Dataflow 자동 확장 문제 해결

이 페이지에서는 Dataflow 자동 확장 기능을 사용하여 문제를 해결하는 방법을 보여주고 자동 확장 관리 방법에 대한 정보를 제공합니다.

작업이 확장 또는 축소되지 않음

이 섹션에서는 작업자가 확장 또는 축소되지 않도록 방지할 수 있는 시나리오에 대한 정보를 제공합니다.

스트리밍 작업이 확장되지 않음

스트리밍 파이프라인에 백로그가 포함된 경우 작업자가 확장되지 않습니다.

이 문제는 백로그가 몇 분 이상 지속되거나 작업자가 CPU를 20% 미만으로 사용할 때 발생합니다.

일부 경우에는 백로그가 증가하지만 CPU 사용률이 낮습니다. 일부 태스크에는 높은 CPU 사용률이 필요하지 않으므로 작업자를 추가해도 성능이 향상되지 않습니다. 이러한 경우 Dataflow가 확장되지 않습니다. 자세한 내용은 스트리밍 자동 확장을 참조하세요. 이 시나리오는 다음 이유로 발생할 수 있습니다.

파이프라인이 I/O 집약적입니다.
파이프라인이 외부 RPC 호출을 기다리는 중입니다.
핫키로 인해 작업자 CPU 사용률이 고르지 않습니다.
파이프라인에 키가 충분하지 않습니다.

일괄 및 스트리밍 작업이 확장되지 않음

일괄 또는 스트리밍 작업이 예상대로 실행되지만 작업자가 더 필요할 때 작업이 확장되지 않습니다.

이 문제는 다음 이유 중 하나로 발생할 수 있습니다.

스테이징 또는 임시 파일에 액세스할 수 없습니다. 작업에 Cloud Storage 버킷이 사용되는 경우 버킷의 객체를 삭제하는 수명 주기 구성이 버킷에 포함될 수 있습니다. 삭제된 객체에는 스테이징 및 임시 폴더와 파일이 포함됩니다. 파일이 삭제되었는지 확인하려면 버킷에 대해 수명 주기 구성을 확인합니다. 작업 시작 후 스테이징 또는 임시 폴더 또는 파일이 삭제된 경우 새 작업자를 만드는 데 필요한 패키지가 존재하지 않을 수 있습니다. 이 문제를 해결하려면 버킷에서 폴더 및 파일을 다시 만듭니다.
방화벽 규칙은 작업자가 필요한 TCP 포트로 트래픽을 전송 및 수신하지 못하도록 방지합니다. 방화벽 규칙으로 인해 작업자가 시작되지 않을 수 있습니다. Dataflow 작업자가 TCP 포트 12345 및 12346에서 트래픽을 송수신할 수 있어야 합니다. 이 문제의 해결 단계를 포함하여 자세한 내용은 Dataflow 방화벽 규칙을 참조하세요.
커스텀 소스에 NULL 값을 반환하는 getProgress() 메서드가 있습니다. 커스텀 소스를 사용할 때 백로그 측정항목은 커스텀 소스의 getProgress() 메서드의 반환 값을 사용하여 데이터 수집을 시작합니다. getProgress()의 기본 구현은 NULL 값을 반환합니다. 이 문제를 해결하려면 NULL 이외의 값을 반환하도록 커스텀 소스가 기본 getProgress() 메서드를 재정의하는지 확인합니다.
수직 자동 확장으로 트리거된 업데이트는 수평 자동 확장을 일시적으로 비활성화합니다. 자세한 내용은 수평 자동 확장에 대한 영향을 참조하세요.
Python 파이프라인에서 map 작업을 사용 중이고 작업이 확장되지 않은 경우 파이프라인 코드에 Reshuffle 변환을 추가해야 할 수 있습니다. 자세한 내용은 Apache Beam 문서의 Reshuffle을 참조하세요.

스트리밍 작업이 축소되지 않음

스트리밍 작업에서 백로그 및 CPU 사용률이 낮으면 작업자가 축소되지 않습니다. 이 문제는 여러 가지 이유로 발생할 수 있습니다.

