Pub/Sub を使用したストリーミング

このページでは、Dataflow と Pub/Sub の統合の概要について説明します。また、Dataflow ランナーで Pub/Sub I/O コネクタを実装する際に利用できる最適化についても説明します。Pub/Sub は、スケーラブルで耐久性のあるイベントの取り込みおよび配信システムです。ウィンドウとバッファリングを使用する場合、Dataflow は、Pub/Sub のスケーラブルな「最低 1 回」配信モデルに、メッセージ重複排除と「1 回限り」「正しい順序」の処理機能を追加します。Dataflow を使用するには、Apache Beam SDK でパイプラインを記述し、Dataflow サービスでパイプライン コードを実行します。

開始する前に、Apache Beam とストリーミング パイプラインの基本的なコンセプトをご確認ください。詳細については、次のリソースをご覧ください。

Pub/Sub を使用したストリーミング パイプラインの構築

Dataflow と Pub/Sub の統合のメリットを得るには、次のいずれかの方法でストリーミング パイプラインを構築します。

Pub/Sub と Dataflow の統合機能

Apache Beam は、Pub/Sub 向けのリファレンス I/O ソース実装(PubsubIO)を提供しています(JavaPython)。これは、Apache Spark ランナー、Apache Flink ランナー、Direct Runner など、Dataflow 以外のランナーによって使用されます。

Dataflow ランナーは PubsubIO の別のプライベート実装を使用します。この実装では、Google Cloud 内部の API とサービスを利用しています。これにより、低レイテンシのウォーターマーク、高精度のウォーターマーク(つまりデータ完全性)、効率的な重複排除という主要な 3 つの利点が得られます。

低レイテンシのウォーターマーク

Dataflow は Pub/Sub のプライベート API にアクセスできます。これにより、Stackdriver よりも低いレイテンシで、サブスクリプション内の確認応答されていない最も古いメッセージの経過時間を得ることができます。比較を示すと、Stackdriver で提供される Pub/Sub バックログ指標には通常 2~3 分の遅延が発生しますが、Dataflow の遅延は約 10 秒です。これにより、Dataflow はパイプライン ウォーターマークを先に進めて、ウィンドウ処理された計算結果をより早く出力できます。

高精度のウォーターマーク

イベント時刻で定義されたウィンドウには強力なウォーターマークが必要になるという問題がありますが、この問題も Dataflow と Pub/Sub の統合によってネイティブに解決されます。イベント時刻は、パブリッシャー アプリケーションによって、Pub/Sub メッセージの属性として指定されたタイムスタンプであり、Pub/Sub サービスによってメッセージに設定された publish_time フィールドではありません。Pub/Sub では、サービスによって割り当てられた(処理時刻の)タイムスタンプに関してのみバックログ統計が計算されるため、イベント時刻のウォーターマークを推測するには別のメカニズムが必要です。

この問題を解決するため、ユーザーがカスタムのイベント タイムスタンプを使用する場合、Dataflow サービスは第 2 のトラッキング サブスクリプションを作成します。このトラッキング サブスクリプションを使用して、ベースとなるサブスクリプションのバックログ内にあるメッセージのイベント時刻を検査し、イベント時刻のバックログを推測します。詳しくは、StackOverflow の Dataflow で Pub/Sub ウォーターマークを計算する方法に関するページをご覧ください。

効率的な重複排除

「1 回限り」のメッセージ処理を行うには、メッセージの重複排除が必要になります。Dataflow は、Pub/Sub メッセージ ID に基づいてメッセージの重複排除を行います。その結果、すべての処理ロジックにおいて、Pub/Sub メッセージ ID に基づいてメッセージが一意になっていると想定できます。これを達成するための効率的な増分集約メカニズムは、PubsubIO API の中で抽象化されています。