실패하는 파이프라인 디버그하기

파이프라인 문제를 빠르게 디버그하고 해결하는 능력은 파이프라인 유지 보수 작업의 핵심 부분입니다. 이를 통해 조직의 중요한 워크플로를 공급하는 생산 파이프라인이 신뢰할 수 있고 의미 있는 상태를 유지할 수 있습니다.

이 문서는 파이프라인 유지 보수자로서 온콜 회전 중 건강 상태 점검 실패에 대한 알림을 받을 때 사용할 수 있는 표준 운영 절차(SOP)의 기초로 사용할 수 있는 프레임워크를 제공합니다.

사전 지식

이 문서는 다양한 Foundry 도구와 워크플로에 익숙하다고 가정하고 있습니다. 관련 섹션에 링크가 제공됩니다:

• Code Repositories
• 빌드 애플리케이션
• 스케줄링 및 스케줄 지표
• Data Lineage

또한 파이프라인 관리자 팀에서 파이프라인의 반복적인 문제에 대한 사건 로그나 기타 문서를 기록한다고 가정합니다. 이는 모범 사례이며 현재 이러한 문서가 없다면 구현해야 합니다.

디버깅 프레임워크 개요

다음 세 가지 질문을 순서대로 항상 먼저 물어보세요.

1. 완화: 이 문제를 가능한 한 빨리 완화할 수 있습니까? 예를 들면:
   • 스케줄을 다시 빌드합니다. 개별 데이터셋이나 실패한 작업보다 스케줄을 다시 빌드하는 것이 좋습니다. 스케줄 기록을 사용하면 파이프라인의 기록이 아닌 개별 데이터셋의 기록을 추적할 수 있습니다.
   • 대기열이 너무 많으면 겹치거나 집중적인 스케줄을 찾아 취소합니다.
   • 수동 업로드가 손상된 경우, 알려진 안정 버전으로 트랜잭션을 되돌립니다.
2. 분류: 문제의 범주는 무엇입니까?
   • 문제를 분류하는 이유는 근본 원인을 파악하고 다른 팀의 참여가 필요한 해결책을 결정하기 위함입니다.
   • 문제 범주를 파악하고 식별하는 방법에 대한 자세한 내용은 아래를 참조하세요.
3. 보다 넓은 영향: 이 문제가 플랫폼의 다른 부분에 영향을 미칠 수 있습니까?

문제 범주 분류

문제를 완화하려고 시도한 후, 파이프라인 관리자로서 근본 원인을 이해하고 대처하기 위해 더 깊이 파고들어야 합니다. 디버깅 중 문제를 분류하는 이유는 근본 원인을 파악하는 데 도움이 되기 때문이며, 가장 중요한 것은 문제를 해결할 수 있는지 아니면 다른 팀에 연락해야 하는지를 빠르게 판단할 수 있게 합니다.

문제의 범주는 세 가지입니다:

• 업스트림 문제: 다른 사람들이 관리하는 인프라나 아티팩트와 관련된 문제
  • Foundry 외부: 업스트림 데이터 소스와 관련된 문제
  • Foundry 내부: 파이프라인 질문의 업스트림에 있는 데이터셋/프로젝트로 인한 문제
• 플랫폼 문제: Foundry 플랫폼 서비스가 예상대로 작동하지 않아 발생하는 문제.
• 변경: 모니터링하는 파이프라인의 범위 내에서 변경된 모든 것. 이것은 문제의 가장 일반적인 범주이며 사용자 변경으로 인해 종종 발생합니다. 예를 들면:
  • 코드 변경
  • 스케줄 변경
  • 파이프라인의 데이터 크기 증가

문제 범주별 문제 해결 단계:

자세히 보면, 위의 단계는 다음과 같습니다:

• 식별: 위의 단계를 진행할 때 무엇이 손상되었는지 정확하게 식별하는 것이 중요합니다. 다음과 같은 질문에 답하세요:

  • 문제가 언제 시작되었습니까?
  • 파이프라인의 어떤 단계에서 무언가가 실패했습니까?
  • 어떤 건강 상태 점검이 실패했습니까?
  • 파이프라인에서 무언가가 변경되어 이 손상된 상태를 초래했습니까?

  이를 통해 업스트림 문제 및 플랫폼 문제에 대해 다른 팀과 필요한 경우 효과적으로 의사소통할 수 있으며, 해결 시간을 줄이고 플랫폼에서 디버깅 기술을 향상시킵니다.

