이 페이지에서는 코드 개발을 시작하기 전에 데이터 파이프라인을 계획할 때 고려해야 하는 중요한 사항들에 대해 설명합니다. 데이터 파이프라인은 데이터를 한 시스템에서 다른 시스템으로 이동하며 비즈니스 정보 시스템의 중요한 구성요소입니다. 데이터 파이프라인의 성능과 안정성은 이러한 광범위한 시스템과 비즈니스 요구사항을 얼마나 효과적으로 충족하는지에 영향을 미칠 수 있습니다.
데이터 파이프라인을 개발하기 전에 계획하면 성능과 안정성을 향상시킬 수 있습니다. 이 페이지에서는 다음을 포함하여 Dataflow 파이프라인의 다양한 계획 고려사항을 설명합니다.
- 측정 가능성 표준을 비롯한 파이프라인의 성능 기대치
- 데이터 소스, 싱크 및 기타 연결된 시스템과 파이프라인 통합
- 파이프라인, 소스, 싱크의 지역화
- 보안(예: 데이터 암호화, 비공개 네트워킹)
SLO 정의 및 측정
성능의 중요한 척도는 파이프라인이 비즈니스 요구사항을 얼마나 잘 충족하는가입니다. 서비스 수준 목표(SLO)는 허용 가능한 기준점과 비교할 수 있는 명확한 성능의 정의를 제공합니다. 예시적으로 시스템에 다음과 같이 SLO를 정의할 수 있습니다.
데이터 최신 상태: 3분 이내에 발생한 사용자 웹사이트 활동에서 제품 추천의 90%를 생성한다.
데이터 정확성: 한 달 이내에 고객 인보이스의 0.5% 미만에서만 오류를 포함한다.
데이터 격리/부하 분산: 영업일 기준으로 우선순위가 높은 모든 결제는 처리 후 10분 이내에 처리하고 표준 우선순위 결제는 다음 영업일까지 완료한다.
서비스 수준 지표(SLI)를 사용하여 SLO 규정 준수를 측정할 수 있습니다. SLI는 시스템이 지정된 SLO를 얼마나 잘 충족하는지를 나타내는 수치화 가능한 측정항목입니다. 예를 들어 가장 최근에 처리된 사용자 활동의 연령을 SLI로 사용하여 데이터 최신 상태 SLO 예시를 측정할 수 있습니다. 파이프라인이 사용자 활동 이벤트에서 추천을 생성하고 SLI가 이벤트 시간과 이벤트 처리 시간 사이의 4분 지연을 보고하는 경우 추천은 4분 이전의 사용자 웹사이트 활동을 고려하지 않습니다. 스트리밍 데이터를 처리하는 파이프라인이 4분의 시스템 지연 시간을 초과하면 SLO가 충족되지 않는다는 것을 알 수 있습니다.
파이프라인 이외의 시스템 구성요소는 SLO에 영향을 미치므로 포괄적인 시스템 상태를 설명하는 측정항목을 포함하여 최종 성능을 설명하는 측정항목 등 파이프라인 자체의 성능 외에 시스템의 전체 성능을 설명하는 다양한 SLI를 캡처하는 것이 중요합니다. 예를 들어 Dataflow 파이프라인은 허용 가능한 지연 시간을 포함하여 결과를 계산할 수 있지만 더 넓은 SLO에 영향을 주는 다운스트림 시스템에서 성능 문제가 발생할 수 있습니다.
고려해야 할 중요한 SLO에 대한 상세 정보는 사이트 안정성 엔지니어링 책을 참조하세요.
데이터 최신 상태
데이터 최신 상태란 데이터의 기간과 관련된 사용성을 의미합니다. 다음 데이터 최신 상태 SLO는 사이트 안정성 엔지니어링 책에서 가장 일반적인 파이프라인 데이터 최신 상태 SLO 형식으로 언급됩니다.
Y[초, 일, 분]에 처리된 데이터의 X% 이 SLO는 특정 기간 동안 처리된 데이터의 비율을 나타냅니다. 일반적으로 제한된 데이터 소스를 처리하는 일괄 파이프라인에 사용됩니다. 이 SLO 유형에 대한 측정항목은 경과된 파이프라인 런타임과 관련된 주요 처리 단계에서의 입력 및 출력 데이터 크기입니다. 입력 데이터 세트를 읽는 단계와 각 입력 항목을 처리하는 다른 단계를 선택할 수 있습니다. SLO의 예시로는 'Shave the Yak 게임의 경우 플레이어 점수에 영향을 미치는 사용자 활동의 99%를 매치 완료 후 30분 내에 처리한다'가 있습니다.
가장 오래된 데이터는 X[초, 일, 분] 이전이어야 함: 이 SLO는 파이프라인에서 데이터가 생성된 시기를 참조합니다. 일반적으로 제한되지 않은 소스의 데이터를 처리하는 스트리밍 파이프라인에 사용됩니다. 이 유형의 SLO에서는 파이프라인이 데이터를 처리하는 데 걸리는 시간을 나타내는 측정항목을 사용합니다. 가능한 두 가지 측정항목은 처리되지 않은 가장 오래된 항목의 생성 시기(처리되지 않은 항목이 큐에 있는 기간) 또는 가장 최근에 처리된 항목의 생성 시기입니다. SLO의 예시는 '제품 추천은 5분 이내의 사용자 활동에서 생성된다.'입니다.
파이프라인 작업이 X[초, 일, 분]내에 완료됨: 이 SLO는 성공적인 완료 기한을 설정하며 일반적으로 제한된 데이터 소스의 데이터를 처리하는 일괄 파이프라인에 사용됩니다. 이 SLO에는 작업 성공을 나타내는 다른 신호(예: 오류가 발생한 처리된 요소의 비율) 외에도 파이프라인 경과 시간 및 작업 완료 상태가 필요합니다. SLO의 예시로는 '현재 영업일의 고객 주문은 다음 날 오전 9시까지 처리된다.'가 있습니다.
Cloud Monitoring을 사용하여 데이터 최신 상태를 측정하는 방법은 Dataflow 작업 측정항목을 참조하세요.
데이터 정확성
데이터 정확성이란 오류가 없는 데이터를 말합니다. 다음을 포함하여 다양한 방법으로 데이터 정확성을 결정할 수 있습니다.
엔드 투 엔드 파이프라인 테스트: 파이프라인이 단위 테스트와 통합 테스트를 성공적으로 통과한 후에 사전 프로덕션 환경에서 실행할 수 있습니다. 지속적 배포를 사용하여 엔드 투 엔드 파이프라인 테스트를 자동화할 수 있습니다.
프로덕션에서 실행되는 파이프라인: 모니터링을 사용하여 데이터 정확성과 관련된 측정항목을 관찰할 때에 해당합니다.
파이프라인을 실행하는 경우 일반적으로 데이터 정확성 목표를 정의하려면 일정 기간 동안 정확성을 측정해야 합니다. 예를 들면 다음과 같습니다.
- 작업별 기준으로 입력 항목의 X% 미만에 데이터 오류가 있습니다. 이 SLO를 사용하여 일괄 파이프라인의 데이터 정확성을 측정할 수 있습니다. SLO의 예시로는 '전기 측정기 측정값을 처리하는 일일 일괄 작업에서 측정값 3% 미만에 데이터 입력 오류가 있다.'가 있습니다.
- X분 이동 구간에서 입력 항목의 Y% 미만에 데이터 오류가 있습니다. 이 SLO를 사용하여 스트리밍 파이프라인의 데이터 정확성을 측정할 수 있습니다. SLO의 예시로는 '지난 1시간 동안 전기 측정기 측정값의 2% 미만에 음수 값이 포함된다."가 있습니다.
이러한 SLO를 측정하려면 적절한 기간 동안 측정항목을 사용하여 유형별로 오류 수를 누적하세요. 오류 유형의 예시로는 잘못된 스키마로 인해 데이터가 잘못되었거나 데이터가 유효한 범위 외부에 있는 경우가 있습니다.
Cloud Monitoring을 사용하여 데이터 정확성을 측정하는 방법은 Dataflow 작업 측정항목을 참조하세요.
데이터 격리 및 부하 분산
데이터 격리는 속성별로 데이터를 세분화하여 부하 분산을 더 쉽게 수행할 수 있습니다. 예를 들어 온라인 결제 처리 플랫폼에서는 개별 결제가 표준 우선순위 또는 높은 우선순위가 되도록 데이터를 분류할 수 있습니다. 그런 다음 파이프라인은 부하 분산을 사용하여 높은 우선순위 결제가 표준 우선순위 결제보다 먼저 처리되도록 할 수 있습니다.
결제 처리를 위해 다음 SLO를 정의한다고 가정해 보겠습니다.
- 높은 우선순위 결제는 10분 이내에 처리됩니다.
- 표준 우선순위 결제는 다음 영업일 오전 9시까지 처리됩니다.
결제 플랫폼이 이러한 SLO를 준수하는 경우 고객은 보고서 대시보드에서 완료된 높은 우선순위 결제를 확인할 수 있습니다. 반면 표준 결제는 다음 날까지 대시보드에 표시되지 않을 수 있습니다.
이 예시 시나리오에는 다음과 같은 옵션이 있습니다.
- 단일 파이프라인을 실행하여 표준 우선순위 및 높은 우선순위 결제를 모두 처리합니다.
- 여러 파이프라인 간의 우선순위에 따라 데이터를 격리하고 부하 분산을 수행합니다.
다음 섹션에서는 각 옵션에 대해 자세히 설명합니다.
단일 파이프라인을 사용하여 혼합 SLO에 제공
다음 다이어그램은 높은 우선순위 및 표준 우선순위 결제를 처리하는 데 사용되는 단일 파이프라인을 보여줍니다. 파이프라인은 스트리밍 데이터 소스(예: Pub/Sub 주제 또는 Apache Kafka 주제)에서 새 결제 알림을 수신합니다. 그런 다음 결제를 즉시 처리하고 스트리밍 삽입을 사용하여 BigQuery에 이벤트를 씁니다.
단일 파이프라인의 이점은 단일 데이터 소스 및 파이프라인만 관리하여 운영 요구사항을 간소화할 수 있다는 점입니다. Dataflow는 자동 미세 조정 기능을 사용하여 작업을 최대한 빠르고 효율적으로 실행합니다.
단일 파이프라인의 단점은 공유 파이프라인이 표준 우선순위 결제보다 높은 우선순위 결제를 우선할 수 없으며 파이프라인 리소스가 두 결제 유형 간에 공유된다는 점입니다. 앞에서 설명한 비즈니스 시나리오에서 파이프라인은 두 SLO 중 더 엄격한 SLO를 유지해야 합니다. 즉, 파이프라인은 처리된 결제의 실제 우선순위와 관계없이 높은 우선순위 결제에 SLO를 사용해야 합니다. 또 다른 단점은 작업 백로그의 경우 스트리밍 파이프라인이 작업의 긴급성에 따라 백로그 처리의 우선순위를 지정할 수 없다는 점입니다.
특정 SLO에 맞춤화된 여러 파이프라인 사용
리소스를 격리하고 특정 SLO를 충족하기 위해 두 개의 파이프라인을 사용할 수 있습니다. 다음 다이어그램은 이 접근 방식을 보여줍니다.
높은 우선순위 결제는 우선순위가 지정된 처리를 위해 스트리밍 파이프라인에 격리됩니다. 표준 우선순위 결제는 매일 실행되고 BigQuery 로드 작업을 사용하여 처리된 결과를 작성하는 일괄 파이프라인으로 처리됩니다.
데이터를 서로 다른 파이프라인에 격리하면 이점이 있습니다. 더 엄격한 SLO에 대한 높은 우선순위 결제를 제공하려면 우선순위가 높은 결제 전용 파이프라인에 더 많은 리소스를 할당하여 처리 시간을 단축할 수 있습니다. 리소스 구성에는 Dataflow 작업자 추가, 더 큰 머신 사용, 자동 확장 설정이 포함됩니다. 높은 우선순위 항목을 별도의 처리 큐에 격리하면 표준 우선순위 결제가 갑자기 증가하는 경우 처리 지연을 완화할 수 있습니다.
여러 파이프라인을 사용하여 일괄 및 스트리밍 소스에서 데이터를 격리하고 부하 분산하는 경우 Apache Beam 프로그래밍 모델에서는 높은 우선순위(스트리밍) 파이프라인과 표준 우선순위(일괄) 파이프라인이 동일한 코드를 공유할 수 있습니다. 유일한 예외는 일괄 파이프라인의 제한된 소스에서 읽는 초기 읽기 변환입니다. 자세한 내용은 재사용 가능한 변환 라이브러리 만들기를 참조하세요.
데이터 소스 및 싱크를 위한 계획
데이터를 처리하려면 데이터 파이프라인을 다른 시스템과 통합해야 합니다. 이러한 시스템을 소스 및 싱크라고 합니다. 데이터 파이프라인은 소스에서 데이터를 읽어 싱크에 씁니다. 소스 및 싱크 외에도 데이터 파이프라인은 처리 단계 내에서 데이터 보강, 필터링 또는 외부 비즈니스 로직 호출을 위해 외부 시스템과 상호작용할 수 있습니다.
확장성을 위해 Dataflow는 여러 작업자를 거쳐 동시에 파이프라인 단계를 실행합니다. 파이프라인 코드 및 Dataflow 서비스 외부의 요인도 파이프라인의 확장성에 영향을 줍니다. 이러한 요인은 다음이 포함될 수 있습니다.
외부 시스템 확장성: 파이프라인이 상호작용하는 외부 시스템으로 성능을 제한하고 확장성의 상한을 형성할 수 있습니다. 예를 들어 필요한 읽기 처리량에 대한 파티션 수가 부족한 Apache Kafka 주제가 파이프라인 성능에 영향을 줄 수 있습니다. 파이프라인 및 구성요소가 성능 목표를 충족하는지 확인하려면 사용 중인 외부 시스템의 권장사항 문서를 참조하세요. 기본 제공되는 확장성을 제공하는 Google Cloud 서비스를 사용하여 인프라 용량 계획을 간소화할 수도 있습니다. 자세한 내용은 이 페이지의 Google Cloud 관리형 소스 및 싱크 사용을 참조하세요.
데이터 형식 선택: 특정 데이터 형식을 다른 형식보다 더 빠르게 읽을 수 있습니다. 예를 들어 Avro와 같이 동시에 로드할 수 있는 읽기를 지원하는 데이터 형식을 사용하면 일반적으로 필드에 줄바꿈이 삽입된 CSV 파일을 사용하는 것보다 빠르고, 압축된 파일을 사용하는 것보다 더 빠릅니다.
데이터 위치 및 네트워크 토폴로지: 데이터 파이프라인과 관련하여 데이터 소스 및 싱크의 지리적 근접성과 네트워킹 특성이 성능에 영향을 줄 수 있습니다. 자세한 내용은 이 페이지의 리전 고려사항을 참조하세요.
외부 서비스 호출
파이프라인에서 외부 서비스를 호출하면 호출당 오버헤드가 발생하므로 파이프라인의 성능과 효율성이 떨어질 수 있습니다. 데이터 파이프라인이 외부 서비스를 호출하는 경우 오버헤드를 줄이려면 가능한 경우 여러 데이터 요소를 단일 요청으로 일괄 처리합니다. 기본 Apache Beam I/O 변환에서 BigQueryIO 및 스트리밍 삽입 작업을 포함하여 이러한 작업을 자동으로 수행합니다. 일부 외부 서비스는 용량 한도 외에도 일정 기간 동안 총 호출 수(예: 일일 할당량)를 제한하거나 호출 속도(예: 초당 요청 수)를 제한하는 할당량도 적용합니다.
Dataflow는 여러 작업자에 걸쳐 작업을 병렬화하므로 트래픽이 너무 많으면 외부 서비스에 부담을 주거나 사용 가능한 할당량이 소진될 수 있습니다. 자동 확장을 사용하는 경우 Dataflow는 외부 호출과 같이 느린 단계를 실행하는 작업자를 추가하여 보완을 시도할 수 있습니다. 작업자를 추가하면 외부 시스템에 더 많은 부담이 발생할 수 있습니다. 외부 시스템이 예상 부하 요구사항을 지원하거나 파이프라인의 트래픽을 지속 가능한 수준으로 제한할 수 있는지 확인합니다. 자세한 내용은 외부 서비스에 배치 크기 및 동시 호출 제한을 참조하세요.
Google Cloud 관리형 소스 및 싱크 사용
Google Cloud 관리형 서비스를 Dataflow 파이프라인과 함께 사용하면 대부분의 요구 사항을 충족하는 확장성, 일관된 성능, 할당량, 한도를 제공하므로 용량 관리의 복잡성을 해결할 수 있습니다. 하지만 파이프라인 작업에 대한 서로 다른 할당량과 한도를 알고 있어야 합니다. Dataflow 자체에 할당량 및 한도가 적용됩니다. Google Cloud 지원팀에 문의하여 일부 한도를 늘릴 수 있습니다.
Dataflow는 Compute Engine VM 인스턴스를 사용하여 작업을 실행하므로 충분한 Compute Engine 할당량이 필요합니다. Compute Engine 할당량이 부족하면 파이프라인 자동 확장 처리가 방해를 받거나 작업이 시작되지 않을 수 있습니다.
이 섹션의 나머지 부분에서는 다양한 Google Cloud 할당량 및 한도가 파이프라인의 설계, 개발, 모니터링에 미치는 영향을 살펴봅니다. Pub/Sub 및 BigQuery는 파이프라인 소스 및 싱크의 예시로 사용됩니다.
예시 1: Pub/Sub
Pub/Sub를 Dataflow와 함께 사용하면 Pub/Sub는 스트리밍 데이터 파이프라인에서 메시지를 주고받을 수 있는 확장 가능하고 내구성이 뛰어난 이벤트 수집 서비스를 제공합니다. Google Cloud 콘솔을 사용하여 Pub/Sub 할당량 소비를 열람하고 할당량 한도를 늘릴 수 있습니다. 프로젝트별 할당량 및 한도를 초과하는 단일 파이프라인이 있는 경우 할당량을 늘려달라고 요청하는 것이 좋습니다.
Pub/Sub 할당량 및 한도는 프로젝트 수준 사용을 기준으로 설계됩니다. 구체적으로 서로 다른 프로젝트의 게시자 및 구독자에게는 독립적인 데이터 처리량 할당량이 부여됩니다. 여러 파이프라인이 단일 주제를 게시하거나 구독하는 경우 각 파이프라인을 자체 프로젝트에 배포하여 해당 주제에 허용되는 최대 처리량을 얻을 수 있습니다. 이 구성에서 각 파이프라인은 서로 다른 프로젝트 기반 서비스 계정을 사용하여 메시지를 사용하고 게시합니다.
다음 다이어그램에서 파이프라인 1과 파이프라인 2는 프로젝트 A에 제공되는 것과 동일한 구독자 및 게시자 처리량 할당량을 공유합니다. 반대로 파이프라인 3은 프로젝트 B에 연결된 전체 구독자 및 게시자 처리량 할당량을 사용할 수 있습니다.
여러 파이프라인은 Pub/Sub 주제에 대한 별도의 구독을 사용하여 단일 Pub/Sub 주제에서 읽을 수 있으므로 Dataflow 파이프라인이 다른 구독자(예: 다른 파이프라인)와 관계없이 메시지를 가져오고 확인할 수 있습니다. 이러한 기능이 추가 Pub/Sub 구독을 만들어 파이프라인을 쉽게 클론할 수 있습니다. 추가 구독을 만들면 고가용성을 위한 복제본 파이프라인을 만들고(일반적으로 스트리밍 사용 사례), 동일한 데이터에 대해 추가 테스트 파이프라인을 실행하고 파이프라인 업데이트를 사용 설정하는 데 유용합니다.
예시 2: BigQuery
BigQuery 데이터의 읽기 및 쓰기는 자바, Python, Go를 비롯한 여러 언어로 Apache Beam SDK에서 지원됩니다. 자바를 사용하면 BigQueryIO 클래스가 이 기능을 제공합니다. BigQueryIO는 데이터를 읽는 두 가지 메서드인 EXPORT(테이블 내보내기)와 DIRECT_READ를 지원합니다.
다양한 읽기 메서드는 서로 다른 BigQuery 할당량을 소비합니다.
테이블 내보내기는 기본 읽기 방법이며 다음 다이어그램과 같이 작동합니다.
이 다이어그램은 다음 흐름을 보여줍니다.
- BigQueryIO는 BigQuery 내보내기 요청을 호출하여 테이블 데이터를 내보냅니다. 내보낸 테이블 데이터는 임시 Cloud Storage 위치에 기록됩니다.
- BigQueryIO는 Cloud Storage의 임시 위치에서 테이블 데이터를 읽습니다.
BigQuery 내보내기 요청은 내보내기 할당량에 따라 제한됩니다. 또한 내보내기 요청이 완료되어야 파이프라인이 데이터 처리를 시작할 수 있으므로 작업 실행 시간이 추가됩니다.
반대로, 직접 읽기 방법은 BigQuery Storage API를 사용하여 직접 BigQuery에서 테이블 데이터를 읽습니다. BigQuery Storage API는 gRPC를 사용하여 테이블 행 데이터의 처리량이 높은 읽기 성능을 제공합니다. BigQuery Storage API를 사용하면 내보내기 단계가 필요하지 않으므로 내보내기 할당량 제한이 방지되고 작업 실행 시간이 줄어듭니다.
다음 다이어그램은 BigQuery Storage API를 사용하는 경우의 흐름을 보여줍니다. BigQuery 내보내기 요청을 사용하는 흐름과 달리 이 흐름은 테이블에서 파이프라인으로 데이터를 가져오는 데 하나의 직접 읽기 단계만 있기 때문에 더 간단합니다.
BigQuery 테이블에 데이터를 쓰는 경우에도 자체 할당량에 영향을 미칩니다. BigQuery 로드 작업을 사용하는 일괄 파이프라인은 테이블 및 프로젝트 수준에서 적용되는 서로 다른 BigQuery 로드 작업 할당량을 사용합니다. 마찬가지로 BigQuery 스트리밍 삽입을 사용하는 스트리밍 파이프라인은 BigQuery 스트리밍 삽입 할당량을 사용합니다.
데이터를 읽고 쓰는 데 가장 적합한 방법을 결정하려면 사용 사례를 고려하세요. 예를 들어 테이블에 하루 수천 개의 데이터를 추가하기 위해 BigQuery 로드 작업을 사용하지 마세요. 스트리밍 파이프라인을 사용하여 BigQuery에 거의 실시간 데이터를 씁니다. 스트리밍 파이프라인은 이를 위해 스트리밍 삽입 또는 Storage Write API를 사용해야 합니다.
리전별 고려사항
Dataflow는 여러 Google Cloud 리전에서 관리형 서비스로 제공됩니다. 작업을 실행하는 데 사용할 리전을 선택할 때는 다음 사항을 고려하세요.
- 데이터 소스 및 싱크의 위치
- 데이터 처리 위치의 환경설정 또는 제한 사항
- 특정 리전에서만 제공되는 Dataflow 기능
- 특정 작업의 실행을 관리하는 데 사용되는 리전
- 작업의 작업자에 사용되는 영역
특정 작업의 경우 해당 작업 및 작업자에 사용하는 리전 설정이 다를 수 있습니다. 리전 및 영역 지정 시기를 포함한 자세한 내용은 Dataflow 리전 문서를 참조하세요.
Dataflow 작업을 실행할 리전을 지정하면 고가용성 및 재해 복구를 위한 리전별 고려사항을 계획할 수 있습니다. 자세한 내용은 고가용성 및 지리적 중복성을 참조하세요.
리전
Dataflow 리전은 Apache Beam 그래프 자체에 대한 정보 등 작업과 관련된 메타데이터(예: 변환 이름)를 저장하고 처리합니다. 또한 자동 확장과 같은 작업자 동작도 제어합니다. 리전을 지정하면 보안 및 규정 준수, 데이터 지역, 작업의 리전 내 게재위치 요구사항을 충족하는 데 도움이 됩니다. 가능한 경우 교차 리전 네트워크 호출로 인한 성능 영향을 방지하기 위해 작업과 작업자에 동일한 리전을 사용하는 것이 좋습니다.
Dataflow 작업자
Dataflow 작업은 Dataflow 작업자라고 하는 Compute Engine VM 인스턴스를 사용하여 파이프라인을 실행합니다. Dataflow 작업은 Dataflow 위치가 없는 리전을 포함한 모든 Compute Engine 영역을 작업자에 사용할 수 있습니다. 작업에 작업자 리전을 지정하여 작업자의 리전 배치를 제어할 수 있습니다. 작업자 리전 또는 영역을 지정하려면 다음 안내를 수행하세요.
- gcloud CLI를 사용하여 Dataflow 템플릿에서 작업을 만드는 경우
--worker-region플래그를 사용하여 작업자 리전을 재정의하거나--worker-zone플래그를 사용하여 작업자 영역을 재정의합니다. - Apache Beam 자바 SDK를 사용하여 작업을 만드는 경우, 파이프라인 옵션으로 작업자의 리전과 영역을 설정합니다.
workerRegion을 사용하여 작업자 리전을 재정의하거나workerZone을 사용하여 작업자 영역을 재정의합니다.
네트워크 지연 시간 및 처리량을 개선하려면 데이터 소스 및 싱크와 지리적으로 가까운 리전에 작업자를 만드는 것이 좋습니다. 작업을 만들 때 작업자의 리전이나 영역을 지정하지 않으면 Dataflow는 자동으로 작업의 리전과 동일한 리전에 있는 영역으로 기본 설정됩니다.
Dataflow Shuffle 서비스 또는 Streaming Engine을 사용하지 않는 경우 작업에서 처리한 데이터(예: PCollection 객체에 저장된 데이터)는 사용자 코드가 작업자 외부에서 데이터를 전송하지 않는다고 가정하여 작업의 작업자에 상주합니다. Dataflow Shuffle 서비스 또는 Streaming Engine을 사용 설정한 경우 PCollection 객체로 표시된 분산 데이터 세트를 작업자와 이러한 서비스 간에 전송할 수 있습니다.
데이터 암호화 고려사항
완전 관리형 서비스인 Dataflow는 진행 중인 데이터와 저장 데이터 둘 다에 Google 관리 암호화 키를 사용하여 데이터 파이프라인을 통과하는 데이터를 자동으로 암호화합니다. Google 관리 암호화 키 대신 자체 암호화 키를 관리하는 것이 바람직할 수 있습니다. 이 경우 Dataflow는 Cloud Key Management Service(KMS)를 사용하여 고객 관리 암호화 키(CMEK)를 지원합니다. 또한 클라우드에 호스팅되는 하드웨어 보안 모듈(HSM) 서비스인 Cloud HSM을 사용하여 FIPS 140-2 Level 3 인증 HSM 클러스터에서 암호화 키를 호스팅하고 암호화 작업을 수행할 수 있습니다.
CMEK를 사용할 때 Dataflow는 Cloud KMS 키를 사용하여 기간 설정, 그룹화, 조인과 같은 데이터 키 기반 작업을 제외한 데이터를 암호화합니다. 데이터 키에 개인 식별 정보(PII)와 같은 민감한 정보가 포함된 경우 Dataflow 파이프라인에 들어가기 전에 키를 해싱하거나 변환해야 합니다.
비공개 네트워킹 고려사항
네트워킹 및 보안 요구사항은 Dataflow 작업과 같은 VM 기반 워크로드가 비공개 IP 주소만 사용하도록 요구할 수 있습니다. Dataflow를 사용하면 작업자가 모든 네트워크 통신에 비공개 IP 주소를 사용하도록 지정할 수 있습니다. 공개 IP가 사용 중지된 경우 Dataflow 작업자가 Google API 및 서비스에 연결할 수 있도록 서브네트워크에서 비공개 Google 액세스를 사용 설정해야 합니다.
Dataflow 작업에서 Google Cloud 외부의 네트워크 리소스에 액세스하기 위해 공개 IP가 필요한 경우가 아니라면 Dataflow 작업자에 대해 공개 IP를 사용 중지하는 것이 좋습니다. 공개 IP를 사용 중지하면 Dataflow 작업자는 서브네트워크 외부의 리소스 또는 피어 VPC 네트워크에 액세스할 수 없습니다. 마찬가지로 서브네트워크 또는 피어 VPC 네트워크 외부에서 네트워크 액세스를 통해 VM 작업자에 접근할 수 없습니다.
--usePublicIps 파이프라인 옵션을 사용하여 작업자에게 비공개 IP만 있어야 하는지를 지정하는 방법에 대한 자세한 내용은 파이프라인 옵션을 참조하세요.
다음 단계
- 파이프라인 개발 및 테스트
- 전체 파이프라인 워크플로 설계 알아보기
- Google의 데이터 처리 파이프라인을 위한 사이트 안정성 엔지니어링(SRE) 권장사항 자세히 알아보기