Pub/Sub로 스트리밍

이 페이지에서는 Pub/Sub와의 Dataflow 통합에 대한 개념 개요를 제공합니다. 이 개요에서는 Dataflow 실행기의 Pub/Sub I/O 커넥터 구현에서 사용할 수 있는 몇 가지 최적화를 설명합니다. Pub/Sub는 확장 가능하고 내구성 있는 이벤트 수집 및 전달 시스템입니다. Dataflow는 Pub/Sub의 확장 가능한 최소 1회 전달 모델을 메시지 중복 삭제 기능, 단 한 번에 처리하는 기능, 타임스탬프가 지정된 이벤트에서 데이터 워터마크를 생성하는 기능으로 보완합니다. Dataflow를 사용하려면 Apache Beam SDK를 사용하여 파이프라인을 작성한 다음 Dataflow 서비스에서 파이프라인 코드를 실행합니다.

시작하기 전에 Apache Beam 및 스트리밍 파이프라인의 기본 개념에 대해 알아보세요. 자세한 내용은 다음 리소스를 참조하세요.

Pub/Sub로 스트리밍 파이프라인 빌드

Pub/Sub와의 Dataflow 통합의 이점을 누리려면 다음 방법 중 하나로 스트리밍 파이프라인을 빌드하세요.

Pub/Sub 및 Dataflow 통합 기능

Apache Beam은 Pub/Sub(자바, Python, Go)에 대한 참조 I/O 소스 구현(PubsubIO)을 제공합니다. 이 I/O 소스 구현은 Apache Spark 실행기, Apache Flink 실행기, 직접 실행기와 같은 비 Dataflow 실행기에서 사용됩니다.

Dataflow 실행기는 PubsubIO의 다른 비공개 구현 (자바, Python, Go용)을 사용합니다. 이 구현은 Google Cloud 내부 API 및 서비스를 활용하여 짧은 지연 시간 워터마크, 높은 워터마크 정확성/데이터 완전성 및 효율적인 중복 삭제(메시지를 단 한 번에 처리)라는 세 가지 주요 이점을 제공합니다.

Apache Beam I/O 커넥터를 사용하면 제어된 소스 및 싱크를 사용하여 Dataflow와 상호작용할 수 있습니다. Dataflow 실행기의 PubsubIO 구현은 첫 번째 통합된 단계에서 성공적으로 처리된 다음 그러한 처리의 부작용이 영구 스토리지에 기록된 후 메시지를 자동으로 확인합니다. 자세한 내용은 Fusion 문서를 참조하세요. 따라서 일부 구성요소가 다운되거나 연결이 끊어진 경우, Dataflow가 데이터 손실이 없음을 보장할 수 있는 경우에만 메시지가 확인됩니다.

짧은 지연 시간 워터마크

Dataflow는 Cloud Monitoring에서 사용할 수 있는 것보다 지연 시간이 짧은 구독에서 가장 오래 확인되지 않은 메시지 기간을 제공하는 Pub/Sub의 비공개 API에 액세스할 수 있습니다. 비교를 위해 Cloud Monitoring에서 사용할 수 있는 Pub/Sub 백로그 측정항목이 일반적으로 2~3분 지연되지만 Dataflow의 경우 해당 측정항목이 약 10초만 지연됩니다. 이렇게 하면 Dataflow가 파이프라인 워터마크를 진행시키고 기간이 지정된 계산 결과를 더 빠르게 내보낼 수 있습니다.

높은 워터마크 정확성

Pub/Sub와의 Dataflow 통합으로 인해 기본적으로 해결되는 또 다른 중요한 문제는 이벤트 시간에 정의된 기간에 강력한 워터마크가 필요하다는 것입니다. 이벤트 시간은 게시자 애플리케이션에서 Pub/Sub 서비스의 메시지에 설정된 publish_time 필드가 아닌 Pub/Sub 메시지의 속성으로 지정된 타임스탬프입니다. Pub/Sub는 서비스 할당(또는 처리 시간) 타임스탬프에 대해서만 백로그 통계를 계산하므로 이벤트 시간 워터마크를 예측하려면 별도의 메커니즘이 필요합니다.

이 문제를 해결하기 위해 사용자가 커스텀 이벤트 타임스탬프를 사용하도록 선택하면 Dataflow 서비스에서 두 번째 추적 구독을 만듭니다. 이 추적 구독은 기본 구독의 백로그에 있는 메시지의 이벤트 시간을 검사하고 이벤트 시간 백로그를 추정하는 데 사용됩니다. 자세한 내용은 Dataflow에서 Pub/Sub 워터마크를 계산하는 방법을 다루는 StackOverflow 페이지를 참조하세요.

