본 번역은 검증되지 않았습니다. AIP를 통해 영문원문으로부터 번역되었습니다.

프로덕션 파이프라인 빌드하기

프로덕션 워크플로는 신뢰할 수 있는 파이프라인을 필요로 합니다. 이 문서에서 설명한 원칙을 파이프라인을 빌드할 때 따르면, 유지 관리가 용이해지며, SLA 위반을 일으키기 전에 문제를 발견할 수 있습니다. 여기서 제시하는 일부 지침은 파이프라인에 중요한 것이 무엇인지 지식을 공유하는 데도 도움이 됩니다. 이는 파이프라인의 생명주기 전반, 개발부터 장기 유지 관리에 이르기까지 모든 단계에서 중요합니다.

이 문서는 파이프라인 개발자와 유지 관리자 모두에게 유용합니다. 개발자의 경우, 파이프라인을 바로 프로덕션으로 넘겨야 할 때 빌드를 시작하기 전에 유용합니다. 마찬가지로, 이 문서는 개념 증명 파이프라인이 프로덕션 파이프라인으로 전환될 때 사용할 수 있습니다. 파이프라인 유지 관리자의 경우, 다음 요소들이 유지 관리 모드로 들어가기 전의 전제 조건이어야 합니다.

파이프라인 정의와 기대치

프로덕션 파이프라인을 빌드하기 시작하기 전에 기대치에 대한 확정적인 답변을 가지는 것이 항상 가능한 것은 아니지만, 가능한 한 초기에 그것들에 대해 주의를 기울이는 것이 가치있습니다. 파이프라인 정의와 기대치를 설정하면서 이를 문서화하는 것이 강력히 권장됩니다.

기대치는 프로덕션 파이프라인의 설계 및 설정의 여러 측면에 영향을 미치며, 이에는 다음이 포함됩니다:

  • 파이프라인 디자인과 아키텍처 결정.
  • 어떻게 일정을 설정해야 하는지(이는 파이프라인이 얼마나 자주 빌드되는지 제어하는 주요 방법입니다).
  • 어떤 검증과 모니터링이 필요한지.
  • 파이프라인이 유지 관리 모드에 있을 때 문제를 어떻게 우선 순위 지정할지.

