실패한 스트림 조사와 복구
스트림은 계속 실행되는 작업이므로 실패가 시작된 시점과 재시작 후의 동작을 함께 확인합니다. 처음부터 실패하는지, 한 번 실패한 뒤 정상화되는지, 재시작할 때마다 같은 구간에서 실패하는지에 따라 조사할 입력과 인프라가 달라집니다.
실패 양상
| 유형 | 관찰 기준 | 조사 방향 |
|---|---|---|
| 즉시 실패 | 시작 후 5분 안에 실패합니다. | 잘못된 캐스팅, 파싱 오류 또는 클러스터 시작을 막는 사용자 로직을 조사합니다. |
| 일시적 실패 | 한동안 정상 실행한 뒤 한 번 실패하고 재시작 후 계속 정상 실행합니다. | 네트워크나 클라우드 인프라의 일시적인 중단을 조사합니다. |
| 반복 실패 | 이전에는 정상 실행했지만 이후 재시작할 때마다 약 5~10분 안에 실패합니다. | 진행을 막는 새 입력 데이터 또는 지속적인 인프라 문제를 조사합니다. |
이 유형은 원인을 좁히는 기준이며 원인을 확정하는 진단값은 아닙니다. 과거에 성공한 스트림이라면 사용자 로직뿐 아니라 상위 스트림의 변경도 비교합니다.
일시적 실패에는 AWS, Azure 또는 GCP 같은 기반 클라우드의 네트워크 장애가 영향을 줄 수 있습니다. 스트림에 스케줄을 적용하면 실패 후 자동 재실행으로 복구 지점에서 처리를 이어가도록 구성할 수 있습니다.
상세 화면과 로그
Dataset Preview에서 스트림 상세를 열고 실패한 실행을 찾습니다. Foundry가 식별한 일반 오류는 상세 화면에 표시됩니다.
상세 설명보다 로그에 더 많은 원인 정보가 있을 수 있으므로 두 위치를 함께 확인합니다. 로그에서는 ERROR, throwable, Exception 같은 단서와 실제 예외가 발생한 코드를 찾습니다.
로그를 내려받으려면 해당 실행의 Download logs를 선택합니다. 가장 이른 로그부터 볼지 가장 최근 로그부터 볼지 순서를 선택할 수 있습니다.
로직과 입력 데이터
예외가 특정 코드 위치를 가리키면 최근 변경과 비교합니다. 변경이 원인인지 확인하려면 해당 코드 변경을 되돌리는 복구 절차를 검토할 수 있습니다.
로직을 바꾸지 않았어도 새로운 입력이 기존 가정을 깨뜨릴 수 있습니다. 예를 들어 분모에 0이나 null이 들어오는 상황을 처리하지 못하는 코드, 손상된 값 또는 예상과 다른 자료형이 원인이 될 수 있습니다. 입력 스트림 끝부분의 레코드를 확인하고, 업무상 올바른 정제 또는 제외 기준을 반영합니다. 특정 예외를 무조건 무시하여 데이터 누락을 숨기는 방식과는 구분합니다.
지연과 상태 문제도 함께 나타나면 스트리밍 모니터링과 상태 및 워터마크를 확인합니다.
시작 트랜잭션이 현재 뷰에 없는 오류
다음 오류가 반복될 수 있습니다.
Caused by: com.palantir.logsafe.exceptions.SafeIllegalStateException: Start transaction rid is not part of the current view.
대표적인 원인은 스트리밍 입력에 새 스냅샷이 생성되어 이전 시작 트랜잭션이 현재 뷰의 범위에서 벗어난 경우입니다. 스트리밍은 받은 레코드를 곧바로 하위로 보내므로 원천의 새 스냅샷만으로 이미 전달한 레코드를 취소할 수 없습니다. 새 스냅샷을 기준으로 결과를 다시 계산하려면 재생이 필요합니다.
Pipeline Builder에서 새 배포를 시작하고 Deploy pipeline의 Replay on deploy를 선택하여 입력을 다시 처리합니다.
재생은 스트림 이력과 하위 소비자에 영향을 주며 큰 파이프라인에서는 중단 시간이 길어질 수 있습니다. 기본 Reset Outputs on replay가 켜진 상위 파이프라인은 출력을 비우고 재생 범위로 다시 채우므로, 하위 파이프라인도 새 입력 범위 전체를 올바르게 처리하도록 재생 범위를 정해야 합니다. 단순한 입력 스트림 초기화와 재생 배포를 같은 작업으로 취급하지 않습니다.