빌드 스케줄 문제 해결
스케줄이 데이터를 갱신하지 않았을 때는 트리거가 없었는지, 트리거는 있었지만 빌드를 생략했는지, 시작한 빌드가 실패했는지를 먼저 구분합니다. 스케줄의 Metrics에서 Run History를 열면 이 세 경우를 나누어 볼 수 있습니다.
실행 이력에서 원인 구분
| 관찰한 상태 | 확인할 내용 |
|---|---|
| 빌드를 시작했으나 실패했습니다. | 실행 이력의 빌드를 선택하여 Builds의 Build Report와 전체 로그를 확인합니다. |
Ignored가 표시됩니다. | 트리거는 충족되었지만 빌드가 만들어지지 않은 이유를 확인합니다. 모든 대상이 최신 상태인 경우가 흔합니다. |
| 기대한 시점에 실행 이력이 없습니다. | 정지 상태, 트리거 구성과 실제 이벤트 발생 여부를 확인합니다. |
| 일부 작업만 실행되었습니다. | 최신 상태인 작업을 생략했는지, 빌드 선택 범위에서 빠졌는지 확인합니다. |
갑자기 동작이 달라졌다면 Versions에서 해당 시점의 설정 변경을 비교합니다. 정상적으로 동작했던 버전과 대상, 브랜치, 조건 및 권한 범위를 비교하고 필요한 변경을 되돌립니다.
시작한 빌드가 실패한 경우
Run History에서 실제 트리거 시점을 확인한 뒤 연결된 Build Report로 이동합니다. 이후에는 실행 작업의 로그와 오류를 조사합니다.
실행 권한이 부족해도 빌드를 시작하지 못할 수 있습니다. 프로젝트 범위 스케줄은 선택한 프로젝트와 데이터셋의 권한을 확인하고, 사용자 계정 범위 스케줄은 마지막 수정자의 계정 상태와 데이터 권한을 확인합니다. 사용자가 비활성화되거나 필수 데이터에 대한 권한을 잃으면 실행이 실패할 수 있습니다.
Ignored: 모든 데이터셋이 최신 상태인 경우
대상의 입력이 마지막 빌드 이후 바뀌지 않았다면 스케줄은 빌드를 생략할 수 있습니다. 실행 이력에 표시된 사유를 확인하고, Data Lineage에서 Out-of-date 색상 기준으로 어떤 실행 작업 명세가 갱신이 필요한 상태인지 확인합니다.
Force build는 이 판단을 무시합니다. 외부 변경을 Foundry가 감지할 수 없는 Data Connection 동기화나 Object Storage v1(Phonograph) 동기화 같은 경우에 사용하며, 일반 파생 데이터셋 전체에 켜면 불필요한 연산이 발생할 수 있습니다. 외부 API를 호출하는 변환은 항상 갱신이 필요한 것으로 간주하므로 이를 실행하기 위해 강제 빌드를 켤 필요가 없습니다.
일부 실행 작업만 포함된 경우
가능한 원인은 두 가지입니다.
- 빌드 선택에는 포함되었지만 이미 최신 상태여서 실행하지 않았습니다. 전부 최신 상태이면 전체 실행이
Ignored가 됩니다. - 빌드의 실행 작업 명세 그래프에 포함되지 않았습니다. Data Lineage에서 스케줄을 선택하고 실제 빌드 대상의 강조 표시를 확인합니다.
두 번째 경우에는 빌드 유형을 확인합니다. 특히 연결 빌드에서 같은 데이터셋의 여러 브랜치를 사용하는 경우, 스케줄 브랜치에 입력과 대상 사이의 실행 작업 명세 경로가 있어야 합니다.
스케줄이 트리거되지 않은 경우
- 스케줄이 일시 정지되었는지 확인합니다. 정지한 스케줄은 재개하기 전까지 트리거되지 않습니다.
- 시간대와 트리거 조건을 확인합니다. 이전에는 동작했다면 버전 이력에서 최근 변경을 비교합니다.
- 이벤트 트리거라면 실제 이벤트가 발생했는지 확인합니다.
- 입력 갱신을 기다린다면 입력 빌드가 성공했는지뿐 아니라 Dataset Preview 이력에서 필요한 트랜잭션이 커밋되었는지도 확인합니다.
- 여러 입력의 갱신을 모두 기다린다면 모든 입력의 빌드와 발생 시각을 확인합니다.
가상 예로 A1과 A2의 갱신을 AND로 기다리는 스케줄이 T1에 실행되었다고 가정합니다. 다음 T2 실행에는 T1 이후 T2까지 A1과 A2가 모두 다시 갱신되어야 합니다. 그 사이 A2만 수동 빌드하여 갱신해도 A1의 새 이벤트가 없으면 조건을 충족하지 않습니다.
설정한 횟수만큼 재시도하지 않는 경우
재시도 가능한 오류만 다시 실행하며, 관리자가 설정한 최대 횟수가 적용됩니다. 재시도 대상 오류 코드는 다음과 같습니다.
INTERNALTIMEOUTCUSTOM_SERVERFAILED_PRECONDITION
스케줄의 시도 횟수 설정은 최초 시도도 포함합니다. 값이 1이면 이 설정에 따른 재시도는 없습니다. 오류가 재시도 가능한지와 관리자 상한을 함께 확인합니다.
휴지통에 있는 입력이나 출력
JobSpecInputsTrashed, JobSpecOutputsTrashed 오류 또는 Data Lineage의 휴지통 경고는 빌드에 포함되거나 입력으로 읽는 리소스가 휴지통에 있다는 뜻입니다.
- 필요한 데이터셋이면 휴지통에서 복원합니다.
- 필요하지 않으면 스케줄에서 제외합니다.
- 제외한 데이터셋을 다른 하위 데이터셋이 입력으로 읽는다면 하위 데이터셋도 제외하거나, 그 입력을 사용하지 않도록 하위 변환 로직을 바꿉니다.
입력만 제외하고 하위 작업의 의존 관계를 그대로 두면 휴지통의 데이터를 읽으려는 문제가 남을 수 있습니다.
스케줄 편집 권한
| 작업 | 필요한 권한 |
|---|---|
| 프로젝트 범위 스케줄 편집 | 대상 데이터셋의 Editor, 트리거 데이터셋의 Viewer, 스케줄 범위 프로젝트의 Editor가 필요합니다. |
| 편집, 삭제 또는 일시 정지 | 대상 데이터셋과 범위 프로젝트의 Editor가 필요합니다. |
| 조회 | 대상 데이터셋의 Viewer가 필요합니다. |
특정 데이터셋의 권한을 잃은 뒤 구성을 수정하는 경우, 그 데이터셋을 스케줄에서 제거한 다음 변경을 저장해야 합니다.
연산 사용량 정보가 완전하지 않은 경우
다음 경고가 표시될 수 있습니다.
Not all compute information is available. Actual compute usage may be higher than shown.
예약한 빌드가 아직 실행 중이어서 총사용량이 확정되지 않았거나, 적어도 한 빌드의 리소스 사용 정보가 없을 때 나타납니다. 이 경고 자체를 해결하기 위한 사용자 작업은 필요하지 않습니다. 현재 화면의 합계가 실제 사용량보다 작을 수 있다는 뜻으로 해석합니다.