운영 스케줄에 상태 검사 배치

상태 검사는 데이터 도착, 빌드와 외부 전달이 기대대로 이루어지는지 감시합니다. 데이터 내용의 정확성이나 업무상 유효성까지 보장하지는 않으므로 이런 조건은 별도의 도메인 검증과 Data Expectations로 정의해야 합니다.

검사를 모든 데이터셋에 무작정 추가하면 같은 장애의 경고가 반복됩니다. 반대로 입력과 최종 출력의 상태를 놓치면 원인을 찾기 어렵습니다. 함께 빌드하는 스케줄을 모니터링 단위로 삼고 데이터셋의 역할에 따라 검사 종류를 정합니다.

실제 실행 범위로 스케줄 해석

Resolved schedule은 스케줄이 실제로 빌드할 수 있는 범위와 필요한 입력을 기준으로 데이터셋의 역할을 정하는 관점입니다. Data Lineage에서 지정한 target 목록 자체와는 다릅니다.

Data Lineage에서 스케줄을 열고 사이드바에서 선택하면 스케줄 색상으로 빌드 범위를 볼 수 있습니다.

• Target은 빌드를 시도하는 대상입니다. Data Connection 동기화 데이터셋은 force build를 설정한 경우에 빌드하는 예외가 있습니다.
• Excludes는 그 스케줄에서 빌드하지 않습니다.
• Connecting build의 Inputs는 보통 빌드하지 않습니다. 그보다 상위에 또 다른 선택 입력이 있으면 연결되는 범위에 포함될 수 있으므로 실제 그래프를 확인합니다.

스케줄이 손댈 수 있는 범위와 매번 실제로 다시 계산하는 범위도 다릅니다. 이미 최신인 데이터셋은 불필요하게 재계산하지 않을 수 있습니다.

Target과 output의 차이

다중 출력 변환이 output_c와 output_d를 함께 만들면 output_c만 target으로 지정해도 output_d도 빌드해야 합니다. 두 데이터셋이 스케줄 안에서 다시 소비되지 않으면 둘 다 output입니다.

반대로 target으로 지정한 데이터셋을 같은 스케줄의 다른 데이터셋이 소비하면 그 데이터셋은 intermediate입니다.

검사들이 측정하는 값

Job status는 해당 데이터셋의 변환 실행 결과를 봅니다. 대상의 실행은 성공했지만 뒤의 다른 작업이 실패한 경우에도 그 Job status는 성공할 수 있습니다. 상위 작업이 실패하여 대상 작업이 취소되고 실행되지 않으면 대상의 Job status를 평가하지 않을 수 있습니다.

Schedule status와 Schedule duration은 지정한 스케줄이 실행할 때 전체 빌드와 중간 실행을 감시합니다. 따라서 스케줄 하나의 장애를 잡기 위해 모든 중간 데이터셋에 Job status를 반복 설치할 필요가 없습니다.

최신성 검사도 기준 시각이 서로 다릅니다.

Ignore empty transactions를 켜면 빈 트랜잭션을 마지막 갱신 시각 계산에서 제외합니다. Data Health API의 timeSinceLastUpdated 구성은 ignoreEmptyTransactions의 기본값이 true입니다. UI에서 사용하는 검사도 이 옵션의 실제 설정값을 확인합니다.

내용 최신성에 사용하는 열은 가능하면 해당 행이 원천 시스템에 추가된 시각을 나타내야 합니다. 빌드가 방금 끝났다는 사실과 내용이 최신이라는 사실을 구분합니다.

스케줄에 설치할 검사

Schedule status는 스케줄 안의 작업 실패를 감시합니다. 이미 이 검사를 사용한다면 같은 스케줄이 빌드하는 모든 데이터셋에 Job status를 추가하는 방식은 권장하지 않습니다.

Schedule duration은 빌드를 막는 충돌이나 실행 시간 악화를 감지합니다. 입력 키 분포가 바뀐 조인처럼 데이터 때문에 느려지는 경우와 코드 변경에 따른 성능 저하를 모두 살펴봅니다. 조인 단계에서 대부분 작업이 끝났는데 하나만 오래 남는 것은 데이터 skew의 신호일 수 있습니다.

입력 데이터셋 검사

실제 input 역할의 모든 데이터셋에 검사를 준비하면 늦은 원천 데이터나 스키마 변경을 원인까지 추적할 수 있습니다. 이 권장안의 일반 상태 검사는 한 데이터셋에 같은 유형을 하나만 설정할 수 있습니다. 필요한 유형의 검사가 이미 있다면 기존 검사를 구독합니다.

Schedule status를 쓰면 상위 단계의 실패 때문에 입력 데이터셋 작업이 취소되거나 중단되어 실행되지 않은 경우도 감지할 수 있습니다.

최종 출력 검사

모든 실제 output에 TSLU를 설치하여 필요한 갱신 주기를 지키는지 확인합니다.

가상 예시로 매일 오전 9시에 시작하고 평균 한 시간 걸리는 파이프라인에는 다음 두 구성이 가능합니다.

• 자동 갱신 검사에서 마지막 업데이트 이후 임계값을 26시간으로 설정합니다. 하루 주기와 빌드 시간 및 여유를 포함합니다.
• 검사 임계값을 2시간으로 두고 매일 오전 11시에 검사하도록 예약합니다. 이 경우 Automatically resolve를 켜면 빌드가 조금 늦게 끝난 뒤 다음 날까지 계속 비정상으로 남는 상황을 피할 수 있습니다.

Schedule status와 duration은 실행 중 문제의 조기 신호이고 출력 TSLU까지 실패하면 실제 갱신 지연을 조사해야 합니다.

다른 애플리케이션이나 사용자가 소비하는 출력에는 Schema 검사도 설치합니다. Contour, Slate나 Object Explorer 등에 영향을 주는 스키마 변경을 감지하여 하위 애플리케이션을 수정하거나 사용자에게 알립니다. 출력에는 정확한 스키마 일치 구성이 권장됩니다.

중요한 중간 데이터셋과 동기화

중간 데이터셋이라도 사용자나 다른 애플리케이션이 직접 사용하면 추가 검사를 둘 수 있습니다.

• Schema는 사용자에게 노출하는 데이터의 구조 변경을 감시합니다.
• Data freshness는 원천 시각 열이 있을 때 내용의 최신성을 확인합니다.
• TSLU는 많은 사용자가 의존하는 중요한 중간 데이터셋의 갱신 지연을 직접 감지하는 보조 수단입니다.
• 다른 Foundry 애플리케이션이나 외부 시스템으로 동기화한다면 Sync status를 설치합니다.
• Sync freshness를 Data freshness 및 TSLU와 함께 보면 데이터셋 자체가 늦게 갱신되었는지, 갱신은 되었지만 원천 내용이 오래되었는지, 내용은 최신인데 외부 동기화가 늦었는지 구분할 수 있습니다.

기본 배치 요약

아래 표는 기본 권장 배치입니다. 선택적 검사는 위의 역할과 SLA에 따라 추가합니다. 사용자 노출 및 동기화 대상 분류는 input, intermediate, output 어느 역할과도 겹칠 수 있습니다.