느리거나 중단된 작업 문제 해결

이 페이지에서는 Dataflow 스트리밍 및 일괄 작업이 느려지거나 중단되는 일반적인 원인을 해결하는 방법을 설명합니다.

스트리밍

다음과 같은 증상이 나타나면 Dataflow 스트리밍 작업이 느리게 실행되거나 중단될 수 있습니다.

• 파이프라인에서 소스의 데이터를 읽지 않습니다. 예를 들어 Pub/Sub에서 백로그가 증가하고 있습니다.
• 파이프라인에서 데이터를 싱크에 쓰지 않습니다.
• 데이터 최신 상태 측정항목이 증가하고 있습니다.
• 시스템 지연 시간 측정항목이 증가하고 있습니다.

다음 섹션의 정보를 사용하여 문제를 식별하고 진단합니다.

반복 실패 조사

스트리밍 작업에서 일부 실패가 무한정 재시도됩니다. 이러한 재시도로 인해 파이프라인이 진행되지 않습니다. 반복 실패를 식별하려면 작업자 로그에서 예외를 확인합니다.

• 사용자 코드에 대한 예외이면 코드나 데이터의 문제를 디버깅하고 수정합니다.
• 예기치 않은 실패로 인해 파이프라인이 중단되지 않도록 하려면 데드 레터 큐를 구현합니다. 구현 예시는 Apache Beam 문서의 BigQuery 패턴을 참고하세요.
• 예외가 메모리 부족(OOM) 오류이면 Dataflow의 메모리 부족 오류 문제 해결을 참조하세요.
• 다른 예외는 Dataflow 오류 문제 해결을 참조하세요.

비정상 작업자 식별

스트리밍 작업을 처리하는 작업자가 비정상이면 작업이 느려지거나 중단된 것으로 보일 수 있습니다. 비정상 작업자를 식별하려면 다음 안내를 따르세요.

• 메모리 사용률 측정항목을 사용하고 작업자 로그에서 메모리 부족 오류를 찾아 메모리 부족을 확인합니다. 자세한 내용은 Dataflow의 메모리 부족 오류 문제 해결을 참조하세요.
• Streaming Engine을 사용하는 경우 지속성 측정항목을 사용하여 디스크 입력/출력 작업(IOPS)으로 병목 현상을 식별합니다.
• 작업자 로그에서 다른 오류를 확인합니다. 자세한 내용은 파이프라인 로그 작업 및 Dataflow 오류 문제 해결을 참조하세요.

낙오 항목 식별

낙오 항목은 단계의 다른 작업 항목에 비해 속도가 느린 작업 항목입니다. 낙오 항목을 식별하고 수정하는 방법에 대한 자세한 내용은 스트리밍 작업의 낙오 항목 문제 해결을 참조하세요.

동시 로드 부족 문제 해결

확장성과 효율성을 위해 Dataflow는 여러 작업자를 거쳐 동시에 파이프라인 단계를 실행합니다. Dataflow에서 가장 작은 동시 로드 처리 단위는 키입니다. 통합된 각 단계의 수신 메시지는 키와 연결됩니다. 키는 다음 방법 중 하나로 정의됩니다.

• 키는 Pub/Sub 파티션과 같은 소스 속성을 통해 암시적으로 정의됩니다.
• 키는 파이프라인의 집계 논리(예: GroupByKey)를 통해 명시적으로 정의됩니다.

파이프라인에 지정된 단계의 키가 부족하면 동시 로드 처리가 제한됩니다. 이 단계에서 병목 현상이 발생할 수 있습니다.

동시 로드가 낮은 단계 식별

파이프라인 속도 저하가 낮은 동시 로드로 인해 발생했는지 확인하려면 CPU 사용률 측정항목을 확인합니다. CPU가 낮지만 작업자 간에 고르게 분산된 경우 작업 동시 로드가 부족할 수 있습니다. 작업에서 Streaming Engine을 사용하는 경우 스테이지에 동시 로드가 낮은지 확인하려면 작업 측정항목 탭에서 동시 로드 측정항목을 봅니다. 이러한 문제를 방지하는 대책은 다음과 같습니다.

