이 페이지에서는 Dataflow에서 Pub/Sub을 읽을 때의 권장사항을 설명합니다.
Apache Beam은 Dataflow가 아닌 실행자가 사용할 수 있는 Pub/Sub I/O 커넥터의 참조 구현을 제공합니다. 하지만 Dataflow 실행기는 커넥터의 자체 맞춤 구현을 사용합니다. 이 구현은 Google Cloud 내부 API 및 서비스를 활용하여 메시지를 단 한 번에 처리하기 위한 짧은 지연 시간 워터마크, 높은 워터마크 정확성, 효율적인 중복 삭제를 제공합니다. 이 커넥터는 Java, Python, Go에서 사용할 수 있습니다.
단 한 번 처리
Pub/Sub는 이벤트 게시자를 이벤트 소비자와 분리합니다. 애플리케이션은 메시지를 주제에 게시하고 Pub/Sub은 메시지를 구독자에게 비동기식으로 전송합니다.
Pub/Sub는 주제에 게시된 각 메시지에 고유한 메시지 ID를 할당합니다. 기본적으로 Pub/Sub는 최소 1회 메시지 전송을 실행합니다. 최소 1회 전송 시맨틱스를 달성하기 위해 Pub/Sub는 확인 기한 내에 구독자로부터 확인을 받지 못하면 전송을 다시 시도합니다. 재시도로 인해 메시지가 두 번 이상 전송될 수 있습니다. 예를 들어 구독자가 기한이 지난 후에 확인하거나 일시적인 네트워크 문제로 인해 확인이 손실된 경우 재전송이 발생할 수 있습니다.
정확히 한 번 스트리밍 모드를 사용하여 Dataflow 파이프라인을 실행하면 Dataflow에서 메시지의 중복을 삭제하여 정확히 한 번 시맨틱스를 실행합니다. 파이프라인에서 일부 중복 레코드를 허용할 수 있는 경우 대신 적어도 한 번 스트리밍 모드를 사용하는 것이 좋습니다. 이 모드를 사용하면 파이프라인의 지연 시간과 총 비용을 크게 줄일 수 있습니다. 단점은 일부 메시지가 두 번 처리될 수 있다는 점입니다. 자세한 내용은 사용할 스트리밍 모드 선택을 참고하세요.
메시지 속성별 중복 삭제
기본적으로 Dataflow는 메시지 ID를 기준으로 중복 삭제합니다. 그러나 애플리케이션은 동일한 레코드를 두 개의 서로 다른 Pub/Sub 메시지로 두 번 전송할 수 있습니다. 예를 들어 원본 소스 데이터에 중복 레코드가 포함되어 있거나 애플리케이션에서 동일한 메시지를 두 번 잘못 게시할 수 있습니다. 후자는 네트워크 문제 또는 기타 중단으로 인해 확인이 누락된 경우 재시도로 인해 발생할 수 있습니다. 이 경우 중복 메시지의 메시지 ID가 다릅니다.
시나리오에 따라 데이터에 중복 삭제에 사용할 수 있는 고유한 필드가 포함되어 있을 수 있습니다. 예를 들어 레코드에 고유한 트랜잭션 ID가 포함될 수 있습니다. Pub/Sub 메시지 ID를 사용하는 대신 메시지 속성 값을 기반으로 메시지를 중복 삭제하도록 Pub/Sub I/O 커넥터를 구성할 수 있습니다. 게시자가 재시도 중에 이 속성을 일관되게 설정하는 한 Dataflow는 중복을 감지할 수 있습니다. 중복 삭제를 위해 메시지는 10분 이내에 Pub/Sub에 게시되어야 합니다.
ID 속성 사용에 관한 자세한 내용은 다음 SDK 참조 주제를 참고하세요.
withIdAttribute
(Java)ReadFromPubSub
(Python)ReadOptions
(Go)
구독
파이프라인을 구성할 때 읽을 Pub/Sub 주제 또는 Pub/Sub 구독을 지정합니다. 구독을 지정하는 경우 여러 파이프라인에 동일한 Pub/Sub 구독을 사용하지 마세요. 두 개의 파이프라인이 단일 구독에서 읽는 경우 각 파이프라인은 데이터의 일부를 비결정론적 방식으로 수신하므로 중복 메시지, 워터마크 지연, 비효율적인 자동 확장이 발생할 수 있습니다. 대신 각 파이프라인에 대해 별도의 구독을 만듭니다.
주제를 지정하면 커넥터가 새 임시 구독을 만듭니다. 이 정기 결제는 파이프라인마다 고유합니다.
타임스탬프 및 워터마크
모든 Pub/Sub 메시지에는 Pub/Sub에서 메시지를 수신한 시간을 나타내는 타임스탬프가 있습니다. 데이터에는 소스에서 레코드가 생성된 시간인 이벤트 타임스탬프도 있을 수 있습니다.
Pub/Sub 메시지의 속성에서 이벤트 타임스탬프를 읽도록 커넥터를 구성할 수 있습니다. 이 경우 커넥터는 워터마킹에 이벤트 타임스탬프를 사용합니다. 그렇지 않으면 기본적으로 Pub/Sub 메시지 타임스탬프를 사용합니다.
이벤트 타임스탬프 사용에 관한 자세한 내용은 다음 SDK 참조 주제를 참고하세요.
withTimestampAttribute
(Java)ReadFromPubSub
(Python)ReadOptions
(Go)
Pub/Sub 커넥터는 구독에서 가장 오래 확인되지 않은 메시지 기간을 제공하는 Pub/Sub의 비공개 API에 액세스할 수 있습니다. 이 API는 Cloud Monitoring에서 제공하는 것보다 지연 시간이 짧습니다. 이를 통해 Dataflow는 파이프라인 워터마크를 진행시키고 지연 시간이 짧은 기간이 지정된 계산 결과를 내보낼 수 있습니다.
이벤트 타임스탬프를 사용하도록 커넥터를 구성하면 Dataflow에서 두 번째 Pub/Sub 구독을 만듭니다. 이 구독을 사용하여 아직 백로그에 있는 메시지의 이벤트 시간을 검사합니다. 이 접근 방식을 사용하면 Dataflow가 이벤트 시간 백로그를 정확하게 추정할 수 있습니다. 자세한 내용은 Dataflow에서 Pub/Sub 워터마크를 계산하는 방법을 다루는 StackOverflow 페이지를 참고하세요.
Pub/Sub 탐색
Pub/Sub Seek를 사용하면 사용자가 이전에 확인된 메시지를 다시 재생할 수 있습니다. Dataflow에서 Pub/Sub Seek를 사용하여 파이프라인의 메시지를 다시 처리할 수 있습니다.
그러나 실행 중인 파이프라인에서는 Pub/Sub Seek를 사용하지 않는 것이 좋습니다. 실행 중인 파이프라인에서 뒤로 탐색하면 메시지가 중복되거나 메시지가 삭제될 수 있습니다. 또한 Dataflow의 워터마크 로직을 무효화하고 처리된 데이터가 포함된 파이프라인의 상태와 충돌합니다.
Pub/Sub Seek를 사용하여 메시지를 다시 처리하려면 다음 워크플로를 사용하는 것이 좋습니다.
- 구독의 스냅샷을 만듭니다.
- Pub/Sub 주제에 대한 새 구독을 만듭니다. 새 정기 결제는 스냅샷을 상속합니다.
- 현재 Dataflow 작업을 배출하거나 취소합니다.
- 새 구독을 사용하여 파이프라인을 다시 제출합니다.
자세한 내용은 Pub/Sub 스냅샷 및 Seek을 사용한 메시지 재처리를 참고하세요.
지원되지 않는 Pub/Sub 기능
다음 Pub/Sub 기능은 Dataflow 실행기의 Pub/Sub I/O 커넥터 구현에서 지원되지 않습니다.
지수 백오프
Pub/Sub 구독을 만들 때 지수 백오프 재시도 정책을 사용하도록 구성할 수 있습니다. 그러나 지수 백오프는 Dataflow에서 작동하지 않습니다. 대신 즉시 재시도 재시도 정책으로 구독을 만듭니다.
지수 백오프는 부정 확인 또는 확인 기한 만료 시 트리거됩니다. 그러나 Dataflow는 파이프라인 코드가 실패할 때 부정 확인을 전송하지 않습니다. 대신 메시지 처리를 무기한으로 다시 시도하면서 메시지의 확인 기한을 계속 연장합니다.
데드 레터 주제
다음과 같은 이유로 Dataflow에서 Pub/Sub 데드 레터 주제를 사용하지 마세요.
Dataflow는 다양한 내부적인 이유로 부정 확인을 전송합니다 (예: 작업자가 종료되는 경우). 따라서 파이프라인 코드에 오류가 발생하지 않더라도 메시지가 데드 레터 주제로 전송될 수 있습니다.
Dataflow는 파이프라인이 데이터를 완전히 처리하기 전에 메시지를 확인할 수 있습니다. 특히 Dataflow는 메시지가 첫 번째 융합 단계에서 성공적으로 처리되고 처리의 부작용이 영구 스토리지에 기록된 후에 메시지를 확인합니다. 파이프라인에 여러 융합 단계가 있고 첫 번째 단계 이후 어느 시점이든 오류가 발생하면 메시지가 이미 확인되었으며 데드 레터 주제로 이동하지 않습니다.
대신 파이프라인에서 데드 레터 패턴을 명시적으로 구현하세요. 일부 I/O 싱크에는 데드 레터 큐에 대한 지원 기능이 내장되어 있습니다. 다음 예는 데드 레터 패턴을 구현합니다.
Pub/Sub 1회만 전송
Dataflow에는 단 한 번 처리를 위한 자체 메커니즘이 있으므로 Dataflow에서 Pub/Sub 정확히 한 번 전송을 사용하는 것은 권장하지 않습니다. Pub/Sub 일회성 전송을 사용 설정하면 동시 처리에 사용할 수 있는 메시지 수가 제한되므로 파이프라인 성능이 저하됩니다.
Pub/Sub 메시지 순서 지정
메시지 순서 지정은 구독자가 메시지가 게시된 순서대로 메시지를 수신할 수 있는 Pub/Sub의 기능입니다.
다음과 같은 이유로 Dataflow에서 메시지 순서를 사용하는 것은 권장되지 않습니다.
- Pub/Sub I/O 커넥터가 메시지 순서를 보존하지 않을 수 있습니다.
- Apache Beam은 요소가 처리되는 순서에 관한 엄격한 가이드라인을 정의하지 않습니다. 따라서 다운스트림 변환에서 순서가 보존되지 않을 수 있습니다.
- Dataflow에서 Pub/Sub 메시지 순서를 사용하면 지연 시간이 늘어나고 성능이 저하될 수 있습니다.
다음 단계
- Pub/Sub 및 Dataflow를 사용한 스트림 처리: Qwik Start(자체 진행 실습)
- Pub/Sub에서 BigQuery로 스트리밍
- Dataflow를 사용하여 Pub/Sub에서 메시지 스트리밍
- 스트리밍 파이프라인
- Dataflow에서 단 한 번 처리
- 람다 이후: Dataflow에서 단 한 번에 처리, 1부 및 3부: 소스와 싱크 (블로그)