운영 파이프라인의 스케줄 구성 기준

운영 스케줄은 각 데이터셋을 누가 갱신하는지와 어디까지 빌드하는지를 명확히 해야 합니다. 같은 데이터셋을 여러 스케줄이 빌드하면 대기열이 늘고 양쪽 실행이 느려질 수 있습니다. Data Lineage의 노드 색상 기준에서 Schedule count를 선택하면 데이터셋별 스케줄 수를 확인할 수 있습니다.

논리적인 파이프라인 단위로 묶기

대부분의 파이프라인은 한 스케줄로 관리하고 각 데이터셋에는 하나의 예약 빌드만 연결하는 구성이 권장됩니다. 단계마다 스케줄을 따로 두기보다 연결 빌드로 처리 구간을 묶으면 갱신 책임과 실패 조사 위치가 명확해집니다.

최종 출력이 여러 개이거나 검증 테이블을 별도로 갱신해야 하면 여러 스케줄이 필요할 수 있습니다. 예를 들어 Apex 1, Apex 2, Apex 3을 각각 갱신하되 공통 입력인 Shared는 별도 파이프라인에서 갱신하고 나머지 스케줄의 입력 경계로 둘 수 있습니다.

복잡한 파이프라인에서는 입력 검증과 안정성 구성을 함께 적용합니다.

프로젝트 범위와 실행 소유자

가능하면 프로젝트 범위를 사용합니다. 사용자 한 명의 권한에 의존하면 계정 비활성화, 팀 이동 또는 데이터 권한 변경으로 실행이 중단될 수 있습니다. 특히 사용자 계정 범위 스케줄은 마지막 수정자가 소유자가 되므로 단순한 설정 편집도 실행 권한을 바꿉니다.

권한 상속을 끊는 변환, Contour 실행 작업 또는 Fusion 동기화처럼 프로젝트 범위를 사용할 수 없는 경우에는 파이프라인의 스케줄 소유자를 한 계정으로 일관되게 관리하는 편이 좋습니다. 개인에게 종속되지 않는 서비스 사용자 계정이나 수정 책임을 맡은 팀 리드를 사용할 수 있습니다. 다른 계정이 편집하면 소유권이 바뀐다는 점은 그대로 적용됩니다.

소유자가 일관되면 Builds의 Started by 필터로 관련 빌드를 찾기도 쉽습니다. 여러 사용자가 관리하고 권한도 서로 다르면 변경 이력에서 소유자 전환을 함께 확인해야 합니다.

재시도 횟수와 간격

재시도 가능한 예외로 작업이 실패하면 빌드 오케스트레이션 계층은 같은 빌드 안에서 같은 작업의 새 시도를 시작할 수 있습니다. 운영에서는 최초 시도 이후 재시도를 최소 세 번 허용하고, 간격은 최소 1분으로 두는 구성이 권장됩니다. 일반적인 권장 간격은 1~3분입니다. 플랫폼의 일시적인 문제가 해소될 시간을 주기 위한 간격입니다.

편집기의 number of attempts는 최초 시도도 포함하므로 재시도 세 번은 총 네 번의 시도에 해당합니다. 실제 횟수에는 관리자 상한과 오류 유형별 재시도 가능 여부가 적용됩니다.

아주 짧은 SLA 때문에 첫 실패를 즉시 알려야 하거나 변환이 멱등적이지 않은 외부 부수 효과를 일으키면 재시도를 끄는 판단이 필요할 수 있습니다. 다만 스케줄 재시도를 꺼도 런타임 버전 adjudication에 따른 재시도가 발생할 수 있으므로, 설정 하나만으로 모든 재실행이 사라진다고 가정하지 않습니다.

수집 동기화와 강제 빌드 분리

원시 Data Connection 동기화마다 별도의 강제 빌드 스케줄을 둡니다. 외부 원천의 변경 여부를 Foundry가 알 수 없어 동기화가 항상 최신 상태로 표시되기 때문입니다.

일반 파생 데이터셋은 강제 빌드 없이 갱신 필요 여부에 따라 처리합니다. 동기화와 파생 데이터셋을 하나의 강제 빌드로 묶으면 입력이 바뀌지 않은 파생 데이터도 매번 다시 계산할 수 있습니다. 강제 빌드가 필요한 구간을 분리하고, 후속 파이프라인은 연결 빌드로 관리하는 구성이 권장됩니다. Object Storage v1 동기화 등 별도 요건은 고급 설정에서 구분합니다.

포함할 데이터셋과 제외할 데이터셋

자신이 소유하고 관리하는 파이프라인만 빌드하도록 범위를 명시합니다. 가능하면 전체 빌드 대신 연결 빌드를 사용하고, 다른 팀의 데이터셋은 명시적으로 제외합니다.

그림의 Apex 2를 갱신하는 스케줄에서 Owned By Someone을 직접 빌드하지 않도록 제외해야 합니다. Cleaned 1이나 Cleaned 2를 빌드할 권한이 없는 경우에도 이 데이터셋들을 스케줄의 빌드 범위에서 제외합니다. 입력으로 읽는 권한과 직접 갱신하는 권한은 별도로 판단합니다.

다음 리소스도 운영 범위에 주의가 필요합니다.

파이프라인의 모든 최종 출력을 스케줄 대상으로 지정합니다. 대상은 스케줄이 설치되는 데이터셋이고, 출력은 그 빌드 안에서 다른 작업이 더 이상 입력으로 사용하지 않는 최종 데이터셋입니다. 보통 둘은 같지만 여러 출력을 가진 변환에서는 달라질 수 있습니다. 최종 출력을 모두 대상으로 지정했는지 따로 확인합니다.

실패 감지와 이름

실패 신호를 빨리 확인하려면 고급 옵션의 Abort build on failure를 켭니다. 실행 작업 하나가 실패하면 다른 작업을 취소하고 빌드를 종료합니다.

각 스케줄에는 목적을 설명하는 이름을 붙입니다. 여러 수집 경로가 있거나 다른 사용자가 중간 데이터에서 새 파이프라인을 만들거나 유지보수 담당자가 바뀔 때, 이름이 갱신 책임과 실행 범위를 파악하는 단서가 됩니다.