일반적인 오류 안내

이 페이지에서는 Cloud Dataflow 작업을 실행할 때 발생할 수 있는 몇 가지 일반적인 오류에 대해 설명하고 이러한 오류에 대처하기 위한 조치 방법을 제안합니다.

작업 메시지:

작업 제출 오류:

작업자 로그(Stackdriver):

작업 메시지

'작업 항목이 4번 실패하여 작업이 실패했습니다.'

하나의 작업이 예외 또는 비정상 종료를 일으켜 작업자 코드가 4번 실패하는 경우 Cloud Dataflow에서 작업이 실패하고 a work item failed 4 times 메시지가 표시됩니다.

4개의 개별 실패에 대해서는 작업의 Stackdriver 로그를 참조하세요. Error-level 또는 Fatal-level 로그 항목을 참조하세요. 이러한 예외 또는 오류가 4개 이상 있을 것입니다.

인코딩 오류, IOExceptions 또는 사용자 코드의 예상치 못한 동작

Apache Beam SDK와 Cloud Dataflow 작업자는 공통적인 타사 구성요소를 사용하며, 이러한 구성요소는 추가적인 종속 항목을 가져옵니다. 버전이 충돌하면 서비스에서 예기치 않은 동작이 발생할 수 있습니다. 코드에서 이러한 패키지를 사용하는 경우 일부 라이브러리가 이후 버전과 호환되지 않으므로 실행하는 시점을 기준으로 범위 내에 있는 것으로 표시되는 버전을 사용해야 할 수도 있습니다. SDK 및 작업자 종속 항목에는 종속 항목 목록과 필요한 버전이 포함되어 있습니다.

잘 실행되었던 작업이 '스테이징된 패키지...에 액세스할 수 없습니다'라는 메시지를 표시하며 실패

스테이징에 사용된 Cloud Storage 버킷에 스테이징된 패키지를 삭제하게 만드는 TTL 설정이 없는지 확인합니다.

작업 제출 오류

'413 요청 엔터티가 너무 큼' / '파이프라인의 직렬화된 JSON 표현 크기가 허용 제한을 초과합니다'

작업 제출 시 JSON 페이로드에 대한 오류가 발생하면 파이프라인의 JSON 표현이 최대 요청 크기(20MB)를 초과했음을 의미합니다. 이러한 오류는 콘솔이나 터미널 창에서 다음 메시지 중 하나로 나타날 수 있습니다.

  • 413 Request Entity Too Large
  • '파이프라인의 직렬화된 JSON 표현 크기가 허용 제한을 초과합니다'
  • '워크플로 작업을 만들지 못함: 잘못된 JSON 페이로드가 수신됨'
  • '워크플로 작업을 만들지 못함: 요청 페이로드가 허용 제한을 초과합니다'

작업 크기는 특히 파이프라인의 JSON 표현과 연관됩니다. 파이프라인이 클수록 요청이 커집니다. Cloud Dataflow는 현재 20MB로 요청 크기를 제한합니다.

파이프라인의 JSON 요청 크기를 예측하려면 다음 옵션을 사용하여 파이프라인을 실행합니다.

자바: SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

자바: SDK 1.x

--dataflowJobFile=< path to output file >

이 명령어는 작업의 JSON 표현을 파일에 작성합니다. 직렬화된 파일 크기로 요청 크기를 가늠할 수 있습니다. 실제 크기는 요청에 포함된 추가 정보로 인해 약간 더 커집니다.

파이프라인의 특정 조건으로 인해 JSON 표현이 제한을 초과할 수 있습니다. 가장 흔한 예는 다음과 같습니다.

  • 대량의 메모리 내 데이터를 포함한 Create 변환
  • 원격 작업자에게 전송하기 위해 직렬화된 큰 DoFn 인스턴스
  • (의도하지 않게) 대량의 데이터가 직렬화되도록 가져오는 익명 내부 클래스 인스턴스로서의 DoFn

이러한 상황을 방지하려면 파이프라인을 재구성하세요.

'작업 그래프가 너무 큽니다. 더 작은 작업 그래프로 다시 시도하거나 작업을 두 개 이상의 작은 작업으로 분할하세요.'

작업의 그래프 크기는 10MB를 초과하면 안 됩니다. 파이프라인의 특정 조건으로 인해 작업 그래프가 제한을 초과할 수 있습니다. 가장 흔한 예는 다음과 같습니다.

  • 대량의 메모리 내 데이터를 포함한 Create 변환
  • 원격 작업자에게 전송하기 위해 직렬화된 큰 DoFn 인스턴스
  • (의도하지 않게) 대량의 데이터가 직렬화되도록 가져오는 익명 내부 클래스 인스턴스로서의 DoFn