• 행동:

  • 업스트림 문제: 파이프라인의 업스트림에서 프로젝트 또는 데이터 소스로부터 지연되거나 누락되거나 잘못된 데이터로 인해 문제가 발생한 것으로 확인되면 업스트림 데이터에 대한 책임을 지는 팀에 연락하세요.
    • 팁: 모니터링을 시작하기 전에 업스트림 팀의 연락처 정보를 문서화하는 것이 도움이 됩니다. 이렇게 하면 온콜 담당자가 쉽게 연락할 수 있습니다.
  • 플랫폼 문제: Foundry에서 예상치 못한 동작을 발견하고 파이프라인의 사용자 변경을 배제한 경우 Palantir 담당자에게 연락하세요. 관찰된 변경 사항에 대한 세부 정보를 포함하여 문제에 대한 가능한 한 구체적인 정보를 제공하세요. 아래 섹션에서 이러한 문제를 어떻게 발견하는지에 대한 팁을 확인할 수 있습니다.
  • 변경: 모니터링 중인 파이프라인 내에서 무언가 변경된 것을 확인한 후, 일반적으로 문제를 해결하기 위한 조치를 취할 수 있습니다. 경우에 따라 변경을 한 사람에게 추가 정보를 요청해야 할 수도 있습니다. 파이프라인에서 무언가 변경되었는지 확인하는 데 도움이 되는 다음 섹션을 참조하세요.

• [선택 사항] 하위 사용자 통신: 문제가 분류되고 추가 근본 원인이 파악되면 파이프라인의 하류 소비자에게 알리는 것이 적절할 수 있습니다. 이는 문제의 영향, 범위, 기간 및 파이프라인의 사용 사례에 따라 다릅니다.

• 회피 방법: 다른 팀이나 사용자로부터의 수정이 시간이 걸릴 경우, 파이프라인의 건강한 부분이 하류 소비자에게 계속 실행되도록 중기적인 회피 방법을 구현하는 것이 유용할 수 있습니다. 정확한 임시 수정은 문제와 사용자의 요구에 따라 다릅니다. 예를 들면:

  • 손상된 데이터셋이나 파이프라인 분기를 스케줄에서 제거하여 문제를 격리시킵니다.
  • 문제의 근본 원인이 되는 경우 다른 파이썬 라이브러리 버전을 고정합니다. 이는 meta.yml에서 라이브러리 이름 옆에 명시적 버전 번호를 지정하여 수행할 수 있습니다.

파이프라인의 변경 사항 확인

파이프라인 관리자에게 가장 일반적으로 발생하는 문제는 모니터링하는 파이프라인 내에서 무언가가 변경되어 발생한 결과로 인한 문제입니다. 또한 파이프라인 관리자로서 가장 통제할 수 있고 문제를 직접 해결할 수 있으며 다른 팀에 의존할 필요가 없습니다.

자세한 단계는 다음과 같습니다:

1. 최선을 다해 파이프라인에서 문제가 발생하는 정확한 위치를 찾으세요. 예를 들어 스케줄, 데이터셋, 트랜잭션, 코드 변경 등을 확인하려고 시도하세요.

2. 건강한 이전 실행과 현재 손상된 상태를 비교하여 무엇이 변경되었는지 확인하세요. 정신적 체크리스트 질문이 유용할 수 있습니다. 아래는 질문 예제와 해당 질문에 대한 답을 찾을 수 있는 도구 예제입니다:

   • 평소보다 느린가요? 이것은 대기열로 인한 것인지 아니면 실제로 빌드가 계산하는 데 더 오래 걸리는 것인지 확인하세요.
   • 파일/데이터 크기 변경?
   • 코드 변경? 스키마 변경?
   • 스케줄 변경?
   • 진행 중인 플랫폼 사건?

도구

위의 질문에 대한 답을 찾는 데 사용되는 Foundry 도구에 익숙하지 않은 경우 아래 목록은 조사 중에 사용할 수 있는 가장 일반적인 패턴의 예를 제공합니다. 이 목록은 가능한 모든 경우를 다루지 않지만 시작 가이드로 사용할 수 있습니다:

