이 문서에서는 프로덕션에 즉시 사용할 수 있는 파이프라인을 배포하고 업데이트하는 방법을 설명합니다. 이 문서는 Dataflow를 사용하여 데이터 파이프라인의 프로덕션 준비 상태를 개선하는 데 도움이 되는 시리즈 중 하나입니다. 이 시리즈는 Dataflow 파이프라인의 개발, 배포, 모니터링 등을 담당하고 Dataflow 및 Apache Beam에 대한 실무 지식이 있는 기술 관련 사용자를 대상으로 합니다.
이 시리즈의 문서에는 다음과 같은 부분이 포함됩니다.
- 개요
- 데이터 파이프라인 계획
- 데이터 파이프라인 개발 및 테스트
- 데이터 파이프라인 배포(이 문서)
- 데이터 파이프라인 모니터링
소개
파이프라인 개발에는 코드 개발, 테스트, 프로덕션으로 전송과 같은 다양한 단계 및 작업이 포함됩니다. 이 문서에서는 다음을 설명합니다.
- 다양한 환경에 자동화된 빌드, 테스트, 파이프라인 배포를 지원하기 위한 지속적 통합 및 지속적 배포(CI/CD)에 대한 고려사항
- 프로덕션에서 성능 및 리소스 사용률을 최적화하기 위한 Dataflow 기능
- 프로덕션 환경에서 스트리밍 파이프라인을 업데이트하기 위한 접근 방식 및 watchpoint
- 프로덕션에서 파이프라인 안정성을 개선하기 위한 권장사항
지속적 통합(CI)
지속적 통합(CI)에서는 개발자가 코드를 공유 저장소에 자주 병합해야 하므로 자주 업데이트되는 웹 사이트와 같이 많이 변경되는 애플리케이션에 유용합니다. 데이터 파이프라인은 일반적으로 다른 유형의 애플리케이션만큼 변경되지 않지만 CI 방식은 파이프라인 개발에 많은 이점을 제공할 수 있습니다. 예를 들어 테스트 자동화는 결함이 발생할 때 빠른 피드백을 제공하고 회귀가 코드베이스에 입력될 가능성을 줄입니다.
테스트 자동화는 CI의 중요한 부분입니다. 테스트 자동화가 적절한 테스트 범위와 결합된 경우 각 코드 커밋에서 테스트 도구 모음을 엄격하게 실행할 수 있습니다. CI 서버는 Maven과 같은 빌드 자동화 도구와 함께 작동하여 하나 이상의 CI 파이프라인 단계로 테스트 모음을 실행할 수 있습니다. 단위 테스트 및 통합 테스트를 통과한 코드는 파이프라인을 실행할 수 있는 배포 아티팩트로 패키징할 수 있습니다. 이를 통과 빌드라고 합니다.
통과 빌드에서 생성된 배포 아티팩트의 수와 유형은 파이프라인 실행 방법에 따라 다를 수 있습니다. Apache Beam 자바 SDK를 사용하면 파이프라인 코드를 자체 실행 JAR 파일로 패키징할 수 있습니다. 그런 다음 사전 프로덕션 또는 프로덕션 Google Cloud 프로젝트와 같은 배포 환경을 위해 프로젝트에서 호스팅되는 버킷에 JAR 파일을 저장할 수 있습니다. 기본 템플릿(템플릿 실행 유형)을 사용하는 경우 배포 아티팩트에는 JSON 템플릿 파일, 파이프라인의 JAR 파일, 선택적 메타 데이터 템플릿이 포함됩니다. 그런 후 다음 섹션에 설명된 대로 지속적 배포를 사용하여 아티팩트를 여러 배포 환경에 배포할 수 있습니다.
지속적 배포 및 배포(CD)
지속적 배포는 수동으로 시작할 준비가 된 하나 이상의 배포 환경에 배포 아티팩트를 복사합니다. 일반적으로 CI 서버가 빌드한 아티팩트는 엔드 투 엔드 테스트를 실행하기 위해 하나 이상의 사전 프로덕션 환경에 배포됩니다. 엔드 투 엔드 테스트를 모두 통과하면 프로덕션 환경이 업데이트됩니다.
일괄 파이프라인의 경우 지속적 배포를 통해 파이프라인을 새 Dataflow 작업으로 직접 실행할 수 있습니다. 또는 필요한 경우 다른 시스템에서 아티팩트를 사용하여 일괄 작업을 시작할 수 있습니다. 예를 들어 워크플로 내에서 Cloud Composer를 사용하여 일괄 작업을 실행하거나 Cloud Scheduler를 사용하여 일괄 작업을 예약할 수 있습니다.
스트리밍 파이프라인은 일괄 파이프라인보다 더 복잡합니다. 따라서 지속적 배포를 사용하여 자동화하기가 더 어려울 수 있습니다. 예를 들어 기존 스트리밍 파이프라인을 교체하거나 업데이트하는 방법을 결정해야 할 수 있습니다. 파이프라인을 업데이트할 수 없거나 업데이트하지 않을 경우 여러 Dataflow 작업 조정 등과 같은 방법을 사용하여 비즈니스 중단을 최소화하거나 방지할 수 있습니다.
CI/CD에 필요한 ID 및 역할
CI/CD 파이프라인은 다양한 시스템과 상호작용하여 파이프라인을 빌드, 테스트, 배포합니다. 예를 들어 파이프라인은 소스 코드 저장소에 액세스해야 합니다. 이러한 상호작용을 사용 설정하려면 파이프라인에 적절한 ID와 역할이 있어야 합니다. 다음 파이프라인 활동의 경우에는 파이프라인에 특정 ID와 역할이 있어야 할 수도 있습니다.
Google Cloud를 포함한 외부 서비스와 통합 테스트
임시 테스트 또는 시스템 통합 테스트를 실행하기 위해 Direct Runner를 사용하는 경우, 파이프라인은 Google Cloud CLI 사용자 인증 정보를 사용하여 Google Cloud 데이터 소스와 싱크를 사용하거나 GOOGLE_APPLICATION_CREDENTIALS 환경 변수에서 제공하는 사용자 인증 정보를 사용합니다. 파이프라인에서 액세스하는 Google Cloud 리소스의 사용자 인증 정보를 가져오는 데 사용되는 서비스 계정에 충분한 역할과 권한이 부여되었는지 확인합니다.
다른 배포 환경에 아티팩트 배포
가능하면 각 프로젝트에 효과적으로 각 환경에 대해 고유한 사용자 인증 정보를 사용하고, 그에 따라 리소스에 대한 액세스를 제한합니다.
각 프로젝트에 고유한 서비스 계정을 사용하여 스토리지 버킷에 배포 아티팩트를 읽고 쓸 수 있습니다. 파이프라인 실행 유형에 따라 배포 프로세스가 여러 아티팩트를 스테이징해야 할 수도 있습니다. 예를 들어 Dataflow 템플릿을 만들고 스테이징하려면 파이프라인의 템플릿 파일과 같은 파이프라인을 시작하는 데 필요한 배포 아티팩트를 Cloud Storage 버킷에 쓸 수 있어야 합니다.
다른 배포 환경에 파이프라인 배포
가능한 경우 각 프로젝트에 고유한 서비스 계정을 사용하여 Dataflow 자체에 대한 액세스를 포함하여 프로젝트 내의 Google Cloud 리소스에 액세스하고 관리합니다.
Dataflow 작업 만들기 및 관리를 위해 사용하는 서비스 계정은 작업 관리를 위해 충분한 IAM 권한이 있어야 합니다. 서비스 계정에 roles/dataflow.admin 역할을 할당하는 것으로 충분히 작업 관리를 위해 설정된 최소 권한을 부여할 수 있습니다. 이 역할은 작업 생성 및 관리 권한을 부여하지만, 작업 실행 권한을 부여하지 않습니다.
Dataflow 작업 실행을 위해 사용하는 컨트롤러 서비스 계정은 실행 중 Compute Engine 리소스 관리 권한과 Apache Beam 파이프라인 및 Dataflow 서비스 사이의 상호작용 관리 권한이 필요합니다. 컨트롤러 서비스 계정에 roles/dataflow.worker 역할을 할당하는 것으로 충분히 Dataflow 작업 실행을 위해 설정된 최소 권한을 부여할 수 있습니다. 작업에 사용되는 리소스에 따라(예: Pub/Sub 주제에서 읽기), roles/dataflow.worker 역할로 제공되는 것 이외의 추가 권한을 부여해야 할 수 있습니다.
--serviceAccount 파이프라인 옵션을 사용하여 해당 작업에 사용할 사용자 관리 컨트롤러 서비스 계정을 지정합니다. 작업을 성공적으로 실행하기 위해서는 작업 생성을 위해 사용되는 서비스 계정에 사용자 관리 컨트롤러 서비스 계정에 대한 roles/iam.serviceAccountUser 역할을 부여해야 합니다. 작업을 만들 때 컨트롤러 서비스 계정을 지정하지 않으면 Dataflow가 Compute Engine 기본 서비스 계정을 사용하려고 시도합니다.
대신 Compute Engine 기본 서비스 계정에 일반적으로 Dataflow 작업에 필요한 권한보다 더 넓은 권한 집합이 포함되기 때문에 프로덕션 환경에 대해 사용자 관리 컨트롤러 서비스 계정을 지정하는 것이 좋습니다.
프로덕션 시나리오에서는 Dataflow 작업 관리와 컨트롤러 서비스 계정에 대해 별도로 서비스 계정을 사용하는 것이 좋습니다. 이렇게 하면 단일 서비스 계정을 사용할 때와 비교해서 보안이 향상됩니다. 예를 들어 Dataflow 작업 생성을 위해 사용되는 서비스 계정은 데이터 소스 및 싱크에 액세스할 필요가 없거나 파이프라인에서 사용되는 다른 리소스를 사용할 필요가 없을 수 있습니다. 이 시나리오에서는 Dataflow 작업 실행을 위해 사용되는 컨트롤러 서비스 계정에 파이프라인 리소스를 사용할 권한이 부여됩니다. 작업 생성을 위한 다른 서비스 계정에는 Dataflow 작업만 관리(생성 포함)할 수 있는 권한이 부여됩니다.
CI/CD 파이프라인 예시
다음 다이어그램은 데이터 파이프라인의 CI/CD에 대한 일반적이고 도구 제약이 없는 보기를 제공합니다. 또한 이 다이어그램에서는 이전 섹션에서 설명한 개발 작업, 배포 환경, 파이프라인 실행기 사이의 관계를 보여줍니다.
이 다이어그램은 다음 단계를 보여줍니다.
코드 개발: 코드 개발 중에 개발자는 Direct Runner를 사용하여 로컬로 파이프라인 코드를 실행합니다. 또한 개발자는 Dataflow Runner를 사용하여 임시 파이프라인을 실행할 때 샌드박스 환경을 사용합니다.
일반적인 CI/CD 파이프라인에서 개발자가 새 코드를 저장소로 푸시하는 등 소스 제어 시스템을 변경하면 지속적 통합 프로세스가 트리거됩니다.
빌드 및 테스트: 지속적 통합 프로세스는 파이프라인 코드를 컴파일한 다음 Direct Runner를 사용하여 단위 테스트 및 변환 통합 테스트를 실행합니다. 필요한 경우 소규모 테스트 데이터 세트를 사용한 외부 소스 및 싱크와의 통합 테스트를 포함하는 시스템 통합 테스트도 실행할 수 있습니다.
테스트가 성공하면 CI 프로세스가 파이프라인을 실행하기 위해 필요한 배포 아티팩트를 지속적 배포 프로세스에 액세스할 수 있는 위치에 저장합니다. 이러한 배포 아티팩트에는 작업 실행 유형에 따라 JAR 파일, Docker 이미지, 템플릿 메타데이터가 포함될 수 있습니다. 생성된 배포 아티팩트 유형에 따라 Cloud Storage 및 Artifact Registry를 사용하여 서로 다른 아티팩트 유형을 저장할 수 있습니다.
전송 및 배포: 지속적 배포 프로세스는 사전 프로덕션 환경에 배포 아티팩트를 복사하거나 다른 방법으로 해당 환경 내에서 해당 아티팩트를 사용 가능하도록 제공합니다. 개발자는 Dataflow Runner를 사용하여 엔드 투 엔드 테스트를 수동으로 실행하거나 지속적 배포를 사용하여 자동으로 테스트를 시작할 수 있습니다. 일반적으로 지속적 배포 접근 방식은 스트리밍 파이프라인보다 일괄 파이프라인에 사용 설정하는 것이 더 간단합니다. 일괄 파이프라인은 지속적으로 실행되지 않으며 새 출시 버전으로 대체하기가 더 쉽기 때문입니다.
스트리밍 파이프라인을 업데이트하는 프로세스는 단순하거나 복잡할 수 있으며 사전 프로덕션 환경에서 업데이트를 테스트해야 합니다. 업데이트 절차가 버전 간에 항상 일치하지 않을 수 있습니다. 예를 들어 파이프라인은 인플레이스 업데이트가 더 이상 불가능하도록 변경될 수 있습니다. 따라서 지속적 배포를 사용하면 파이프라인 업데이트를 자동화하기 경우가 있을 수 있습니다.
모든 엔드 투 엔드 테스트를 통과하면 지속적 배포 프로세스 중에 배포 아티팩트를 복사하거나 프로덕션 환경에 제공할 수 있습니다. 새 파이프라인이 기존 스트리밍 파이프라인을 업데이트하거나 대체하는 경우 사전 프로덕션 환경에서 테스트된 절차를 사용하여 새 파이프라인을 배포합니다.
비템플릿 작업 실행과 템플릿 작업 실행 비교
개발 환경에서 Apache Beam SDK를 직접 사용하여 Dataflow 작업을 만들 수 있습니다. 이 유형의 작업을 비템플릿 작업이라고 부릅니다. 이 접근 방식은 개발자에게 편리하지만 파이프라인의 개발 작업과 실행 작업은 분리하는 것이 좋습니다. 이렇게 분리하면 템플릿 작업을 사용하여 파이프라인을 스테이징하고 독립 태스크로 실행할 수 있습니다. 템플릿이 스테이징된 다음에는 Google Cloud CLI, Google Cloud Console, Dataflow REST API를 사용해서 비개발자를 포함한 다른 사용자가 템플릿으로부터 작업을 실행할 수 있습니다.
Dataflow는 다음 유형의 작업 템플릿을 제공합니다.
- 기본 템플릿: 개발자는 Apache Beam SDK를 사용하여 파이프라인 코드를 실행하고 JSON 직렬화 실행 그래프를 템플릿으로 저장합니다. Beam SDK는 템플릿 파일을 파이프라인 코드에 필요한 종속 항목과 함께 Cloud Storage 위치에 스테이징합니다.
- Flex 템플릿: 개발자는 Google Cloud CLI를 사용하여 파이프라인을 Docker 이미지로 패키징합니다. 그 다음에는 Artifact Registry에 저장됩니다. Flex 템플릿 사양 파일은 또한 자동으로 생성되며 사용자가 지정한 Cloud Storage 위치에 저장됩니다. Flex 템플릿 사양 파일에는 파이프라인 매개변수와 같이 템플릿 실행 방법을 설명하는 메타데이터가 포함되어 있습니다.
템플릿 유형에 대한 자세한 비교 정보는 기본 템플릿과 Flex 템플릿 사이의 유사성과 차이점 문서를 참조하세요.
링크된 문서에 설명된 Flex 템플릿 기능 외에도 Flex 템플릿은 기본 템플릿에 비해 템플릿 관리 이점을 제공합니다. 기본 템플릿의 경우, JAR 파일과 같은 여러 아티팩트가 Cloud Storage 스테이징 위치에 저장될 수 있지만, 이러한 여러 아티팩트를 관리할 수 있는 기능이 없습니다. 이와 달리 Flex 템플릿은 Docker 이미지 내에 캡슐화되어 있습니다. 이 이미지는 파이프라인에 필요한 모든 종속 항목(Flex 템플릿 사양과 별도)을 Container Registry에서 관리되는 하나의 배포 아티팩트로 패키징합니다. Flex 템플릿에 대해 Docker 이미지 관리 기능을 사용할 수 있습니다. 예를 들어 Container Registry에 pull(및 선택적으로 push) 권한을 부여하여 Flex 템플릿을 안전하게 공유하고, Flex 템플릿의 여러 버전에 대해 Docker 이미지 태그를 사용할 수 있습니다.
개발자는 기본 템플릿 및 Flex 템플릿을 사용하여 템플릿 프로젝트와 다른 프로젝트 작업을 실행할 수 있습니다. 즉, 레지스트리를 소유하는 프로젝트와 다른 작업 및 템플릿 애셋을 호스팅하는 스토리지 버킷(또는 기본 템플릿을 사용하는 경우에는 스토리지 버킷만)의 작업을 실행할 수 있습니다 이 방식은 여러 고객의 데이터 처리를 서로 다른 프로젝트 및 파이프라인 작업으로 격리시켜야 할 때 유용합니다. Flex 템플릿을 사용하면 파이프라인을 실행할 때 사용할 Docker 이미지의 다른 버전을 지정할 수 있습니다. 이렇게 하면 일괄 파이프라인의 단계별 바꾸기 또는 나중에 템플릿을 업데이트할 때 여러 프로젝트로 파이프라인을 스트리밍하는 작업을 간소화할 수 있습니다.
리소스 사용량 최적화를 위한 Dataflow 기능
Dataflow는 리소스 사용률을 최적화하기 위해 다음과 같은 실행기별 기능을 제공하여 성능을 개선하고 비용을 줄일 수 있습니다.
- Streaming Engine: 스트리밍 파이프라인 실행을 VM 작업자에서 전용 서비스로 이동합니다. 자동 확장 응답 개선, 작업자 VM의 리소스 소비 감소, 재배포 없이 자동 서비스 업데이트 등의 이점이 있습니다. 스트리밍 파이프라인에는 Streaming Engine을 사용 설정하는 것이 좋습니다. 최신 버전의 Apache Beam 자바 SDK 또는 Python SDK를 사용하면 이 기능이 기본적으로 사용 설정됩니다.
- Dataflow Shuffle: 일괄 파이프라인의 셔플 작업을 VM 작업자에서 전용 서비스로 이동합니다. 대부분의 일괄 파이프라인에 대한 빠른 실행, 작업자 VM의 리소스 소비 감소, 자동 확장 응답 개선, 내결함성 개선 등의 이점이 있습니다. 일괄 파이프라인에는 Dataflow Shuffle을 사용 설정하는 것이 좋습니다. Apache Beam 자바 SDK 및 최신 Python SDK를 사용하면 이 기능이 기본적으로 사용 설정됩니다.
- 유연한 리소스 예약(FlexRS): 이 방법은 고급 예약 기술, Dataflow Shuffle 서비스, 선점형 VM 인스턴스와 일반 VM의 조합을 사용하여 일괄 처리 비용을 줄입니다.
프로덕션 환경에서 스트리밍 파이프라인 업데이트
작업 완료 시 중지되는 일괄 파이프라인과 달리 스트리밍 파이프라인은 중단 없는 처리를 제공하기 위해 지속적으로 실행되어야 하는 경우가 많습니다. 초기 배포 후에는 기존 파이프라인을 업데이트할 때 다음 사항을 고려해야 합니다.
- 파이프라인의 비즈니스 로직은 파이프라인의 중단을 최소화하거나 방지하는 방식으로 업데이트해야 합니다. 요구사항에 따라 파이프라인의 새 버전이 배포되는 동안 일시적인 처리 중단을 허용할 수 있습니다. 하지만 애플리케이션에 장애가 발생할 수 있습니다.
- 파이프라인 업데이트 프로세스는 메시지 처리 및 기타 연결된 시스템의 중단을 최소화하는 방식으로 스키마 변경을 처리해야 합니다. 예를 들어 이벤트 처리 파이프라인의 메시지 스키마가 변경되면 다운스트림 데이터 싱크의 스키마도 변경해야 할 수 있습니다.
이 섹션의 나머지 부분에서는 이 두 가지 문제를 해결하는 방법을 설명합니다.
스트리밍 파이프라인에 인플레이스 업데이트 수행
특정한 상황에서 Dataflow를 사용하면 파이프라인을 취소하거나 드레이닝하지 않고도 진행 중인 스트리밍 작업을 직접 업데이트할 수 있습니다. Dataflow는 업데이트된 파이프라인 코드를 실행 중인 파이프라인에 안전하게 배포할 수 있도록 호환성 검사를 수행합니다. 특정 코드 변경으로 인해 호환성 검사가 실패할 수 있습니다(예: 기존 단계에서 부차 입력이 추가 또는 삭제됨). 자세한 내용은 기존 파이프라인 업데이트를 참조하세요.
코드 변경사항을 적용하는 것 외에도 인플레이스 업데이트를 사용하여 스트리밍 Dataflow 작업의 작업자 수를 변경할 수 있습니다. 자세한 내용은 파이프라인 배포의 '스트리밍 모드에서 수동 확장' 섹션을 참조하세요.
스트리밍 파이프라인 종료 및 교체
처리를 일시적으로 중지할 수 있는 경우 파이프라인을 취소하거나 드레이닝할 수 있습니다. 파이프라인을 취소하면 Dataflow가 즉시 처리를 중지하고 리소스를 종료합니다. 이로 인해 이동 중인 데이터, 즉 파이프라인에서 처리 중인 데이터가 손실됩니다. 대부분의 경우 데이터 손실을 방지하기 위해 드레이닝을 사용하는 것이 좋습니다.
파이프라인을 드레이닝하면 처리 중인 모든 창이 즉시 닫히고 모든 트리거가 실행됩니다. 이동 중인 데이터가 손실되지는 않지만 드레이닝을 수행하면 창에 불완전한 데이터가 발생할 수 있습니다. 이 경우 처리 중인 창에서는 일부 또는 불완전한 결과를 내보냅니다. 자세한 내용은 파이프라인 드레이닝의 효과를 참조하세요. 기존 작업이 완료되면 업데이트된 파이프라인 코드가 포함된 새 스트리밍 작업을 실행하여 처리를 재개할 수 있습니다.
또 다른 단점은 기존 스트리밍 작업이 종료되는 시점과 교체 파이프라인이 데이터 처리를 재개할 수 있는 시점 사이에 몇 차례의 다운타임이 발생한다는 것입니다.
그러나 이 접근 방식의 장점은 기존 파이프라인을 취소하거나 드레이닝한 다음 새 작업을 실행하여 업데이트된 파이프라인으로 간단히 대체하기만 하면 된다는 것입니다.
Pub/Sub 스냅샷 및 Seek을 사용한 메시지 재처리
경우에 따라 드레이닝 파이프라인을 교체하거나 취소한 후에 이전에 전송된 Pub/Sub 메시지를 다시 처리해야 할 수도 있습니다. 예를 들어 업데이트된 비즈니스 로직을 사용하여 데이터를 다시 처리해야 할 수 있습니다. Pub/Sub Seek 기능을 사용하면 Pub/Sub 스냅샷에서 메시지를 재생할 수 있습니다. Dataflow 파이프라인이 있는 Pub/Sub Seek 기능을 사용하면 구독 스냅샷이 생성된 시점부터 메시지를 다시 처리할 수 있습니다.
개발 및 테스트 중에 Pub/Sub Seek을 사용하여 알려진 메시지를 반복 재생하여 파이프라인의 출력을 확인할 수도 있습니다. Pub/Sub Seek를 사용하는 경우 파이프라인에서 구독을 사용 중일 때는 구독 스냅샷을 탐색하지 마세요. 탐색하면 Dataflow의 워터마크 로직이 무효화되고 Pub/Sub 메시지가 정확히 한 번만 처리되게 할 수 있습니다.
터미널 창에서 Dataflow 파이프라인으로 Pub/Sub Seek를 사용하는 데 권장되는 gcloud CLI 워크플로는 다음과 같습니다.
구독의 스냅샷을 만듭니다.
gcloud pubsub snapshots create snapshot-name --subscription=pipeline-subscription-name
파이프라인을 드레이닝하거나 취소합니다.
gcloud dataflow jobs drain job-id
또는
gcloud dataflow jobs cancel job-id
스냅샷을 탐색합니다.
gcloud pubsub subscriptions seek snapshot-name
구독을 사용하는 새 파이프라인을 배포합니다.
병렬 파이프라인 실행
Dataflow가 작업을 직접 업데이트할 수 없는 경우에도 병렬 파이프라인을 만들어 스트리밍 파이프라인이 중단되지 않게 할 수 있습니다. 이 방법을 사용하려면 파이프라인 코드를 업데이트한 새 스트리밍 작업을 만들고 기존 파이프라인과 동시에 실행합니다.
새 파이프라인을 만들 때는 기존 파이프라인에 사용한 것과 동일한 윈도우 전략을 사용합니다. 워터마크가 업데이트된 파이프라인에서 처리한 가장 오래된 완료 윈도우의 타임스탬프를 초과할 때까지 기존 파이프라인을 계속 실행할 수 있습니다. 이 시점에 기존 파이프라인은 완전히 드레이닝되거나 취소되므로 계속해서 업데이트된 파이프라인이 대신 실행되고 자체 처리 작업을 효과적으로 인계받습니다.
다음 다이어그램은 이 프로세스를 보여줍니다.
다이어그램에서 파이프라인 B는 파이프라인 A에서 인계받은 업데이트된 작업입니다. t 값은 파이프라인 B에서 처리된 가장 오래된 완료 기간의 타임스탬프입니다. w 값은 파이프라인 A의 워터마크입니다. 편의를 위해 지연 데이터가 없는 완벽한 워터마크라고 가정하고(처리 및 실제 경과 시간은 가로축에 표시됨) 두 파이프라인 모두 5분의 고정(텀블링) 기간을 사용합니다. 워터마크가 각 기간의 끝을 통과한 후 결과가 트리거됩니다.
동시 출력은 두 파이프라인이 겹치는 기간 동안 발생합니다. 따라서 업데이트된 파이프라인을 구성하여 기존 파이프라인이 결과를 쓴 위치와 다른 대상에 결과를 쓰도록 구성해야 합니다. 그런 다음 다운스트림 시스템은 데이터베이스 보기와 같은 두 대상 싱크에 대한 추상화를 사용하여 결합된 결과를 쿼리할 수 있습니다. 이러한 시스템은 추상화를 사용하여 중첩 실행 기간에서 결과를 중복 삭제할 수도 있습니다.
다음 예시는 Pub/Sub에서 입력 데이터를 읽고, 일부 처리를 수행하고, 결과를 BigQuery에 쓰는 간단한 파이프라인의 사용 방법을 설명합니다.
초기 상태에서는 기존 스트리밍 파이프라인(파이프라인 A)이 실행 중이고 구독(구독 A )을 사용하여 Pub/Sub 주제(주제)에서 메시지를 읽습니다. 결과는 BigQuery 테이블(테이블 A)에 기록됩니다. 결과는 기본 테이블 변경사항을 마스킹하는 파사드 역할을 하는 BigQuery 뷰를 통해 사용할 수 있습니다. 이는 파사드 패턴이라는 디자인 메서드의 애플리케이션입니다. 다음 다이어그램은 초기 상태를 보여줍니다.
업데이트된 파이프라인의 새 구독(구독 B)을 만듭니다. 구독 B를 사용하여 Pub/Sub 주제(주제)에서 읽고 별도의 BigQuery 테이블(테이블 B)에 쓰는 업데이트된 파이프라인(파이프라인 B)을 배포합니다. 이 흐름을 다이어그램으로 나타내면 다음과 같습니다.
이 시점에서 파이프라인 A 및 파이프라인 B는 동시에 실행되며 결과를 별도의 테이블에 씁니다. 시간 t는 파이프라인 B에서 처리된 가장 오래된 완료 기간의 타임스탬프로 기록합니다.
워터마크가 시간 t를 초과하면 파이프라인 A가 드레이닝됩니다. 그러면 열려 있는 모든 기간이 닫히고 이동 중인 데이터의 처리가 완료됩니다. 완료 기간이 중요한 경우(지연 데이터가 없다고 가정) 첫 번째 파이프라인을 드레이닝하기 전에 겹치는 기간이 완료될 때까지 두 파이프라인을 모두 실행할 수 있습니다. 이동 중인 데이터를 모두 처리하고 테이블 A에 기록한 후에는 파이프라인 A의 스트리밍 작업을 중지합니다. 다음 다이어그램은 이 단계를 보여줍니다.
이 시점에서는 파이프라인 B만 실행됩니다. 테이블 A와 테이블 B의 파사드 역할을 하는 BigQuery 뷰(파사드 뷰)에서 쿼리할 수 있습니다. 두 테이블에 동일한 타임스탬프가 있는 행의 경우 테이블 B의 행을 반환하거나 테이블 B에 행이 없는 경우 테이블 A로 돌아가도록 뷰를 구성합니다. 다음 다이어그램은 테이블 A와 테이블 B에서 읽는 뷰(파사드 뷰)를 보여줍니다.
이 시점에서 원하는 경우 구독 A를 삭제할 수 있습니다. 두 BigQuery 테이블을 병합하거나 따로 분리할 수 있습니다.
중복된(병렬) 파이프라인을 배포하면 새 파이프라인 배포에서 문제가 감지되는 경우 롤백이 간소화될 수 있습니다. 이전 예시에서는 정확한 작동을 위해 파이프라인 B를 모니터링하면서 파이프라인 A를 계속 실행하는 것이 좋습니다. 파이프라인 B에 문제가 있는 경우 파이프라인 A를 사용하여 롤백할 수 있습니다.
스키마 변형 처리
데이터 처리 시스템은 비즈니스 요구사항의 변경이나 기술적인 이유로 스키마 변형을 수용해야 하는 경우가 많습니다. 일반적으로 스키마 업데이트를 적용할 때는 비즈니스 정보 시스템이 중단되지 않도록 신중하게 계획하고 실행해야 합니다. 파이프라인 업데이트를 수행할 때는 수집을 중단하지 않고 기존 스키마에 의존하는 연결된 시스템에 영향을 주지 않는 범위에서 스트리밍 데이터 파이프라인 내의 스키마 변형을 처리해야 합니다.
Pub/Sub 주제에서 JSON 페이로드가 포함된 메시지를 읽는 간단한 파이프라인을 고려해보세요. 파이프라인은 각 메시지를 TableRow 인스턴스로 변환한 다음 행을 BigQuery 테이블에 씁니다. 출력 테이블의 스키마는 파이프라인에서 처리되는 메시지와 유사합니다.
다음 다이어그램에서는 스키마를 스키마 A라고 합니다.
시간 경과에 따라 메시지 스키마가 간단하지 않은 방식으로 변경되었다고 가정해 보겠습니다. 필드는 추가, 삭제 또는 대체되고 스키마 A는 새로운 스키마로 발전합니다. 다음 다이어그램에서는 새 스키마를 스키마 B라고 합니다. 이 경우 파이프라인 A를 업데이트해야 하며 출력 테이블 스키마는 스키마 B를 지원해야 합니다.
기본 테이블과 스테이징 테이블을 사용하여 스키마 변형 처리
출력 테이블에서는 새 필드를 추가하거나 열 모드(예: REQUIRED에서 NULLABLE)를 완화하는 스키마 변형을 다운타임 없이 수행할 수 있습니다. 또한 변형은 일반적으로 기존 쿼리에 영향을 주지 않습니다. 그러나 기존 스키마 필드를 수정하거나 삭제하는 스키마 변형으로 인해 쿼리가 중단되거나 다른 중단 문제가 발생합니다. 기존 스키마 필드가 수정되거나 삭제될 때 다운타임 없이 변경사항을 수용할 수 있는 방법을 계획해야 합니다.
중단을 피하는 한 가지 방법은 파이프라인이 작성한 테이블을 기본 테이블과 하나 이상의 스테이징 테이블로 분리하는 것입니다. 이 접근 방식에서 기본 테이블은 파이프라인이 쓴 이전 데이터를 저장하고 스테이징 테이블은 최신 파이프라인 출력을 저장합니다. 기본 및 스테이징 테이블에 BigQuery 파사드 뷰를 정의하면 소비자가 이전 데이터와 최신 데이터를 모두 쿼리할 수 있습니다.
다음 다이어그램에서는 스테이징 테이블(스테이징 테이블 A), 기본 테이블, 파사드 뷰를 포함하도록 이전 흐름을 수정합니다.
수정된 흐름에서 파이프라인 A는 스키마 A를 사용하는 메시지를 처리하고 호환되는 스키마를 가진 스테이징 테이블 A에 출력을 씁니다. 기본 테이블에는 파이프라인의 이전 버전에서 쓴 이전 데이터와 스테이징 테이블에서 주기적으로 병합되는 결과가 포함됩니다. 소비자는 파사드 뷰를 사용하여 이전 데이터와 실시간 데이터를 포함한 최신 데이터를 쿼리할 수 있습니다.
메시지 스키마가 스키마 A에서 스키마 B로 변형되면 스키마 B를 사용하는 메시지와 호환되도록 파이프라인 코드를 업데이트해야 할 수 있습니다. 기존 파이프라인을 새 구현으로 업데이트해야 합니다. 인플레이스 업데이트를 수행하거나 병렬 파이프라인을 실행하여 중단없이 스트리밍 데이터 처리를 계속할 수 있습니다. 반면에 파이프라인을 종료하고 교체하면 파이프라인이 실행되지 않는 기간이 있기 때문에 처리가 중단됩니다.
업데이트된 파이프라인은 스키마 B를 사용하는 추가 스테이징 테이블(스테이징 테이블 B)에 씁니다. 조정된 워크플로를 통해 파이프라인을 업데이트하기 전에 새 스테이징 테이블을 만들거나, 업데이트된 파이프라인 코드가 테이블을 자동으로 만들 수 있습니다. 파사드 뷰는 새 스테이징 테이블의 결과를 포함하도록(관련 워크플로 단계 사용 가능) 업데이트해야 합니다. 다음 다이어그램은 스키마 B를 포함한 스테이징 테이블 B를 보여주는 업데이트된 흐름과 기본 테이블 및 두 스테이징 테이블에서 콘텐츠를 포함하도록 파사드 뷰가 어떻게 업데이트되었는지 보여줍니다.
파이프라인 업데이트와는 별도의 프로세스로 스테이징 테이블을 주기적으로 또는 필요에 따라 기본 테이블에 병합할 수 있습니다. 다음 다이어그램은 스테이징 테이블 A가 기본 테이블에 어떻게 병합되는지 보여줍니다.
Dataflow 작업의 수명
Dataflow 작업은 다양한 작업 상태로 표현되는 수명 주기를 거칩니다.
Dataflow 작업을 실행하려면 리전 엔드포인트에 작업을 제출합니다.
여기에서 작업이 리전 내의 영역 중 하나에 있는 사용 가능한 Dataflow 백엔드로 라우팅됩니다. Dataflow가 백엔드를 할당하기 전에 작업을 실행할 수 있을 정도로 충분한 할당량과 권한이 있는지 확인합니다. 이러한 실행 전 검사가 완료되고 백엔드가 할당되면 작업이 JOB_STATE_PENDING 상태로 전환됩니다. FlexRS 작업의 경우 백엔드 할당이 미래의 시점으로 지연될 수 있으며 이러한 작업은 JOB_STATE_QUEUED 상태가 됩니다.
할당된 백엔드는 실행할 작업을 선택하고 Google 프로젝트에서 Dataflow 작업자 시작을 시도합니다. 작업자 VM에 선택된 영역은 여러 요인에 따라 달라집니다. Dataflow Shuffle을 사용하는 일괄 작업의 경우 이 서비스는 영역 간 트래픽 방지를 위해 Dataflow 백엔드와 작업자 VM이 같은 영역에 있도록 합니다.
Dataflow 작업자가 시작된 후에는 이 작업자가 Dataflow 백엔드에서 작업을 요청합니다. 백엔드는 작업자 간에 분산되는 동시 로드가 가능한 청크(번들이라고 함)로 작업을 분할합니다. 작업자가 기존 작업을 처리할 수 없고 자동 확장이 사용 설정된 경우 작업을 처리하기 위해 백엔드에서 더 많은 작업자를 시작합니다. 마찬가지로 필요 이상으로 많은 작업자가 있는 경우에는 일부 작업자가 종료됩니다.
Dataflow 작업자가 시작되면 Dataflow 백엔드는 작업 실행을 조정하는 제어 영역 역할을 합니다. 처리 중에 작업의 데이터 영역은 GroupByKey, CoGroupByKey, Combine과 같은 셔플 작업을 수행합니다.
작업은 셔플 작업에 다음과 같은 데이터 영역 구현 중 하나를 사용합니다.
- 데이터 영역은 Dataflow 작업자에서 실행되고 셔플 데이터는 영구 디스크에 저장됩니다. 이 구현에는 일괄 파이프라인용 Shuffle Appliance와 스트리밍 파이프라인용 Streaming Appliance라는 두 가지 변수가 있습니다. 작업에 사용되는 변수는 작업 생성 시 일괄 또는 스트리밍 모드 중 무엇을 지정하는지에 따라 자동으로 선택됩니다.
- 데이터 영역은 작업자 VM에서 외부화된 서비스로 실행됩니다. 이 구현에서 작업을 만들 때 지정할 수 있는 두 가지 변수는 일괄 파이프라인용 Dataflow Shuffle과 스트리밍 파이프라인용 Streaming Engine입니다. 작업자 기반 셔플과 비교할 때 서비스 기반 셔플은 데이터 셔플링 작업의 성능과 확장성을 크게 개선합니다.
JOB_STATE_RUNNING 상태로 전환되는 스트리밍 작업은 작업이 실패하지 않는 한 취소 또는 드레이닝될 때까지 무기한 실행됩니다. 모든 처리가 완료되거나 복구할 수 없는 오류가 발생하면 일괄 작업이 자동으로 종료됩니다. 작업이 중지된 원인에 따라 Dataflow는 작업의 상태를 JOB_STATE_CANCELLED, JOB_STATE_DRAINED, JOB_STATE_DONE 등 여러 터미널 상태 중 하나로 설정합니다.
파이프라인 안정성 권장사항
이 섹션에서는 Dataflow로 작업할 때 발생할 수 있는 장애에 대해 설명하고 작업 제출 중 및 파이프라인 실행 시 발생하는 오류를 처리하기 위한 권장사항을 설명합니다.
격리 원칙 준수
전체 파이프라인의 안정성을 개선하기 위한 일반적인 권장사항은 리전 및 영역의 격리 원칙을 따르는 것입니다. 파이프라인에는 중요한 리전 간 종속 항목이 없어야 합니다. 여러 리전의 서비스에서 중요한 종속 항목이 있는 파이프라인이 있는 경우 해당 파이프라인은 이러한 리전 중 하나의 오류로 인해 영향을 받을 수 있습니다. 이 문제를 피하려면 중복 및 백업을 위해 멀티 리전에 배포하세요.
Dataflow 스냅샷 만들기
Dataflow는 파이프라인 상태 백업을 제공하는 스냅샷 기능을 제공합니다. 파이프라인 스냅샷을 다른 영역 또는 리전의 새 스트리밍 Dataflow 파이프라인으로 복원할 수 있습니다. 그런 다음 스냅샷 타임스탬프부터 Pub/Sub 또는 Kafka 주제의 메시지 재처리를 시작할 수 있습니다. 파이프라인의 정기 스냅샷을 설정하면 복구 시간 목표 (RTO) 시간을 최소화할 수 있습니다.
Dataflow 스냅샷에 대한 자세한 내용은 Dataflow 스냅샷 사용을 참조하세요.
작업 제출 실패 처리
Apache Beam SDK를 사용하여 기존 Dataflow 작업을 제출합니다. 작업을 제출하려면 파이프라인 옵션의 일부로 지정된 Dataflow Runner를 사용하여 파이프라인을 실행합니다. Apache Beam SDK는 Cloud Storage에서 파일을 스테이징하고, 작업 요청 파일을 만들고, 파일을 Dataflow에 제출합니다.
또는 Dataflow 템플릿에서 생성된 작업은 일반적으로 템플릿 API를 사용하는 다른 제출 방법을 사용합니다.
기존 작업 및 템플릿 작업의 작업 실패를 나타내는 다양한 오류가 Dataflow에서 반환될 수 있습니다. 이 섹션에서는 다양한 유형의 작업 제출 실패를 처리하거나 완화하기 위한 권장사항을 설명합니다.
일시적인 실패 후 작업 제출 재시도
Dataflow 서비스 문제로 인해 작업이 시작되지 않으면 작업을 몇 번 다시 시도합니다. 이렇게 하면 일시적인 서비스 문제에 대한 파이프라인 복원력이 향상됩니다.
작업자 리전을 지정하여 영역 오류 완화
Dataflow는 리전별 가용성을 제공하며 멀티 리전에서 사용할 수 있습니다. 사용자가 명시적으로 영역을 지정하지 않고 리전 엔드포인트에 작업을 제출하면 Dataflow는 리소스 가용성에 따라 지정된 리전의 영역으로 작업을 라우팅합니다.
작업 배치에 권장되는 옵션은 가능한 경우 --zone 플래그 대신 --region 플래그를 사용하여 작업자 리전을 지정하는 것입니다. 이렇게 하면 Dataflow는 해당 작업에 가장 적합한 영역을 자동으로 선택하여 파이프라인의 내결함성을 강화할 수 있습니다. 명시적 영역이 지정된 작업은 이러한 이점이 없으며 영역 내에서 문제가 발생하면 실패합니다(예: 리소스 소진). 영역 문제로 인해 작업 제출이 실패하면 명시적으로 영역을 지정하지 않고 작업을 다시 시도하여 문제를 해결할 수 있습니다.
멀티 리전에 데이터를 저장하여 리전 오류 완화
전체 리전을 사용할 수 없는 경우 다른 리전에서 작업을 시도하세요. 여러 리전에서 작업이 실패하면 데이터의 가용성을 고려해야 합니다. 여러 리전에 데이터를 수동으로 복사하지 않고 단일 리전 장애를 방지하려면 여러 리전에 데이터를 자동으로 저장하는 Google Cloud 리소스를 사용하세요. 예를 들어 데이터 세트 또는 Cloud Storage 이중 리전 및 멀티 리전 버킷에는 BigQuery 멀티 리전 위치를 사용합니다. 한 리전을 사용할 수 없게 되면 데이터를 사용할 수 있는 다른 리전에서 파이프라인을 다시 실행할 수 있습니다.
Dataflow에서 멀티 리전 서비스를 사용하는 예시는 고가용성 및 지리적 중복성을 참조하세요.
파이프라인 실행 실패 처리
작업이 제출되고 수락되면 해당 작업에 유효한 작업은 다음과 같습니다.
- 일괄 작업 취소
- 스트리밍 작업의 업데이트, 드레이닝 또는 취소
작업을 제출한 후에는 실행 중인 작업의 위치를 변경할 수 없습니다. FlexRS를 사용하지 않는 경우 일반적으로 작업은 제출 후 몇 분 내에 데이터 처리를 시작합니다. (FlexRS 작업은 데이터 처리를 시작하는 데 최대 6시간이 걸릴 수 있습니다.)
이 섹션에서는 작업 실행 실패 및 처리 권장사항을 설명합니다.
작업 모니터링을 통해 일시적인 오류로 인한 문제 파악 및 해결
일괄 작업의 경우 실패한 항목이 포함된 번들은 4번 재시도됩니다. Dataflow는 단일 번들이 4번 실패하면 작업을 종료합니다. 이렇게 하면 많은 일시적인 문제가 해결됩니다. 하지만 장기적 실패가 발생하면 보통 최대 재시도 한도에 빠르게 도달하므로 업이 빠르게 실패할 수 있습니다.
모니터링 및 이슈 관리의 경우 실패한 작업을 감지하도록 알림 규칙을 구성합니다. 작업이 실패하면 작업 로그를 검사하여 재시도 한도를 초과한 실패한 작업 항목으로 인해 발생한 작업 실패를 파악합니다.
스트리밍 작업의 경우 Dataflow는 실패한 작업 항목을 무기한 재시도하므로 작업이 종료되지 않습니다. 하지만 문제가 해결될 때까지 작업이 중단될 수 있습니다. 모니터링 정책을 만들어 시스템 지연 시간 증가 및 데이터 최신 상태 저하와 같은 중단된 파이프라인의 신호를 감지합니다. 파이프라인 코드에 오류 로깅을 구현하면 반복적으로 실패하는 작업 항목으로 인해 발생한 파이프라인 중단을 식별할 수 있습니다.
영역 중단이 발생하면 다른 영역에서 작업 다시 시작
작업이 시작된 후 사용자 코드를 실행하는 Dataflow 작업자는 단일 영역으로 제한됩니다. 영역 중단이 발생하면 중단 범위에 따라 Dataflow 작업이 영향을 받을 수 있습니다.
Dataflow 백엔드에만 영향을 미치는 중단의 경우 백엔드에서 작업을 계속할 수 있도록 관리형 서비스에 의해 백엔드가 다른 영역으로 자동 마이그레이션됩니다. (작업에서 Dataflow Shuffle을 사용하는 경우 백엔드를 다른 영역으로 이동할 수 없습니다.) Dataflow 백엔드 마이그레이션이 발생하면 작업이 일시적으로 중단될 수 있습니다.
영역 중단이 발생하면 실행 중인 작업은 실패하거나 영역 가용성이 복원될 때까지 중단될 수 있습니다. 영역을 오랫동안 사용할 수 없게 되면 작업을 중지(일괄 작업의 경우 취소, 스트리밍 작업의 경우 드레이닝)한 다음 다시 시작하여 Dataflow가 새로운 정상 영역을 선택하도록 해야 합니다.
리전 중단이 발생하면 다른 리전에서 일괄 작업을 다시 시작
Dataflow 작업이 실행 중인 리전에서 리전 중단이 발생하면 작업이 실패하거나 중단될 수 있습니다. 일괄 작업의 경우 가능하면 다른 리전에서 작업을 다시 시작합니다. 리전을 사용할 수 없는 경우 작업 제출 실패를 처리할 때와 마찬가지로 데이터를 멀티 리전에서 사용할 수 있는지 확인하는 것이 중요합니다.
고가용성 또는 장애 조치를 사용하여 리전 중단 완화
스트리밍 작업의 경우 애플리케이션의 내결함성과 예산에 따라 실패를 완화할 수 있는 옵션을 사용할 수 있습니다. 리전 중단의 경우 가장 간단하고 비용 효율적인 옵션은 중단이 끝날 때까지 기다리는 것입니다. 하지만 애플리케이션이 지연 시간에 민감하고 최소한의 지연으로 데이터 처리가 중단되거나 재개되어야 하는 경우에는 허용되지 않을 수 있습니다. 다음 섹션에서는 이러한 옵션에 대해 설명합니다.
고가용성: 데이터 손실 없이 지연 시간에 민감함
애플리케이션에서 데이터 손실을 허용할 수 없는 경우 두 개의 서로 다른 리전에서 중복 파이프라인을 동시에 실행하고 파이프라인이 동일한 데이터를 사용하도록 합니다. 이렇게 하면 두 리전 모두에서 동일한 데이터 소스를 사용할 수 있습니다. 이러한 파이프라인의 출력에 의존하는 다운스트림 애플리케이션은 이 두 리전의 출력 간에 전환할 수 있어야 합니다. 리소스 중복으로 인해 이 옵션은 다른 옵션에 비해 비용이 많이 듭니다. 배포의 예시는 다음 섹션인 고가용성 및 지리적 중복성을 참조하세요.
장애 조치: 잠재적인 데이터 손실이 약간 발생하며 지연 시간에 민감함
애플리케이션이 잠재적인 데이터 손실을 허용할 수 있는 경우 스트리밍 데이터 소스를 여러 리전에서 사용할 수 있도록 합니다. 예를 들어 Pub/Sub를 사용하면 동일한 주제에 대해 두 개의 독립적인 구독(리전당 하나)을 유지할 수 있습니다. 리전 중단이 발생하면 다른 리전에서 교체 파이프라인을 시작하고 파이프라인이 백업 구독의 데이터를 사용하도록 할 수 있습니다. 지연 시간은 그대로 유지하면서 데이터 손실을 최소화하려면 백업 구독을 적절한 시간으로 재생해야 합니다. 다운스트림 애플리케이션은 실행 중인 파이프라인의 출력으로 전환하는 방법을 알아야 합니다(고가용성 옵션과 유사). 이 옵션은 데이터만 중복되므로 중복 파이프라인을 실행할 때보다 리소스를 적게 사용합니다.
고가용성 및 지리적 중복성
고가용성 데이터 처리를 위해 여러 스트리밍 파이프라인을 동시에 실행할 수 있습니다. 예를 들어 데이터 처리를 위한 지리적 중복성과 내결함성을 제공하는 서로 다른 리전에서 두 개의 병렬 스트리밍 작업을 실행할 수 있습니다.
데이터 소스 및 싱크의 지리적 가용성을 고려하여 가용성이 높은 멀티 리전 구성에서 엔드 투 엔드 파이프라인을 운영할 수 있습니다. 다음 다이어그램은 배포의 예시를 보여줍니다.
이 다이어그램은 다음 흐름을 보여줍니다.
- Pub/Sub는 전 세계 대부분의 리전에서 실행됩니다. 이렇게 하면 서비스가 빠른 글로벌 데이터 액세스를 제공하고 사용자는 메시지가 저장되는 위치를 제어할 수 있습니다. Pub/Sub는 게시된 메시지를 구독자와 가장 가까운 Google Cloud 리전에 자동으로 저장하거나 메시지 스토리지 정책을 사용하는 특정 리전 또는 여러 리전을 사용하도록 메시지를 구성할 수 있습니다. 그런 다음 Pub/Sub는 메시지가 저장된 위치에 상관없이 전 세계 구독자에게 메시지를 전달합니다. Pub/Sub 클라이언트는 연결되는 서버 위치를 알 필요가 없습니다. 전역 부하 분산 메커니즘이 메시지가 저장된 가장 가까운 Google Cloud 데이터 센터로 트래픽을 전달하기 때문입니다.
- Dataflow는 특정 Google Cloud 리전에서 실행됩니다. 별도의 Google Cloud 리전에서 병렬 파이프라인을 실행하면 단일 리전에 영향을 미치는 오류로부터 작업을 격리할 수 있습니다. 이 다이어그램은 동일한 파이프라인의 두 인스턴스를 보여줍니다. 각 인스턴스는 별도의 Google Cloud 리전에서 실행됩니다.
- BigQuery는 리전 및 멀티 리전 데이터 세트 위치를 제공합니다. 멀티 리전 위치를 선택하면 데이터 세트는 두 개 이상의 리전에 있습니다. 이 다이어그램은 각각 별도의 멀티 리전 데이터 세트에 쓰는 두 개의 개별 파이프라인을 보여줍니다.
다음 단계
- 이 시리즈의 다음 부분인 데이터 파이프라인 모니터링 계속 진행하기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 가이드, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기