이러한 상황을 방지하려면 파이프라인을 재구성하세요.

'splitIntoBundles() 연산자로 생성된 BoundedSource 객체의 총 수가 허용 제한보다 큽니다' 또는 'splitIntoBundles() 연산자로 생성된 BoundedSource 객체의 총 크기가 허용 제한보다 큽니다'

자바: SDK 2.x

TextIO, AvroIO 또는 일부 다른 파일 기반 소스를 통해 아주 많은 수의 파일을 읽는 경우에 이 오류가 발생할 수 있습니다. 구체적인 제한은 소스의 세부 사항에 따라 다르지만(예: AvroIO.Read에 스키마를 포함하면 허용 파일 수가 감소함) 보통 파이프라인 하나에 수만 개 파일 정도입니다.

파이프라인용 커스텀 데이터 소스를 만들고 소스의 splitIntoBundles 메소드가 직렬화 시 20MB 이상을 차지하는 BoundedSource 객체 목록을 반환하는 경우에도 이 오류가 발생할 수 있습니다.

커스텀 소스의 splitIntoBundles() 연산자로 생성된 BoundedSource 객체의 총 크기 제한은 20MB입니다. 생성된 BoundedSource 객체의 총 크기가 20MB 제한보다 작도록 커스텀 BoundedSource 하위 클래스를 수정하여 이 제한을 피할 수 있습니다. 예를 들어 소스가 처음에 분할을 적게 생성하고 동적 작업 리밸런스를 사용하여 필요에 따라 입력을 추가로 분할할 수 있습니다.

자바: SDK 1.x

TextIO, AvroIO 또는 일부 다른 파일 기반 소스를 통해 아주 많은 수의 파일을 읽는 경우에 이 오류가 발생할 수 있습니다. 구체적인 제한은 소스의 세부 사항에 따라 다르지만(예: AvroIO.Read에 스키마를 포함하면 허용 파일 수가 감소함) 보통 파이프라인 하나에 수만 개 파일 정도입니다.

파이프라인용 커스텀 데이터 소스를 만들고 소스의 splitIntoBundles 메소드가 직렬화 시 20MB 이상을 차지하는 BoundedSource 객체 목록을 반환하는 경우에도 이 오류가 발생할 수 있습니다.

커스텀 소스의 splitIntoBundles() 연산자로 생성된 BoundedSource 객체의 총 크기 제한은 20MB입니다. 생성된 BoundedSource 객체의 총 크기가 20MB 제한보다 작도록 커스텀 BoundedSource 하위 클래스를 수정하여 이 제한을 피할 수 있습니다. 예를 들어 소스가 처음에 분할을 적게 생성하고 동적 작업 리밸런스를 사용하여 필요에 따라 입력을 추가로 분할할 수 있습니다.

작업자 로그(Stackdriver)

'처리가 <stack_trace> 단계에서 출력 또는 마침 상태로 완료되지 않고 <time_interval> 이상 <step_id> 단계에 정체되어 있습니다'

Cloud Dataflow가 반환 없이 DoFn을 실행하는 데 소비하는 시간이 <time_interval>에 지정된 시간보다 길 경우 이 메시지가 표시됩니다.

이 오류의 가능한 원인은 두 가지입니다.

  • DoFn 코드 자체가 느리거나, 느린 외부 작업이 완료되기를 기다립니다. 이 경우 경고를 무시할 수 있습니다.
  • 또는 DoFn 코드가 정체되거나 교착 상태가 되거나 처리를 마치는 속도가 비정상적으로 느릴 수 있습니다. 이 경우에 해당된다고 판단된다면 Stackdriver 로그 항목을 확장하여 정체된 코드의 스택 추적을 확인하세요.

파이프라인이 자바 VM을 기반으로 구축된 경우 정체된 코드의 원인을 더 자세히 조사할 수 있습니다(자바 또는 Scala 사용). 다음 단계에 따라 정체된 스레드만이 아닌 전체 JVM의 전체 스레드 덤프를 가져옵니다.

  1. 로그 항목에서 작업자 이름을 기록합니다.
  2. GCP Console의 Compute Engine 섹션에서 기록한 작업자 이름의 Compute Engine 인스턴스를 찾습니다.
  3. SSH를 사용하여 이 이름의 인스턴스에 연결합니다.
  4. 다음 명령어를 실행합니다.

    curl http://localhost:8081/threadz
    

RPC 시간 제한 예외, 'DEADLINE_EXCEEDED' 예외 또는 '서버 응답 없음' 오류

