파이프라인 장애의 범위와 원인 조사
상태 검사 알림을 받은 운영 담당자는 복구 방법을 선택하기 전에 파이프라인의 기대 동작과 기존 장애 기록을 확인해야 합니다. Code Repositories, Builds, 스케줄 이력과 Data Lineage를 이용하여 실패 지점과 변경 범위를 찾습니다. 반복 문제의 원인과 대응은 팀이 공유하는 장애 기록에 남깁니다.
완화, 분류와 영향 범위
먼저 다음 순서로 판단합니다.
- 현재 영향을 줄일 수 있는지 확인합니다. 실행을 다시 해야 한다면 개별 데이터셋보다 스케줄을 재실행하여 파이프라인 단위 이력에 남기는 방식이 권장됩니다. 대기가 심하면 겹치거나 자원을 많이 쓰는 스케줄을 찾아 조정할 수 있고, 잘못된 수동 업로드는 알려진 정상 데이터 트랜잭션으로 되돌리는 방법을 검토할 수 있습니다.
- 원인이 상위 입력, 플랫폼 서비스 또는 담당 파이프라인 안의 변경 중 어디에 있는지 분류합니다.
- 다른 파이프라인이나 플랫폼 구성요소에도 같은 문제가 영향을 주는지 확인합니다.
복구 조치는 파이프라인의 운영 문서를 따릅니다. 예를 들어 대규모 전체 재빌드는 피크 시간에 다른 작업의 성능을 떨어뜨릴 수 있으므로 비용과 파급 범위를 확인해야 합니다.
담당 범위에 따른 분류
| 범주 | 예시 | 주된 대응 |
|---|---|---|
| 상위 입력 문제 | 외부 원천의 지연, 누락 및 잘못된 데이터 또는 다른 Foundry 프로젝트의 입력 장애 | 해당 원천이나 상위 파이프라인 담당자와 확인합니다. |
| 플랫폼 문제 | 사용자 변경으로 설명되지 않는 Foundry 서비스의 비정상 동작 | 구체적인 근거를 모아 Palantir 담당자와 조사합니다. |
| 담당 파이프라인의 변경 | 코드, 스케줄, 스키마 또는 데이터 크기의 변화 | 변경 내용을 추적하여 수정하고 필요하면 변경 작성자에게 확인합니다. |
분류할 때는 다음 사실을 구체적으로 기록합니다.
- 문제가 시작한 시점
- 처음 실패한 단계와 데이터셋, 트랜잭션 및 실행 작업
- 실패한 상태 검사
- 정상 상태와 비교하여 바뀐 코드, 입력 또는 구성
상위 원천의 연락처는 장애 전에 운영 문서에 준비해 두는 것이 좋습니다. 문제의 영향, 지속 시간과 업무 성격에 따라 하위 소비자에게도 알립니다.
다른 팀의 수정에 시간이 걸리면 정상 구간을 계속 운영하기 위한 임시 조치를 검토할 수 있습니다. 예를 들어 문제 데이터셋이나 경로를 스케줄에서 분리하거나, 원인이 확인된 Python 라이브러리 버전을 meta.yaml에 명시하여 고정할 수 있습니다. 임시 조치와 최종 수정의 범위를 구분합니다.
정상 실행과 비교
먼저 스케줄, 데이터셋, 트랜잭션 또는 코드 변경 중 어느 수준에서 문제가 시작했는지 찾습니다. 이전 정상 실행과 비교할 때는 다음 질문을 사용합니다.
- 대기 시간이 늘었습니까, 실제 계산 시간이 늘었습니까?
- 파일 수나 데이터 크기가 바뀌었습니까?
- 코드 또는 스키마가 바뀌었습니까?
- 스케줄 설정이 바뀌었습니까?
- 알려진 플랫폼 장애가 있습니까?
대기 시간과 계산 시간
Builds의 진행 상세 표시에서 대기와 연산 시간을 나누어 확인합니다. 스케줄이 시작한 빌드라면 상세 화면 왼쪽 아래의 스케줄 카드에서 과거 실행 점을 선택하여 이전 빌드로 이동할 수 있습니다.
스케줄 지표의 이력과 그래프도 실행 간 비교에 사용할 수 있습니다. 개별 실행 작업의 입력 및 코드 차이는 Job Comparison에서 확인합니다.
데이터 크기와 스키마
Dataset Preview의 History와 Compare에서 과거 트랜잭션과 현재 상태를 비교합니다.
Contour의 과거 데이터 뷰 및 요약으로 행 수를 비교하거나, 생성 및 수집 날짜 열을 기준으로 행 수 추세를 볼 수 있습니다. Spark details의 count of tasks도 처리 범위 증가를 파악하는 단서가 됩니다.
Data Lineage의 스키마와 Properties & Histogram 패널에서는 특정 열을 사용하는 데이터셋을 찾아 영향을 조사할 수 있습니다.
코드와 스케줄 변경
Dataset Preview의 Compare는 해당 데이터셋을 만드는 직접 변환 파일의 변경을 보여 줍니다. Code Repositories의 Code 탭에서는 File changes 또는 커밋 이력 helper로 저장소 변경을 확인합니다.
직접 작성한 변환이 그대로여도 Python 또는 Java의 공유 라이브러리 로직이 바뀌었을 수 있습니다. 가져온 라이브러리의 버전과 함수 변경도 확인합니다.
스케줄 카드는 마지막 수정 시점을 보여 주며, 지표 페이지의 Versions는 실제 설정 차이를 비교합니다. 실행 주체와 범위도 수정으로 바뀌었는지 확인합니다.
플랫폼 문제의 근거
다른 실행 작업에서도 비슷한 증상이 나타나는지 Builds에서 범위를 좁혀 확인합니다. 계속 재현되는지, 매주 월요일 09:00처럼 반복 패턴이 있는지, 모든 변환인지 Python 작업에만 한정되는지 등이 조사에 도움이 됩니다.
플랫폼 문제로 판단할 때는 담당 파이프라인의 변경을 조사한 결과와 재현 범위, 발생 시각 및 관련 오류를 함께 전달합니다. 원인을 특정하지 못한 경우에도 현재까지 확인한 근거를 정리하여 Palantir 담당자와 이어서 조사할 수 있습니다.