당신의 팀이 다루어야 할 중요한 질문들은 다음과 같습니다:

  • 파이프라인의 범위가 정확히 무엇인가요? 어디에서 시작하고 어디에서 끝나나요? 어디에서 다른 파이프라인으로 피드해야 하나요?
    • 파이프라인의 일부가 다른 파이프라인이나 유즈케이스와 겹친다면, 겹치는 부분을 자체 파이프라인으로 취급하는 것을 고려해 보세요.
  • 파이프라인 새로 고침 비율에 대한 요구사항은 무엇인가요?
    • 또는 데이터가 특정 시간에 새로 고쳐져야 하는 경우가 있나요?
    • 파이프라인은 주말에도 실행되어야 하나요?
    • 언제 데이터가 중요하게 업데이트되어야 하는가?
    • 새로 고침 비율과 지원에 대한 기대치는 무엇인가?
    • 주의하세요 — 이 부분이 쉬워 보이지만, 파이프라인 유지 관리 팀이 가장 어려움을 겪는 부분입니다. 여기에 명확한 정의가 없으면 파이프라인 유지 관리자로서 작업을 우선 순위 지정하거나 올바른 수정을 하는 것이 어렵습니다.
  • 엔드 투 엔드 전파 지연에 대한 기대치는 무엇인가요? 다시 말해, 데이터가 Foundry에 도착하는 순간부터 파이프라인의 결과물이 업데이트되는 지점까지 데이터가 파이프라인을 통해 흐르는 데 얼마나 걸려야 하는가?
  • 당신이 데이터를 가져오는 모든 외부 소스에 대한 연락처는 누구인가요? 외부 소스는 Data Connection Sync 또는 파이프라인에 피드하는 별도의 상위 Foundry 파이프라인일 수 있습니다.
  • 데이터의 정확성에 대한 기능 보장은 무엇인가요? 파이프라인에 대해 반드시 참으로 해야 하는 중요한 열이나 주요 검증이 있나요?
    • 참고: 보장이 깨질 경우 결과가 무엇이어야 하는지 결정하는 것이 중요합니다. 실패하는 검증이 데이터가 최종 사용자에게 도달하는 것을 방해해야 하나요, 아니면 파이프라인이 업데이트되는 것을 막지 않고 알림을 발송해야 하나요? 다른 최신 데이터가 파이프라인을 통해 흐를 수 있도록 후자를 선택하려고 할 수 있습니다. 이 두 가지 다른 상황에 대한 구현은 다를 것입니다. 문서는 보장을 초기에 추적하기 시작하는 좋은 장소입니다.
  • 결정된 기대치가 호환되는가? 복잡한 시스템이 성장함에 따라 실패에 더 노출됩니다. 일반적으로 알림이 발송된 후 충분한 시간을 허락하여 근본적인 문제를 해결하려고 합니다 - 예를 들어 예상치 못한 파이프라인 실패나 상류 소스에서 누락된 데이터입니다.
    • 예시 1: 예상 파이프라인 새로 고침 비율과 관련하여 전파 지연을 생각하는 것이 중요합니다. 예상 새로 고침 비율이 2시간마다이고, 파이프라인 빌드에 1.5시간이 걸린다면, SLA를 준수하는 것이 어려워질 수 있습니다.
    • 예시 2: 워크플로가 시간당 새로 고침 비율을 요구하지만, 상류 데이터 소스가 하루에 두 번만 데이터를 제공합니다. 이는 시간당 새로 고침을 달성할 수 없음을 의미합니다.

프로덕션 파이프라인을 위한 원칙

성공적인 프로덕션 파이프라인을 설정하는 핵심 원칙은 다음과 같이 요약할 수 있습니다: "당신이 유지 관리를 위해 존재하지 않을 것이라는 생각으로 빌드하세요".

이를 달성하는 데 도움이 될 수 있는 구체적인 팁들은 다음과 같습니다:

  • 코드를 버전 관리하고 의미 있는 커밋 메시지를 작성하세요: 어떤 변경이 언제, 누구에 의해 커밋되었는지 추적하는 데 도움이 됩니다.
    • 프로덕션 파이프라인에서는 가능한 경우 JavaPython을 권장합니다. 이 두 언어는 많은 리소스와 강력한 개발자 커뮤니티를 갖고 있습니다. SQL은 접근성이 뛰어나지만, 매우 빠르게 복잡해질 수 있으므로 디버깅이 더 어려울 수 있습니다.
  • 가능한 모든 것에 대한 가독성을 최적화하세요: 단순한 파이프라인은 유지 관리하기 더 쉽습니다. 표준 또는 기존 솔루션을 변환 코드에 적용하면, 유지 관리 부담과 개발 복잡성이 줄어듭니다. 비정상적인 일을 해야만 한다면, 반드시 철저히 문서화하세요.
  • 가능한 선형 파이프라인: 일반적인 아키텍처 측면에서, 유지 관리하기 쉬운 파이프라인은 대체로 단순하고 선형적인 파이프라인입니다. 하지만 그 방법에 대한 추천을 하는 것은 어렵습니다. 파이프라인의 일반적인 구조를 주의 깊게 보고, 주어진 제약조건 내에서 가능한 한 가독성과 단순성을 최적화하세요. 파이프라인을 프로덕션으로 이동하려고 생각할 때, 파이프라인을 풀어내는 데 시간을 투자하는 것은 대개 시간을 잘 보낸 것입니다.
  • 프로덕션 파이프라인은 종종 장기적으로 존재합니다. 결과적으로 파이프라인을 작성하는 사람들이 장기적으로 파이프라인을 유지 관리하거나 관리하지 않을 가능성이 높습니다. 다음 사람이 파이프라인 개발이나 유지 관리를 맡아야 코드를 읽고 파이프라인 설정을 이해할 수 있어야 합니다.
  • 간결한 문서를 유지하세요:
    • 로직 문서: 일반적으로 로직 자체에 대한 문서는 코드 주석에 유지하는 것이 좋습니다.
    • 전체 파이프라인 문서(파이프라인에서 반복되는 문제를 문서화 포함): 이것도 파이프라인 근처, 직관적인 위치에 유지해야 합니다. 이것은 파이프라인이 속한 프로젝트에서 좋은 예시 위치가 될 수 있습니다. 파이프라인 개발자와 유지 관리자가 쉽게 찾을 수 있어야 합니다.
    • 기억하세요: 과도한 문서화도 읽기 어렵게 하고 유용성을 떨어뜨립니다. 간결하게 하고 핵심 정보를 문서화하세요. 종종 참조되지 않는 매우 긴 파이프라인 정보를 포착해야 하는 경우, 별도의 문서에 유지하는 것을 고려하세요.

