Dataflow の仕組み: Dataflow の手法について

※この投稿は米国時間 2020 年 8 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 本記事は Dataflow の開発に至った Google 内部の歴史と、Google Cloud サービスとしての Dataflow の機能、市場における他社製品との比較対照について掘り下げる 3 回シリーズのブログの第 2 回です。第 1 回の記事をご参照ください。Dataflow の仕組み: 誕生秘話

本シリーズの第 1 回では、Google 内での Dataflow 開発の背景について取り上げ、ラムダ アーキテクチャとの比較について解説しました。今回は Dataflow を動かす主要なシステムのいくつかについて、もう少し詳しく見ていきましょう。第 1 回で述べたように、Dataflow にはそれまでのシステムのために構築した数多くのテクノロジーが活用され、新たな手法もいくつか開発されました。

Google のタイマー システムの起源は、初期の MillWheel システムにさかのぼります。MillWheel システムでは、処理ロジックをトリガーするためのタイマーの設定にユーザーが直接アクセスできるようになっていました。これは、概念的には他のスケジュール システムとあまり変わりません。ユーザーは任意の数のアラームを設定し、システムが適切な時間にアラームをトリガーします。Google では永続性を高めるために、こうしたタイマーをバックアップ保存先（Cloud Bigtable データベースなど）に保管し、そのサブセットをキャッシュを使用してメモリに保存しています。そのため、新しく設定されるタイマーはすべてメモリ内に保管され、キャッシュは非同期的に更新できるので、ストレージからの読み取りにホットパスを使用する必要がありません。

タイマーに関して気づきにくいですが、重要な点の一つは、イベント時間のタイマーをサポートする必要があることに起因しています。イベント時間のタイマーがトリガーされるためには、前のステージのデータが完全でなくてはなりません。このような完全性のマーカーはウォーターマークと呼ばれ、個別のコンポーネントによって管理されます。このコンポーネントは、現在のウォーターマークの値を判断するために任意のステージを処理するすべてのノードと通信します。次にウォーターマーク コンポーネントは、下流での関連するすべての計算にこれらの値を公開します。計算ではウォーターマークを使用して、イベント時間のタイマーをトリガーできます。このことがなぜ重要かを示す例として、従来の IoT のユースケースを考えてみましょう。たとえば機器にセンサーが取り付けられている製造ラインです。このようなセンサーは大量のデータを送信しますが、そのデータに関連付けられたウォーターマークによって、時間別あるいは製造サイクル別にデータをグループ化することができます。そのためデータが遅延したり順序がバラバラになったりしても、分析でデータが見逃されることがありません。

状態管理について理解する

Dataflow の状態管理には、タイマーと同様のコンセプトが活用されています。状態は永続的なストレージに保管され、速度と効率性のためにキャッシュに保存されます。MillWheel での経験から学んだことの一つは、ユーザーの状態操作に役立つ抽象化を提供する必要があるということです。アプリケーションによっては、受信した個々のレコードの保管状態すべてについて読み取りと書き込みを行う必要があるものや、サブセットのみの読み取りを必要とするもの、あるいは、全体へのアクセスがたまにしか行われないリストに追加するものなどがあります。Dataflow では、システムが最初から効率的で高速な状態で使用できるよう、適切なキャッシュ保存および永続性戦略と一体化した、関連する状態の抽象化を行うために取り組んできました。また、レコードの処理でのアトミック操作で状態の変更を行うことが重要だということがわかりました。他の多くのシステムでは、ユーザーに外部の状態システムを使用するよう求めていますが、この方法は適切に機能させることが簡単ではありません。前述の IoT のユースケースについて考えると、Dataflow の状態管理機能は、1 分あたりの機器の回転の集約とカウント、一定期間におけるセンサーの平均温度の算出、あるいは切削や鋳造工程のずれの平均値の計算といった作業を容易にし（つまりわずかなユーザーコードしか必要ありません）、セカンダリ システムとやり取りするための複雑な再試行ロジックが必要ありません。

ラムダ アーキテクチャが人気となっている主な理由は、ストリーム処理システムの exactly-once 処理への取り組みです（詳細についてはこちらのブログシリーズをご覧ください）。Dataflow は特定のステージに入った各レコードのフィンガープリントを保存することで、レコードに対して exactly once 処理を提供し、それを使用してそのレコードの再試行の重複除去を行います。当然ですがこれを単純な戦略で行うと無制限にフィンガープリントを確認しなければならなくなるため、ウォーターマーク アグリゲータを使用して、システムを完全に通過したレコードのフィンガープリントを、いつガベージコレクションできるかを判断します。また、このシステムでは、キャッシュ保存の幅広い使用、ブルーム フィルターの回転の使用などその他の最適化を活用します。

Dataflow のもう一つの特長は、パイプライン リソースの自動スケーリングをサポートする機能です。システムを動かす基盤となる作業割り当てを動的に再度割り振る手段を備えているため、ストリーミングとバッチ パイプラインの両方の動的スケーリング（スケールアップおよびスケールダウン）にも対応することが可能です。ストリーミング パイプラインの場合、この機能は各計算ステージの主な範囲に対応し、作業者間でその範囲を動的に変更、分割、結合させて負荷を分散することができます。システムは利用可能なノードの総数を増減させることによって、使用率の変化に対応します。また、タイマーおよび状態の分散したストレージから個別にこれらをスケールできます。IoT の現場の例を最後にもう一度考えると、この自動スケーリング機能があることで、センサーを増やしたりシグナルの頻度を増やしたりするために以前のような長時間の作業やサイクルのプロビジョニングは必要なくなりました。

次は、このシリーズの最終回となる第 3 回のブログをぜひご覧ください。第 3 回では市販されている他のテクノロジーのいくつかについて、Dataflow との比較対照を行います。

-プリンシパル エンジニア Sam McVeety

-プロダクト マネージャー Ryan Lippert