작업에 Streaming Engine이 사용되지 않으면 Dataflow가 작업자 간의 영구 디스크 수를 균형적으로 조정합니다. 그 결과 작업자의 영구 디스크가 동일해야 합니다. 예를 들어 100개 디스크와 100개 작업자가 있으면 각 작업자에 하나의 디스크가 포함됩니다. 작업자가 축소되면 작업에 50개 작업자가 포함되고 작업자별로 2개의 영구 디스크가 사용될 수 있습니다. 25개 작업자가 포함되어 작업자당 4개의 영구 디스크가 사용될 때까지 작업이 다시 축소되지 않습니다. 또한 작업자의 최소 숫자는 maxNumWorkers에 할당된 값을 15로 나눈 값입니다. 자세한 내용은 스트리밍 자동 확장 파이프라인의 확장 범위를 참조하세요.
작업에 스트리밍 엔진이 사용될 때 축소 대상은 대상 CPU 사용률 75%를 기준으로 합니다. 이 CPU 사용률을 달성할 수 없으면 축소가 사용 중지됩니다.
작업자 축소 전 백로그 시간 추정값은 최소 2분 동안 10초 미만으로 유지되어야 합니다. 백로그 시간이 변동되면 축소가 사용 중지될 수 있습니다. 또한 처리량이 낮으면 시간 추정값이 왜곡될 수 있습니다.
파이프라인에서 PeriodicImpulse를 사용하면 Dataflow 작업자가 예상한 대로 축소되지 않습니다. 스트리밍 자동 확장에는 PeriodicImpulse 사용이 지원되지 않습니다.

확장 중지

일괄 또는 스트리밍 작업의 확장이 시작되지만 백로그가 남아 있더라도 작업자 확장이 중지됩니다.

이 문제는 할당량 한도에 도달할 때 발생합니다.

Compute Engine 할당량: Dataflow 작업은 프로젝트의 Compute Engine 할당량에 따라 달라집니다. 여러 작업이 실행되는 경우 프로젝트가 Compute Engine 할당량 한도에 도달할 수 있습니다. 이 경우 Dataflow가 작업자 수를 늘리지 못할 수 있습니다.
CPU 할당량: Dataflow 작업은 또한 프로젝트의 CPU 할당량에 따라 달라집니다. 작업자 유형에 CPU가 1개 넘게 사용되는 경우 프로젝트가 CPU 할당량 한도에 도달할 수 있습니다.
외부 IP 주소 할당량: 리소스와 통신을 위해 작업에 외부 IP 주소가 사용되는 경우 작업자 수만큼 많은 외부 IP 주소가 필요합니다. 작업자 수가 확장되면 외부 IP 주소 수도 증가합니다. IP 주소 한도에 도달하면 작업자 확장이 중지됩니다.

또한 선택한 리전에 리소스가 부족하면 리전 또는 프로젝트에 남은 할당량이 있더라도 해당 유형의 새 리소스를 만들 수 없습니다. 예를 들어 us-central1에 외부 IP 주소를 만들 수 있는 할당량이 아직 남아 있지만 해당 리전에 사용 가능한 IP 주소가 없을 수도 있습니다. 자세한 내용은 할당량 및 리소스 가용성을 참조하세요.

이 문제를 해결하려면 할당량 증가를 요청하거나 다른 리전에서 작업을 실행합니다.

작업자 사용률 힌트에는 효과 없음

작업자 사용률 힌트를 설정하지만 자동 확장 동작은 변경되지 않습니다.

이 문제를 이해하려면 작업자 CPU 사용률 차트로 이동하여 작업자 사용률 힌트가 활발하게 사용되고 있는지 확인합니다. 힌트가 사용 중이면 차트에 CPU utilization hint (actively used by autoscaler)가 표시됩니다. 그렇지 않으면 CPU utilization hint (not actively used by autoscaler)가 표시됩니다.

사용률 힌트는 자동 확장에 영향을 미치는 한 가지 요소에 불과합니다. 다음 표에는 자동 확장 처리가 힌트를 적극적으로 사용하지 않을 수 있는 몇 가지 이유가 나와 있습니다.

