Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Dataflow에서 유연성과 효율성을 고려한 설계

이 문서에서는 복원력이 우수한 Dataflow 파이프라인을 빌드하기 위한 아키텍처 권장사항인 유연성 및 효율성을 위한 설계 (DFE)를 설명합니다.

엄격한 인프라 제약 조건에서 유연한 리소스 정의로 전환하면 다음과 같은 이점이 있습니다.

컴퓨팅 리소스 확보 가능성 극대화
지역 수요가 많은 기간 동안 원활한 자동 확장을 보장합니다.
파이프라인 출시 지연을 방지하고 용량 병목 현상을 제거합니다.

예를 들어 파이프라인을 한 영역의 특정 머신 유형으로 제한하는 대신(예: us-central1-a에서 n1-standard-4 작업자 필요) 최소 리소스 요구사항(예: vCPU 4개, RAM 16GB)을 설정할 수 있습니다. us-central1-a 또는 N1 머신 시리즈에 일시적인 용량 제약이 발생하는 경우 Dataflow는 다른 영역 및 머신 계열 (예: E2, N2 또는 N2D)에 호환되는 작업자 VM을 자동으로 프로비저닝할 수 있습니다. 이러한 유연성을 통해 제한된 단일 하드웨어 풀을 기다리지 않고 파이프라인을 시작하고 확장할 수 있습니다.

이 문서는 Dataflow 워크로드를 관리하고 파이프라인 안정성, 처리량, 인프라 가용성을 최적화하려는 데이터 엔지니어, 클라우드 설계자, 플랫폼 관리자를 대상으로 합니다.

DFE 개요

Dataflow는 Apache Beam 파이프라인을 실행하기 위해 Compute Engine 가상 머신 (VM) 인스턴스를 동적으로 프로비저닝하는 완전 관리형 서버리스 데이터 처리 서비스입니다. 대규모 일괄 처리 및 스트리밍 파이프라인에서 작업자 풀은 VM 인스턴스 수십 개 또는 수백 개로 자주 확장됩니다.

엄격한 인프라 제약 조건으로 구성된 파이프라인은 수요가 많은 기간에 프로비저닝 지연이 발생할 수 있습니다. 엄격한 제약 조건의 예는 다음과 같습니다.

n1-standard-4과 같은 단일 머신 유형을 하드코딩합니다.
파이프라인을 특정 Compute Engine 영역에 고정

특정 머신 유형 또는 영역에 일시적으로 수요가 많으면 Dataflow에서 컴퓨팅 리소스를 할당할 수 없습니다. 이로 인해 프로비저닝 지연 또는 ZONE_RESOURCE_POOL_EXHAUSTED, RESOURCE_POOL_EXHAUSTED과 같은 오류가 발생할 수 있습니다.

DFE 원칙을 사용하면 파이프라인 아키텍처를 엄격한 정적 인프라 선언에서 유연한 요구사항 기반 리소스 정의로 전환할 수 있습니다. 이러한 유연성을 통해 Dataflow는 Google Cloud에서 다양한 사용 가능한 하드웨어 풀에 컴퓨팅을 동적으로 분산하여 운영 오버헤드를 최소화하면서 컴퓨팅 획득 가능성을 극대화할 수 있습니다.

DFE 권장사항

다음 권장사항을 채택하여 컴퓨팅 획득 가능성을 극대화하고, 자동 확장 응답성을 개선하고, 복원력 있는 파이프라인을 빌드하세요.

자동 VM 선택 사용 설정

작업자 머신 유형 파이프라인 옵션으로 정적 머신 유형을 하드코딩하는 대신 Apache Beam 리소스 힌트와 함께 자동 VM 선택을 사용하세요. 최소 리소스 요구사항 (min_ram 또는 cpu_count)을 지정하면 Dataflow는 자동으로 인스턴스 유연성을 사용 설정하고 호환되는 머신 유형 목록에서 작업자를 프로비저닝합니다.

워크로드 지원:

배치 파이프라인: 리소스 힌트를 지정하면 적합 맞춤 및 자동 VM 선택이 자동으로 사용 설정됩니다.
스트리밍 파이프라인: 적합 맞춤에는 --experiments=enable_streaming_rightfitting 파이프라인 옵션과 수평 자동 확장 (기본적으로 사용 설정됨), Streaming Engine (--enable_streaming_engine)을 설정해야 합니다.