• Google Cloud 콘솔의 작업 정보 페이지에서 자동 확장 탭을 사용하여 작업에 수직 확장되는 문제가 있는지 확인합니다. 자동 확장이 문제인 경우 Dataflow 자동 확장 문제 해결을 참조하세요.
• 작업 그래프를 사용하여 단계의 단계를 확인합니다. 단계를 소스에서 읽거나 싱크에 쓰는 경우 소스나 싱크의 서비스에 대한 문서를 검토합니다. 문서를 사용하여 서비스가 충분히 확장될 수 있도록 구성되었는지 확인합니다.
  • 자세한 정보를 수집하려면 Dataflow에서 제공하는 입력 및 출력 측정항목을 사용합니다.
  • Kafta를 사용하는 경우 Kafka 파티션 수를 확인합니다. 자세한 내용은 Apache Kafka 문서를 참고하세요.
  • BigQuery 싱크를 사용하는 경우 자동 샤딩을 사용 설정하여 동시 로드를 향상시킵니다. 자세한 내용은 BigQuery용 자동 샤딩으로 Dataflow 처리량 3배를 참조하세요.

핫 키 확인

태스크가 작업자 간에 균일하지 않게 분산되고 작업자 사용률이 매우 균일하지 않은 경우 파이프라인에 핫 키가 있을 수 있습니다. 핫 키는 다른 키와 달리 처리할 요소가 훨씬 더 많은 키입니다. 이 문제를 해결하려면 다음 단계 중 하나 이상을 수행합니다.

• 데이터를 다시 입력하세요. 새 키-값 쌍을 출력하려면 ParDo 변환을 적용합니다. 자세한 내용은 Apache Beam 문서의 Java ParDo 변환 페이지 또는 Python ParDo 변환 페이지를 참고하세요.
• 결합 변환에서 .withFanout을 사용합니다. 자세한 내용은 Java SDK의 Combine.PerKey 클래스 또는 Python SDK의 with_hot_key_fanout 작업을 참고하세요.
• 바인딩되지 않은 대용량 PCollections을 처리하는 Java 파이프라인이 있는 경우 다음을 수행하는 것이 좋습니다.
  • Combine.Globally 대신 Combine.Globally.withFanout을 사용하세요.
  • Count.PerKey 대신 Combine.PerKey.withHotKeyFanout을 사용하세요.

할당량 부족 확인

소스와 싱크의 할당량이 충분한지 확인합니다. 예를 들어 파이프라인이 Pub/Sub 또는 BigQuery에서 입력을 읽는 경우 Google Cloud 프로젝트의 할당량이 부족할 수 있습니다. 이러한 서비스의 할당량 한도에 대한 자세한 내용은 Pub/Sub 할당량 또는 BigQuery 할당량을 참조하세요.

작업에서 429 (Rate Limit Exceeded) 오류가 다수 발생하면 할당량이 부족할 수 있습니다. 오류를 확인하려면 다음 단계를 시도해 봅니다.

1. Google Cloud 콘솔로 이동합니다.
2. 탐색창에서 API 및 서비스를 클릭합니다.
3. 메뉴에서 라이브러리를 클릭합니다.
4. 검색창을 사용하여 Pub/Sub을 검색합니다.
5. Cloud Pub/Sub API를 클릭합니다.
6. 관리를 클릭합니다.
7. 응답 코드별 트래픽 차트에서 (4xx) 클라이언트 오류 코드를 찾습니다.

측정항목 탐색기를 사용하여 할당량 사용량을 확인할 수도 있습니다. 파이프라인에서 BigQuery 소스나 싱크를 사용하는 경우 할당량 문제를 해결하려면 BigQuery Storage API 측정항목을 사용합니다. 예를 들어 BigQuery 동시 연결 수를 보여주는 차트를 만들려면 다음 단계를 수행합니다.

1. Google Cloud 콘솔에서 Monitoring을 선택합니다.

   Monitoring으로 이동

2. 탐색 창에서 측정항목 탐색기를 선택합니다.

3. 측정항목 선택 창의 측정항목에서 BigQuery 프로젝트 > 쓰기 > 동시 연결 수를 필터링합니다.

Pub/Sub 측정항목 보기에 대한 자세한 내용은 'Cloud Monitoring에서 Pub/Sub 모니터링'의 할당량 사용량 모니터링을 참조하세요. BigQuery 측정항목 보기에 대한 자세한 내용은 '대시보드, 차트, 알림 만들기'의 할당량 사용량 및 한도 보기를 참조하세요.

Batch