관찰된 확장 동작	원인	확인할 측정항목
변경사항 없음	최소 또는 최대 작업자 수에 도달했습니다. 작업자 수는 동시에 처리되는 키 수로 제한됩니다. 작업은 외부 RPC에 의해 제한됩니다. 축소 조정이 너무 작거나 Dataflow에서 축소를 감소하고 있습니다. 자세한 내용은 스트리밍 자동 확장 휴리스틱을 참조하세요.	`job/aggregated_worker_utilization` `job/max_worker_instances_limit` `job/min_worker_instances_limit` `job/processing_parallelism_keys` 작업자 오류 로그에 RPC 오류가 보고됨 작업자 로그에 비정상 종료가 보고됨
수직 확장	높은 백로그 또는 지연 시간 목표가 힌트보다 우선시됩니다. 최소 작업자 수가 현재 작업자 수보다 높은 값으로 업데이트되었습니다.	`job/aggregated_worker_utilization` `job/backlog_bytes` `job/backlog_elements` `job/estimated_timer_backlog_processing_time` `job/min_worker_instances_limit`
축소	최대 작업자 수가 현재 작업자 수보다 낮은 값으로 업데이트되었습니다.	`job/aggregated_worker_utilization` `job/max_worker_instances_limit`

자세한 내용은 스트리밍 자동 확장 휴리스틱을 참조하세요.

자동 확장 측정항목의 격차

자동 확장 측정항목에는 짧고 일시적인 격차가 있습니다.

이 문제는 백엔드 태스크가 다시 시작되는 경우에 발생할 수 있습니다. 측정항목에서 이러한 격차는 자동 확장 문제나 스트리밍 작업 상태를 나타내지 않습니다.

CPU가 균일하지 않게 분산됨

작업이 자동 확장될 때 CPU 사용률이 작업자 간에 균일하지 않게 분산됩니다. 일부 작업자의 CPU 사용률, 시스템 지연 시간 또는 데이터 새로고침 상태가 다른 작업자보다 높습니다.

이 문제는 데이터에 핫키가 포함되어 있을 때 발생할 수 있습니다. 단축키는 파이프라인 성능에 부정적인 영향을 주는 요소가 있는 키를 말합니다. 각 키를 단일 작업자가 처리해야 하므로 작업을 작업자 간에 분할할 수 없습니다.

자세한 내용은 핫키 오류 안내를 참조하세요.

상태 읽기를 요청하는 작업 항목이 더 이상 백엔드에서 유효하지 않음

작업자 VM 인스턴스와 스트리밍 파이프라인의 Streaming Engine 태스크 간 통신 중에 다음 오류가 발생합니다.

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

자동 확장 중에 작업자 VM 인스턴스는 여러 Streaming Engine 태스크와 통신하고 각 태스크는 작업자 VM 인스턴스를 여러 개 제공합니다. 항목 키는 작업을 배포하는 데 사용됩니다. 각 태스크와 작업자 VM 인스턴스에는 키 범위 컬렉션이 있으며 이러한 범위의 분포는 동적으로 변경될 수 있습니다. 예를 들어 자동 확장 중에 작업 크기를 조절하면 키 범위 분포가 변경될 수 있습니다. 키 범위가 변경되면 이 오류가 발생할 수 있습니다. 이 오류는 예상된 오류이며 이러한 메시지와 성능이 저하된 파이프라인 간에 상관관계가 없으면 이를 무시할 수 있습니다.

Streaming Engine 리소스 부족

Streaming Engine이 요청된 최소 작업자 수를 할당할 수 없으면 다음 오류가 반환됩니다.

Streaming Engine does not currently have enough resources available to fulfill
the request.

이 문제를 해결하려면 최소 작업자 수를 줄여보세요. 자동 확장 범위 설정을 참조하세요.

스트리밍 자동 확장 파이프라인의 확장 범위

이 섹션에서는 스트리밍 자동 확장 파이프라인의 확장 범위에 대한 세부정보를 제공합니다.

Java

Streaming Engine을 사용하지 않는 스트리밍 자동 확장 작업의 경우 Dataflow 서비스가 각 작업자에게 1~15 사이의 Persistent Disk를 할당합니다. 이러한 할당에 따라 스트리밍 자동 확장 파이프라인에 사용되는 최소 작업자 수는 N/15이고, 여기서 N은 --maxNumWorkers의 값입니다.