자동 VM 선택을 구성하려면 명령줄 옵션, SDK 파이프라인 옵션 또는 Flex 템플릿 실행 매개변수를 사용하여 파이프라인 수준에서 최소 리소스 요구사항 (min_ram 또는 cpu_count)을 지정합니다. Java 및 Python의 자세한 설정 안내와 코드 예시는 리소스 힌트 사용을 참고하세요.

리전 작업자 배치 사용 (영역 고정 방지)

선택한 리전 내의 정상 영역에 작업자 VM을 동적으로 예약하도록 Dataflow를 구성합니다.

--region 파이프라인 옵션을 지정하고 --zone 및 --worker_zone는 생략합니다. 예를 들면 다음과 같습니다.

--region=us-central1

관리형 서비스를 사용하여 상태 및 셔플 분리

관리형 백엔드 서비스를 사용하지 않는 파이프라인은 작업자 VM 디스크와 메모리에서 직접 셔플 데이터 작업과 스트리밍 상태 스토리지를 실행합니다. 이러한 긴밀한 결합으로 인해 작업자 디스크가 더 커야 하고 워크로드 생존이 특정 VM 인스턴스에 바인딩되므로 용량 제약 조건이 있는 동안 작업자 교체가 더 어려워집니다.

일괄 작업의 경우 Dataflow Shuffle 사용: Dataflow Shuffle은 지원되는 작업자 머신 유형에서 실행되는 일괄 파이프라인에 기본적으로 사용 설정되어 있으며 셔플 작업을 작업자 VM에서 Google에서 관리하는 전용 백엔드 서비스로 오프로드합니다.
스트리밍 작업 - Streaming Engine 사용: Streaming Engine은 작업자 VM에서 특화된 응답성이 높은 백엔드 인프라로 창 상태 스토리지 및 타이머 관리를 오프로드합니다. Apache Beam SDK 2.30.0 이상을 사용하는 파이프라인의 경우 Streaming Engine이 기본적으로 사용 설정됩니다. 명시적으로 사용 설정하려면 --enable_streaming_engine 파이프라인 옵션을 전달합니다.

일괄 파이프라인에 가변형 리소스 예약 (FlexRS) 사용

야간 ETL, 데이터 레이크 수집, 일일 롤업과 같이 시간에 민감하지 않은 배치 워크로드의 경우 가변형 리소스 예약 (FlexRS)을 사용하세요.

FlexRS를 사용 설정하려면 flexRS 목표 파이프라인 옵션을 설정하세요.

Python 파이프라인의 경우: --flexrs_goal=COST_OPTIMIZED
Java 파이프라인의 경우: --flexRSGoal=COST_OPTIMIZED

Flex 템플릿의 유연한 런처 VM 유형 구성

Flex 템플릿을 사용하여 파이프라인을 실행할 때 파이프라인 런처 VM은 기본적으로 e2-standard-2로 설정됩니다. 기본 VM은 대부분의 경우에 작동하지만 용량 제약이 있는 경우 gcloud dataflow flex-template run 명령어를 실행할 때 --launcher-machine-type 옵션을 사용하여 구성을 맞춤설정할 수 있습니다.

gcloud dataflow flex-template run my-job \
    --template-file-gcs-location="gs://my-bucket/template.json" \
    --region="us-central1" \
    --launcher-machine-type="n2-standard-2"

운영 고려사항 및 장단점

DFE 권장사항을 채택하면 컴퓨팅 획득 가능성, 자동 확장 응답성, 운영 안정성이 크게 향상되지만 아키텍처를 설계할 때는 다음 운영 요소와 절충안을 고려하세요.

자동 VM 선택 고려사항

안정성 대 최대 성능: 자동 VM 선택은 최대 실행 성능보다 작업 실행 안정성과 컴퓨팅 획득 가능성을 우선시합니다. Dataflow는 여러 후보 머신 계열 (예: E2, N2, N4, N2D)에서 프로비저닝하므로 런타임 성능과 처리량이 프로비저닝된 머신 계열에 따라 약간 다를 수 있습니다. 엄격한 실행 SLA가 있는 컴퓨팅 집약적 워크로드의 경우 파이프라인을 광범위하게 배포하기 전에 자동 VM 선택으로 파이프라인을 테스트하여 성능 기준을 설정하세요. 워크로드에 특정 하드웨어 플랫폼이나 클럭 속도가 필요하고 용량 제약을 허용할 수 있는 경우 특정 머신 유형을 계속 설정할 수 있습니다.
후보 제품군 전반의 Compute Engine 할당량: 자동 VM 선택은 여러 후보 머신 제품군에서 작업자를 프로비저닝할 수 있으므로 Google Cloud 프로젝트에 타겟 리전의 각 후보 제품군에 대해 충분한 Compute Engine vCPU 및 메모리 할당량이 있는지 확인하세요. 기본 제품군에 용량 부족이 발생하고 프로젝트에 대체 제품군 할당량이 없으면 작업자 프로비저닝이 QUOTA_EXCEEDED 오류와 함께 실패합니다.
스트리밍 파이프라인 필수사항: 스트리밍 파이프라인의 경우 적합 맞춤 및 자동 VM 선택이 기본적으로 사용 설정되지 않습니다. --experiments=enable_streaming_rightfitting를 명시적으로 지정하고 Streaming Engine (--enable_streaming_engine)과 수평 자동 확장이 모두 활성 상태인지 확인해야 합니다.