일괄 작업이 느리거나 중단된 경우 실행 세부정보 탭을 사용하여 작업에 대한 자세한 정보를 확인하고 병목 현상을 일으키는 단계나 작업자를 식별합니다.

낙오 항목 식별

낙오 항목은 단계의 다른 작업 항목에 비해 속도가 느린 작업 항목입니다. 낙오 항목을 식별하고 수정하는 방법에 대한 자세한 내용은 일괄 작업의 낙오 항목 문제 해결을 참조하세요.

느리거나 중단된 단계 식별

느리거나 중단된 단계를 식별하려면 단계 진행 뷰를 사용합니다. 막대가 길수록 단계에서 시간이 오래 걸린다는 의미입니다. 이 뷰를 사용하여 파이프라인에서 가장 느린 단계를 식별합니다.

병목 현상 단계를 찾으면 다음 단계를 수행할 수 있습니다.

• 해당 단계에서 느린 작업자를 식별합니다.
• 느린 작업자가 없으면 단계 정보 패널을 사용하여 가장 느린 단계를 식별합니다. 이 정보를 사용하여 사용자 코드 최적화를 위한 조합을 식별합니다.
• 동시 로드 병목 현상을 찾으려면 Dataflow 모니터링 측정항목을 사용합니다.

느린 작업자 식별

특정 단계에서 느린 작업자를 식별하려면 작업자 진행 상황 뷰를 사용합니다. 이 뷰는 단계가 끝날 때까지 모든 작업자가 작업을 처리하는지 또는 단일 작업자가 느린 태스크에서 중단되었는지 여부를 보여줍니다. 느린 작업자를 찾으면 다음 단계를 수행합니다.

• 해당 작업자의 로그 파일을 봅니다. 자세한 내용은 파이프라인 로그 모니터링 및 보기를 참조하세요.
• 느린 작업자의 CPU 사용률 측정항목 및 작업자 진행 상황 세부정보를 봅니다. 해당 작업자의 로그 파일에서 CPU 사용률이 비정상적으로 높거나 낮은 경우 다음 문제를 확인합니다.
  • A hot key ... was detected
  • Processing stuck ... Operation ongoing

디버깅 도구

파이프라인이 느리거나 중단되면 다음 도구를 사용하여 문제를 진단할 수 있습니다.

• 이슈의 상관관계를 찾고 병목 현상을 식별하려면 Dataflow용 Cloud Monitoring을 사용합니다.
• 파이프라인 성능을 모니터링하려면 Cloud Profiler를 사용합니다.
• 일부 변환은 대용량 파이프라인에 더 적합합니다. 로그 메시지는 일괄 또는 스트리밍 파이프라인에서 중단된 사용자 변환을 식별할 수 있습니다.
• 중단된 작업을 자세히 알아보려면 Dataflow 작업 측정항목을 사용합니다. 다음 목록에는 유용한 측정항목이 포함되어 있습니다.
  • 백로그 바이트 측정항목(backlog_bytes)은 처리되지 않은 입력 양을 단계별로 측정합니다(바이트 단위). 이 측정항목을 사용하여 처리량이 없는 통합 단계를 찾습니다. 마찬가지로 백로그 요소 측정항목(backlog_elements)은 한 단계에서 처리되지 않은 입력 요소 수를 측정합니다.
  • 동시 로드 키 처리(processing_parallelism_keys) 측정항목은 지난 5분 동안 파이프라인의 특정 단계에 대한 동시 로드 처리 키 수를 측정합니다. 이 측정항목을 사용하여 다음 방법으로 조사합니다.
    • 문제 범위를 특정 단계로 좁히고 핫 키 경고(예: A hot key ... was detected)를 확인합니다.
    • 동시 로드 부족으로 인한 처리량 병목 현상을 찾습니다. 이러한 병목 현상으로 인해 파이프라인이 느려지거나 중단될 수 있습니다.
  • 시스템 지연 측정항목(system_lag)과 단계별 시스템 지연 측정항목(per_stage_system_lag)은 데이터 항목이 처리 중이거나 처리 대기 중인 최대 시간을 측정합니다. 이러한 측정항목을 사용하여 데이터 소스에서 비효율적인 단계와 병목 현상을 식별합니다.

Dataflow 모니터링 웹 인터페이스에 포함되지 않은 추가 측정항목은 Google Cloud 측정항목의 전체 Dataflow 측정항목 목록을 참조하세요.