내 작업/빌드가 평소보다 느린가요?

• 빌드 애플리케이션은 주어진 데이터셋에 대한 작업을 비교합니다. 빌드 개요의 오른쪽 상단에 있는 진행 상세 전환을 사용하면 대기 시간 대 계산 시간으로 빌드 진행 상황을 볼 수 있습니다.

  • 실패한 작업이 스케줄의 일부로 빌드된 경우, 빌드 세부 정보 페이지의 왼쪽 하단에 스케줄 카드가 표시됩니다. 이전 빌드를 나타내는 점을 클릭하여 이전 스케줄 실행을 열 수 있습니다.

• 스케줄 지표를 사용하면 스케줄의 과거 실행을 볼 수 있으며 실행을 비교할 수 있는 지표와 그래프를 볼 수 있습니다.

데이터셋 크기에 변경이 있나요? 변환은 더 많은 데이터로 실행되나요?

• 데이터셋 미리보기: Foundry 데이터셋의 이력 및 비교 탭은 데이터셋 이력 개요와 이전 데이터셋 트랜잭션과 비교하여 무엇이 변경되었는지 개요를 볼 수 있게 해줍니다.

• Contour는 요약 보드를 사용하여 행 수를 비교할 수 있는 이력 뷰에 액세스하거나 데이터가 추가/생성된 날짜를 나타내는 열이 있으면 행 수와 추가된 날짜를 비교하는 차트를 만들 수 있습니다.

• 스파크 세부 정보: 작업의 스파크 세부 정보 버튼(아래 참조)을 클릭하면 파이프라인에 데이터가 더 많은지 확인하는 데 도움이 되는 정보를 볼 수 있습니다. 예를 들어 task의 개수 지표가 있습니다.

파이프라인의 코드가 변경되었나요?

• 데이터셋 미리보기의 비교 탭을 사용하면 이력 트랜잭션을 데이터셋과 비교할 때 직접 변환 파일의 코드 변경 내용을 볼 수 있습니다.
• Code Repositories 내에서 코드 탭의 파일 변경 (커밋 이력) 도움말을 사용하면 코드 변경 내용을 볼 수 있습니다.
• Data Lineage 도구를 사용하면 파이프라인 전체에 걸쳐 스키마를 빠르게 검토할 수 있습니다. 특히 사이드 패널 속성 및 히스토그램은 파이프라인에 걸쳐 특정 열을 포함하는 데이터셋을 추적하는 데 유용할 수 있습니다.

스케줄이 변경되었나요?

• 플랫폼의 다양한 부분에 있는 스케줄 카드를 사용하면 스케줄이 마지막으로 변경된 시점을 볼 수 있습니다.
• 스케줄 지표 페이지의 스케줄 버전 탭을 사용하여 스케줄 구성에 어떤 변경이 이루어졌는지 정확하게 식별할 수 있습니다.

플랫폼 문제 식별

다른 작업, 빌드 또는 관련 플랫폼 구성 요소에서 비슷한 증상을 검사하는 것은 문제의 기반을 찾지 못한 경우 유용한 조사 경로가 될 수 있습니다.

특히 다음 질문에 대한 답을 찾아야 합니다:

• 재현 가능한가요?
  • 이 문제가 일관되게 발생합니까?
  • 패턴을 따릅니까? 예를 들어 매주 월요일 오전 9시에 주말 후에 실패하는 경우가 있습니까?
• 범위는 어떻습니까?
  • 작업이 느리거나 실패할 경우 다른 변환 작업에서도 이 문제를 확인하고 있습니까? 아니면 Python 작업만 가능합니까?

빌드 애플리케이션을 사용하여 플랫폼 전체의 작업 이력을 필터링하면 위의 질문에 답할 수 있습니다.

파이프라인 관리자의 핵심 업무 중 하나는 파이프라인 문제를 빠르게 디버그하고 해결하는 것입니다. 이를 통해 조직의 중요한 워크플로를 공급하는 생산 파이프라인이 신뢰할 수 있고 의미 있는 상태를 유지할 수 있습니다. 이 페이지에서 설명한 가이드라인을 따르고도 문제를 파악할 수 없는 경우 Palantir 담당자에게 연락하세요.