효율적인 중복 삭제

메시지를 단 한 번에 처리하려면 메시지 중복 삭제 기능이 필요합니다. Apache Beam 프로그래밍 모델을 사용하면 Pub/Sub 메시지 스트림을 정확히 한 번에 처리할 수 있습니다. Dataflow는 Pub/Sub 메시지 ID를 바탕으로 메시지에 중복 삭제 기능을 적용합니다. 결과적으로 모든 처리 논리에서 Pub/Sub 메시지 ID를 바탕으로 메시지가 이미 고유하다고 가정할 수 있습니다. 이 작업을 수행하기 위한 효율적이고 증분적인 집계 메커니즘은 PubsubIO API에서 추상화됩니다.

PubsubIO이 메시지 ID 대신 Pub/Sub 메시지 속성을 사용해 중복 삭제하도록 구성된 경우 Dataflow에서 10분 내로 Pub/Sub에 게시된 메시지를 중복 삭제합니다. Dataflow 서비스의 표준 정렬 API를 사용하면 Dataflow에서 순서 처리를 사용할 수 있습니다. 또는 Pub/Sub에 순서를 사용하려면 메시지 순서를 참조하세요.

지원되지 않는 Pub/Sub 기능

데드 레터 주제 및 지수 백오프 지연 재시도 정책

Pub/Sub 데드 레터 주제 및 지수 백오프 지연 재시도 정책은 Dataflow에서 완전히 지원되지 않습니다. 대신 파이프라인 내에서 이러한 패턴을 명시적으로 구현하세요. 소매업 애플리케이션 및 Pub/Sub to BigQuery 템플릿에는 데드 레터 패턴의 두 가지 예시가 제공됩니다.

Dataflow에서 데드 레터 주제 및 지수 백오프 지연 재시도 정책이 작동하지 않는 이유에는 두 가지가 있습니다.

먼저 Dataflow는 파이프라인 코드가 실패할 때 Pub/Sub에 NACK 메시지(즉, 부정 확인 전송)를 전송하지 않습니다. 대신 Dataflow는 메시지 처리를 무기한으로 다시 시도하면서 메시지의 확인 기한을 계속 연장합니다. 하지만 Dataflow 백엔드는 다양한 내부적인 이유로 NACK 메시지를 전송할 수 있으므로 파이프라인 코드에 오류가 없더라도 메시지가 데드 레터 주제로 전달될 수 있습니다.

두 번째로 Dataflow는 파이프라인이 데이터를 완전히 처리하기 전에 메시지를 확인할 수 있습니다. 특히 Dataflow에서는 메시지가 첫 번째 융합 단계에서 성공적으로 처리되고 처리의 부작용이 영구 스토리지에 기록된 후에 메시지를 확인합니다. 파이프라인에 여러 융합 단계가 있고 첫 번째 단계 이후 어느 시점이든 오류가 발생하면 메시지가 이미 확인된 것입니다.

동기식 가져오기에서 스트리밍 가져오기로 마이그레이션 예정(Streaming Engine만 해당)

Streaming Engine은 현재 동기식 가져오기를 사용하여 Pub/Sub의 데이터를 사용합니다. 향후 Streaming Engine은 성능 향상을 위해 스트리밍 가져오기를 사용합니다.

마이그레이션 중에 작업은 일정 시간 동안 동기식 가져오기를 사용하고 다른 기간에 스트리밍 가져오기를 사용할 수 있습니다. 이 전환은 Dataflow UI에 표시되고 Cloud Monitoring에 보고되는 Pub/Sub 측정항목에 영향을 미칩니다. 작업이 스트리밍 가져오기로 전환되면 일부 기존 측정항목이 보고되지 않습니다. 자세한 내용은 Dataflow 모니터링 인터페이스 사용을 참조하세요.

동기식 가져오기와 스트리밍 가져오기는 별도의 할당량을 소비합니다. Dataflow팀은 동기식 가져오기를 사용하여 이미 대량의 데이터를 사용하는 프로젝트의 할당량을 사전에 늘립니다.

Streaming Engine을 사용하지 않는 스트리밍 작업은 Streaming Pull로 마이그레이션되지 않으며, 이 변경의 영향을 받지 않습니다.

마이그레이션에 대해 궁금한 점이 있으면 계정팀에 문의하세요.

다음 단계