일정 관리 모범 사례

생산 파이프라인의 일정을 쉽게 관리할 수 있도록, 일정 관리 지침을 개발하였습니다. 이 페이지를 사용하여 당신이 책임지고 있는 일정들을 관리하세요.

전체보기 체크리스트

• 각 데이터셋은 하나의 일정에 의해서만 빌드되어야 합니다.
  • 노드 색상 드롭다운에서 일정 수를 선택하여 Data Lineage 그래프에서 각 데이터셋의 일정 수를 확인할 수 있습니다.
• 각 원시 Data Connection 동기화에 대해 하나의 강제 빌드 일정이 있어야 합니다.
  • 다른 일정에는 강제 빌드가 없어야 합니다. 강제 빌드는 Data Connection 동기화와 함께만 사용해야 합니다.
• 전체 빌드를 피하고 대신 연결 빌드를 사용하려고 노력하세요.
• 일정은 당신이 소유한 데이터셋만 빌드해야 합니다; 일정은 당신이 소유하지 않은 데이터셋을 빌드해서는 안됩니다.
• 휴지통에 있는 데이터셋은 당신의 일정에 의해 빌드되어서는 안됩니다. 휴지통에 있는 리소스를 포함한 일정을 조사하고 해결하기 위해 Upgrade Assistant를 사용하세요.
• 일정에 재시도를 추가하세요(1분에서 3분 사이의 간격으로 세 번의 재시도를 추천합니다).
• 파이프라인의 각 단계에 여러 일정을 가지는 것을 피하고, 대신 데이터셋을 논리적인 일정으로 결합하세요.

예시

하나의 일정으로 결합되어야 할 불필요한 일정이 있는 파이프라인:

연결 빌드를 사용하여 데이터셋을 논리적인 일정으로 결합:

아래 가이드라인을 사용하여 파이프라인에 대한 효과적인 일정 시스템을 설정하세요.

모범 사례

파이프라인 당 하나의 일정

대부분의 경우, 파이프라인 당 하나의 일정만 가져야 합니다. 사실, 파이프라인의 각 데이터셋은 하나의 예정된 빌드만 가져야 합니다. 데이터셋이 두 개의 다른 일정에 의해 빌드되는 경우, 큐잉이 발생하고 두 일정 모두가 느려질 수 있습니다. 각 일정의 책임을 명확히 하고 특정 데이터셋에서 빌드가 실패한 경우 디버깅을 쉽게 하기 위해 일정 집합을 간단하고 정리된 상태로 유지하세요. 이것은 또한 파이프라인 유지 보수에 도움이 될 수 있습니다; 파이프라인을 설정하거나 수정하려면 확인하거나 수정할 곳이 하나만 있으면 됩니다.

순차적인 단계에서 실행되는 파이프라인에 대해 예외가 있을 수 있습니다; 이러한 예시 중 일부는 아래에 설명되어 있습니다:

1. 파이프라인에 여러 종단 노드가 있는 경우, 각 노드에 대한 별도의 일정을 고려해 볼 수 있습니다. 아래에 보여진 예제 파이프라인에서 가장 자연스러운 접근법은 Apex 1, Apex 2 및 Apex 3에서 정의된 세 개의 일정을 설정하는 것입니다. 그러나 Shared에 일정을 생성하고 이 데이터셋을 다른 파이프라인의 입력으로 처리하는 것도 유익할 수 있습니다.
2. 파이프라인이 검증 테이블을 사용하는 경우, 별도의 일정이 필요할 수 있습니다.
3. 이러한 복잡한 파이프라인을 효과적으로 처리하는 방법에 대한 자세한 정보는 안정성 권장 사항을 참조하세요.

프로젝트 범위 일정

가능한 경우 모든 일정은 프로젝트 범위 내에 있어야 합니다. 그래야 일정이 성공적으로 실행되는 능력이 단일 사용자(일정 소유자)의 권한에 의존하지 않게 됩니다. 그렇지 않으면, 일정 소유자의 권한이 변경되어 일정의 데이터셋 빌드를 방해할 수 있습니다. 이는 일정 소유자가 일정 편집 후 변경될 수 있기 때문에 특히 중요합니다. 일정을 마지막으로 수정한 사용자가 일정의 소유자가 되기 때문입니다.

일정을 프로젝트 범위로 설정할 수 없는 경우가 있습니다:

• 권한이 끊어진 변환
• Contour 작업
• Fusion 동기화

사용자 범위 일정에 대한 일정 당 하나의 소유자

프로젝트 범위로 설정할 수 없는 일정에 대해, 주어진 파이프라인에 모든 일정을 소유하는 단일 사용자가 있는 것이 바람직합니다. 이 사용자는 종종 "서비스 사용자"(단일 사람에게 연결되지 않은 특수 사용자 계정)입니다. 또는 단일 소유자는 프로젝트 내의 모든 일정 수정에 대한 책임을 가진 팀 리더일 수 있습니다.

파이프라인에 일정을 소유하는 단일 사용자가 있으면 복잡성이 줄어들고 일정이 사용자 권한 또는 팀 구성의 변경으로 인해 부정적인 영향을 받는 것을 방지할 수 있습니다.

위에서 언급했듯이, 일정을 마지막으로 수정한 사용자가 일정의 소유자가 된다는 점을 주의해야 합니다. 여러 사용자 프로필이 일정을 관리하고 팀 전체의 접근 권한이 동일하지 않은 경우, 소유권 변경을 고려하지 않으면 권한 오류가 발생할 수 있고 이를 추적하는 것이 어렵습니다.

재시도 사용