구성 제외: 다음 표에 나온 기능이나 옵션을 구성하면 자동 VM 선택이 자동으로 우회되거나 지원되지 않습니다.

기능	플래그 또는 구성 옵션	참고
명시적 머신 유형	`--worker_machine_type` 또는 `--machine_type` (Python) `--workerMachineType` (Java)	지정된 머신 유형이 우선하므로 자동 VM 선택이 무시됩니다.
맞춤 디스크 유형, 프로비저닝된 IOPS 또는 처리량	`--disk_type`, `--disk_provisioned_iops` 또는 `--disk_provisioned_throughput_mibps`	자동 VM 선택이 우회됩니다. `--disk_size_gb`를 사용하여 맞춤 디스크 크기를 설정하는 것이 지원됩니다.
최소 CPU 플랫폼	`--min_cpu_platform` (Python) `--minCpuPlatform` (Java)	최소 CPU 플랫폼을 설정하면 자동 VM 선택이 우회됩니다.
컨피덴셜 VM	`--experiments=enable_confidential_compute`	컨피덴셜 VM 인스턴스는 자동 VM 선택에서 지원되지 않습니다.
GPU 또는 TPU 가속기	`--dataflow_service_options=worker_accelerator=...` 또는 `accelerator` 리소스 힌트	자동 VM 선택은 액셀러레이터가 없는 워크로드에만 적용됩니다.
Dataflow Prime	`--dataflow_service_options=enable_prime`	Dataflow Prime은 자동 VM 선택 대신 수직 자동 확장 및 동적 적정 크기 조정을 사용합니다.
Flexible Resource Scheduling(FlexRS)	`--flexrs_goal=COST_OPTIMIZED` (Python) `--flexRSGoal=COST_OPTIMIZED` (Java)	FlexRS는 자체 작업자 풀과 예약 버퍼를 관리합니다.

가변형 리소스 예약 (FlexRS) 절충안

일정 지연 기간: FlexRS는 작업 실행이 시작되기 전에 최대 6시간의 일정 버퍼를 도입할 수 있습니다. 완료 시간 SLA가 엄격하거나 다운스트림 종속 항목이 많은 파이프라인에는 FlexRS를 사용하지 마세요.

리전 배치 및 데이터 지역성

관리 서비스 필수 요건: 리전 작업자 배치는 일괄 작업의 경우 Dataflow Shuffle을 사용하고 스트리밍의 경우 Streaming Engine을 사용하는 작업에만 지원됩니다. 이러한 관리형 백엔드 서비스를 사용하지 않는 작업은 리전 내에서 단일 최적 영역을 선택하는 자동 영역 배치를 사용합니다.
데이터 지역성 및 교차 리전 이그레스: 리전 배치를 사용하면 선택한 리전 내의 사용 가능한 영역에 워커가 분산됩니다. 네트워크 지연 시간을 최소화하고 리전 간 네트워크 이그레스 요금을 방지하려면 모든 데이터 소스와 싱크 (예: Cloud Storage 버킷, BigQuery 데이터 세트, Pub/Sub 주제)가 Dataflow 작업과 동일한 리전에 있어야 합니다.

Compute Engine 예약

예약 선호도: 주문형 Dataflow 작업은 ANY 예약 선호도를 사용하는 일치하는 Compute Engine 예약을 자동으로 사용합니다. 하지만 자동 VM 선택은 특정 이름이 지정된 예약에서 인스턴스를 사용하는 것을 지원하지 않습니다.
일시적인 워크로드에 적합성: Compute Engine 예약은 일반적으로 급증이 발생하기 쉽거나, 자동 확장되거나, 수명이 짧은 일괄 워크로드에는 권장되지 않습니다. 또한 활성 영역 부족 기간에 새 예약을 만들면 주문형 VM 생성과 동일한 용량 제약 조건으로 인해 실패합니다.