스트리밍 엔진을 사용하는 스트리밍 자동 확장 작업의 경우 최소 작업자 수는 1입니다.

Dataflow는 작업자 간의 Persistent Disk 수를 조정합니다. 예를 들어 파이프라인에 안정적인 상태의 작업자 3명 또는 4명이 필요한 경우 --maxNumWorkers=15를 설정할 수 있습니다. 파이프라인은 직원당 15, 8, 5, 4, 3, 2 1개의 Persistent Disk에 각각 1, 2, 3, 4, 5, 8, 15명의 작업자를 사용하여 1명에서 15명 사이의 작업자를 자동으로 확장합니다.

--maxNumWorkers는 1,000개 이하여야 합니다.

Python

Streaming Engine을 사용하지 않는 스트리밍 자동 확장 작업의 경우 Dataflow 서비스가 각 작업자에게 1~15 사이의 Persistent Disk를 할당합니다. 이러한 할당에 따라 스트리밍 자동 확장 파이프라인에 사용되는 최소 작업자 수는 N/15이고, 여기서 N은 --max_num_workers의 값입니다.

스트리밍 엔진을 사용하는 스트리밍 자동 확장 작업의 경우 최소 작업자 수는 1입니다.

Dataflow는 작업자 간의 Persistent Disk 수를 조정합니다. 예를 들어 파이프라인에 안정적인 상태의 작업자 3명 또는 4명이 필요한 경우 --max_num_workers=15를 설정할 수 있습니다. 파이프라인은 직원당 15, 8, 5, 4, 3, 2 1개의 Persistent Disk에 각각 1, 2, 3, 4, 5, 8, 15명의 작업자를 사용하여 1명에서 15명 사이의 작업자를 자동으로 확장합니다.

--max_num_workers는 1,000개 이하여야 합니다.

Go

스트리밍 엔진을 사용하는 스트리밍 자동 확장 작업의 경우 최소 작업자 수는 1입니다.

--max_num_workers는 1,000개 이하여야 합니다.

작업자 스트리밍 자동 확장에 사용할 수 있는 최대 개수

Java

Dataflow는 프로젝트의 Compute Engine 인스턴스 개수 할당량 또는 maxNumWorkers 중 낮은 한도 내에서 작동합니다.

Python

Dataflow는 프로젝트의 Compute Engine 인스턴스 개수 할당량 또는 max_num_workers 중 낮은 한도 내에서 작동합니다.

Go

Dataflow는 프로젝트의 Compute Engine 인스턴스 개수 할당량 또는 max_num_workers 중 낮은 한도 내에서 작동합니다.

자동 확장을 제한하여 청구 영향 감소

자동 확장으로 인해 청구가 증가하지 않도록 하려면 스트리밍 작업에 사용할 수 있는 최대 작업자 수를 제한할 수 있습니다.

Java

--maxNumWorkers를 지정하면 작업을 처리하는 데 사용되는 확장 범위가 제한됩니다.

Python

--max_num_workers를 지정하면 작업을 처리하는 데 사용되는 확장 범위가 제한됩니다.

Go

--max_num_workers를 지정하면 작업을 처리하는 데 사용되는 확장 범위가 제한됩니다.

확장 범위 변경

스트리밍 파이프라인의 확장 범위 변경에 대한 자세한 내용은 자동 확장 범위 설정을 참조하세요.

스트리밍 파이프라인의 자동 확장 사용 중지

스트리밍 파이프라인의 자동 확장을 사용 중지하려면 다음 단계를 수행합니다.

Java

--autoscalingAlgorithm=NONE을 설정합니다. 자세한 내용은 수평 자동 확장 중지를 참조하세요.

Python

--autoscaling_algorithm=NONE을 설정합니다. 자세한 내용은 수평 자동 확장 중지를 참조하세요.

Go

--autoscaling_algorithm=NONE을 설정합니다. 자세한 내용은 수평 자동 확장 중지를 참조하세요.

고정된 작업자 수 사용

Streaming Engine을 사용하지 않는 스트리밍 작업의 경우 기본 동작은 고정된 작업자 수를 사용하는 것입니다. 이러한 파이프라인에 스트리밍 작동 확장을 사용하려면 기본적으로 선택되지 않으므로, 이를 명시적으로 선택해야 합니다.