개발 프로세스 및 인프라 설정

개발

파이프라인이 프로덕션에 들어가면, 파이프라인에 추가 기여를 하는 데 있어서 더 이상의 개발 프로세스를 확립하고 파이프라인 개발자에게 효과적으로 전달하는 것이 중요합니다. 이는 파이프라인에 예상치 못한 중단이 발생하지 않도록 합니다.

결과적으로, 우리는 읽을 것을 권장합니다:

  • 개발 모범 사례: 적어도, 프로덕션 파이프라인은 읽기 쉽고 유지 관리하기 쉽고, 마스터 브랜치가 잠겨 있어야 합니다. 하지만 개발 설정을 더욱 강력하게 하려면, 이 문서의 더 자세한 조언을 읽는 것을 권장합니다.
  • 브랜치 및 파이프라인 릴리스 프로세스: 파이프라인의 개발 단계 동안 브랜치 및 파이프라인 릴리스 프로세스를 이미 사용하고 있지 않다면, 파이프라인을 프로덕션으로 이동할 때 이것을 권장합니다. 문서는 사용할 수 있는 예시 프로세스를 제공할 것입니다.

인프라 (스케줄)

관련된 주제로, 일정을 조기에 설정하면 파이프라인의 다른 부분을 수동으로 트리거하는 것에 대해 생각하지 않고 개발할 수 있습니다. 스케줄링이 지저분하다면, 이것이 개발을 방해하고 변경이 자동으로 파이프라인을 통해 전파되지 않아 느려질 수 있습니다.

파이프라인을 프로덕션으로 이동할 때, 개발 동안 사용된 스케줄이 더 이상 의미가 없거나 안티패턴을 포함할 수 있으므로 스케줄을 검토하고 재구성하는 것이 권장됩니다. 이 단계는 유지 관리 모드로 들어가기 전에 완료되어야 합니다.

최선의 사례에 따라 스케줄을 설정하거나 검토하는 것은 **스케줄링 최선의 사례 문서**를 따르면 이루어질 수 있습니다.

조기 모니터링 시작

파이프라인이 정기적으로 실행되는 즉시, 그 행동을 모니터링하기 시작하려고 합니다. 이는 기술 부채가 누적되는 것을 방지하고 파이프라인에 대한 기대치가 현실적인지 아닌지 추적할 수 있게 해줍니다. 마감과 팀의 능력을 고려할 때, 바로 모니터링을 시작하는 것이 항상 실행 가능한 것은 아니지만 가능한 경우에는 권장됩니다.

모니터링을 설정하는 방법에 대한 자세한 정보는 파이프라인 모니터링 최선의 사례 문서를 참조하세요.