작업을 실행하는 동안 RPC 시간 제한, DEADLINE_EXCEEDED 예외 또는 Server Unresponsive 오류가 발생하면 이는 일반적으로 다음 두 가지 문제 중 하나를 나타냅니다.

  • 작업에 사용된 VPC 네트워크에 방화벽 규칙이 없을 수 있습니다. 방화벽 규칙은 파이프라인 옵션에서 사용자가 지정한 VPC 네트워크의 VM 사이에서 모든 TCP 트래픽을 활성화해야 합니다. 자세한 내용은 네트워크 및 서브네트워크 지정을 참조하세요.

  • 작업이 셔플 바운딩되었습니다. 다음 조치 중 하나 또는 여러 개의 조합을 사용해 보세요.

    자바: SDK 2.x

    • 작업자를 추가합니다. 파이프라인 실행 시 더 높은 값으로 --numWorkers를 설정해 보세요.
    • 작업자에 연결된 디스크 크기를 증가시킵니다. 파이프라인 실행 시 더 높은 값으로 --diskSizeGb를 설정해 보세요.
    • SSD 지원 영구 디스크를 사용합니다. 파이프라인 실행 시 --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd"를 설정해 보세요.

    Python

    • 작업자를 추가합니다. 파이프라인 실행 시 더 높은 값으로 --num_workers를 설정해 보세요.
    • 작업자에 연결된 디스크 크기를 증가시킵니다. 파이프라인 실행 시 더 높은 값으로 --disk_size_gb를 설정해 보세요.
    • SSD 지원 영구 디스크를 사용합니다. 파이프라인 실행 시 --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd"를 설정해 보세요.

    자바: SDK 1.x

    • 작업자를 추가합니다. 파이프라인 실행 시 더 높은 값으로 --numWorkers를 설정해 보세요.
    • 작업자에 연결된 디스크 크기를 증가시킵니다. 파이프라인 실행 시 더 높은 값으로 --diskSizeGb를 설정해 보세요.
    • SSD 지원 영구 디스크를 사용합니다. 파이프라인 실행 시 --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd"를 설정해 보세요.

자바 작업자 하네스에서 Python DoFn으로 전송한 호출이 <error message> 오류와 함께 실패

Python의 DoFn 구현이 실패하고 예외가 발생하는 경우 관련 오류 메시지가 표시됩니다.

Stackdriver 오류 로그를 확장하여 오류 메시지와 역추적을 살펴보세요. 어느 코드가 실패했는지 나타나므로 필요한 경우 수정할 수 있습니다. Apache Beam 또는 Cloud Dataflow의 버그라고 판단되는 경우 버그를 보고하세요.

장치에 남아 있는 공간이 없음

작업에서 대량의 데이터를 셔플하거나 로컬 디스크에 임시 데이터를 쓰는 경우 작업자 영구 스토리지의 여유 공간이 부족해질 수 있습니다.

장치에 남은 공간이 없다는 메시지가 표시되는 경우 관련 파이프라인 옵션을 설정하여 작업자 영구 디스크의 크기를 늘리세요. 자바 작업의 경우 --diskSizeGb 플래그를 사용하세요. Python 작업의 경우 --disk_size_gb를 사용하세요.

'RESOURCE_EXHAUSTED: IO 오류: 디스크에 남아 있는 공간이 없습니다' 등의 디스크 공간 오류

이러한 오류는 일반적으로 작업을 처리하기 위해 할당된 로컬 디스크 공간이 부족함을 나타냅니다. 기본 설정으로 작업을 실행하는 경우 작업이 작업자 3개에서 실행되며 각 작업자에 25GB의 로컬 디스크 공간이 할당되고 자동 확장은 사용되지 않습니다. 기본 설정을 수정하여 작업에 사용할 수 있는 작업자 수를 늘리거나, 작업자당 기본 디스크 크기를 증가시키거나 자동 확장 기능을 사용 설정하는 것이 좋습니다.

셔플러 로그의 '잘못된 요청' 경고

Cloud Dataflow 작업 실행 중 Stackdriver 로그에 다음과 비슷한 일련의 경고가 표시될 수 있습니다.

Unable to update setup work item <step_id> error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id <lease_id>
with expiration time: <timestamp>, now: <timestamp>. Full status: generic::invalid_argument: Http(400) Bad Request

'잘못된 요청' 경고는 처리 지연으로 인해 작업자 상태 정보가 오래되었거나 동기화되지 않는 경우 나타납니다. 이러한 '잘못된 요청' 경고에도 불구하고 Cloud Dataflow 작업은 성공하는 경우가 많습니다. 이 경우 경고를 무시하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.