일정을 설정할 때 재시도를 사용하세요. 재시도는 작업의 일부입니다; 작업이 재시도 가능한 예외로 실패하면, 빌드 오케스트레이션 레이어는 빌드를 실패하지 않고 동일한 작업의 새로운 시도를 다시 시작합니다.

최소 세 번의 재시도를 설정하고, 재시도 사이에 최소한 1분의 간격을 두도록 일정을 설정하는 것을 추천합니다. 이를 통해 플랫폼이 실패하게 될 작업을 자동으로 가로채고 동일한 빌드 내에서 그것들을 다시 트리거할 수 있습니다. 1분의 추가 간격은 작업이 처음 실패한 원인이 된 일시적인 문제에서 플랫폼이 복구할 수 있게 합니다.

작업에 재시도를 활성화하고 싶지 않은 경우도 있습니다. 예를 들어, 실패가 발생하면 즉시 알림을 받아야 하는 매우 엄격한 서비스 수준 계약(SLAs)을 가진 파이프라인이나, 멱등이 아닌 부작용을 가진 변환 등이 있습니다.

다중 데이터셋 강제 빌드 없음

일정은 "강제 빌드" 옵션을 활성화할 수 있습니다. 이 경우, 일정의 모든 데이터셋이 그들의 오래됨에 관계없이 빌드됩니다. 이 옵션은 항상 플랫폼에서 최신 상태인 Data Connection 동기화에 매우 유용하며, 따라서 강제 빌드를 사용하지 않으면 예정된 빌드의 일부로 빌드되지 않습니다. 그러나 우리는 파생된 데이터셋에 대해 강제 빌드 옵션이 있는 다중 데이터셋 일정을 가지는 것을 권장하지 않습니다. 이는 리소스 사용 면에서 비용이 많이 들 수 있기 때문입니다. 대신 일정을 분리하여 강제로 빌드해야 하는 데이터셋이 자체 일정에 있도록 하세요.

일정에 포함하거나 제외해야 할 항목

일정에 포함되는 것에 대해 명시적으로 해야 합니다. 파이프라인 외부에 있는 데이터셋을 명시적으로 무시하세요. 빌드 해결은 복잡할 수 있지만, 포함된 것에 대해 명시적이라는 것은 묵시적보다 더 투명성을 제공합니다.

• 아래의 예제 파이프라인 스크린샷에서, Apex 2에서 정의된 일정에서 Owned By Someone을 무시해야 합니다. Cleaned 1과 Cleaned 2에 대해서도 동일하게 적용됩니다 — 이들 중 어느 하나에서 작업을 트리거하면 권한 부족으로 인해 빌드가 즉시 실패하게 됩니다.

또한, 일정은 다음에 대해 의존하거나 빌드를 시도해서는 안됩니다:

• 현재 휴지통에 있는 것: 휴지통에 있는 리소스를 가진 기존 일정을 수정하려면, 일정 소유자가 되거나 일정에서 해당 리소스를 제외하려면 Upgrade Assistant를 사용하여 조사하세요.
• Contour에서 생성된 것: 일정이 "생산 준비"로 간주되려면, 파이프라인 변경사항을 검토하고 문제가 발생한 경우 이전 버전으로 되돌릴 수 있어야 합니다. Contour는 이러한 워크플로를 지원하지 않으므로, 생산 파이프라인에서 사용하는 것을 권장하지 않습니다.
• Code Workbook 및 Code Workspaces에서 생성된 것: 이것은 Contour 출력 데이터셋보다 엄격한 규칙은 아니지만, 생산 파이프라인에서 Code Workbook 및 Code Workspaces 사용을 권장하지 않습니다. Code Workbook 및 Code Workspaces는 솔루션에 대한 반복에는 훌륭하지만, 변경 관리 및 되돌리기에 관해서는 Code Repositories보다 덜 견고합니다. Code Workbook, Code Workspaces, 및 Code Repositories 간의 차이에 대해 더 알아보기.

파이프라인의 모든 출력은 일정에서 "대상"으로 태그되어야 합니다. 일정은 하나 이상의 대상을 가질 수 있으며, 이는 일정이 설치된 데이터셋입니다. 일정은 또한 하나 이상의 출력을 가질 수 있으며, 이는 빌드의 다른 부분에서 사용되지 않는 일정에 의해 빌드된 최종 데이터셋입니다. 대부분의 경우, 대상 데이터셋과 출력 데이터셋은 동일하겠지만, 일부 경우에는(특히 다중 출력 빌드와 함께) 빌드가 대상과 출력 데이터셋이 다른 경우가 있을 수 있습니다. 일반적으로, 파이프라인의 모든 출력은 대상으로 정의되어야 합니다.

빠르게 실패

작업이 실패하면 즉시 빌드가 실패하도록 설정하세요(고급 옵션에서 실패시 빌드 중단 체크박스를 선택하세요). 빠르게 실패하는 것은 더 빨리 신호를 제공합니다.

일정 이름 지정

모든 일정에는 설명적인 이름이 있어야 합니다. 일정 이름은 파이프라인이 복잡성과 사용자가 시간이 지나면서 증가함에 따라 매우 도움이 될 수 있습니다.

설명적인 일정 이름은 일정과 상호 작용하는 사람들에게 일정의 의도에 대한 정보를 제공합니다; 예를 들어, 미래에 당신의 일정과 관련된 문제를 해결하는 책임이 있는 사람들입니다.

여러 흡입 스트림이 있는 경우, 파이프라인의 어떤 경로를 다른 사용자가 포크해갈 것으로 예상하는 경우, 또는 유지 보수 책임이 시간이 지남에 따라 변경될 것으로 예상하는 경우, 일정 이름을 지정하는 것이 특히 중요합니다.