Dataflow の仕組み: 誕生秘話
Google Cloud Japan Team
※この投稿は米国時間 2020 年 8 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: 本記事は Dataflow の開発に至った Google 内部の歴史と、Google Cloud サービスとしての Dataflow の機能、市場における他社製品との比較対照について掘り下げる 3 回シリーズのブログの第 1 回です。
Google のスマート分析プラットフォームの一部である Google Cloud の Dataflow は、ストリーム データとバッチデータの処理を統合するストリーミング分析サービスです。Dataflow に対する理解を深めるために、MillWheel から始まるその歴史も理解しておくとよいでしょう。
Dataflow の歴史
Google の多くのプロジェクトと同様、MillWheel は 2008 年に小さなチームが考案した大胆なアイデアから誕生しました。プロジェクトの開始時、このチーム（リーダーは Paul Nordstrom）は、MapReduce がバッチデータ処理のために行っていたこと、つまり強力な抽象化機能の提供と大容量へのスケールをストリーミング データ処理に対しても行えるシステムを作成したいと考えました。初期段階では、システムの要件を順次決定して最新版の負荷テストを行っていた、一握りの主要な Google 社内ユーザー（Google 検索と Google 広告のユーザー）しかいませんでした。
MillWheel が行ったのは、クリックログを処理するパイプラインを構築して、お客様のために Google 検索などのシステムを改善する方法をより深く理解するため、リアルタイムでセッション情報の算出を試みることでした。この段階まではセッション情報を毎日算出しており、早朝に多数のマシンを稼働し、エンジニアが朝ログインするときまでに結果を生成していました。この状況を変えようと、MillWheel がこの負荷を分散して丸 1 日かけてテストするようにしたところ、リソース使用量がより予測可能となり、データ鮮度も大幅に向上しました。セッションの長さは一定でないため、この Google 検索のユースケースのおかげで、ウォーターマークやタイマーなどの MillWheel の重要コンセプトを早いうちに考案するきっかけが生まれました。
このセッションのユースケースとともに、初期バージョンのトレンド検索クエリを調査するため、Google Zeitgeist（現 Google トレンド）チームとの共同作業も開始されました。この調査のため、基準値に対する変動を確認できるよう、任意のキーワードの検索による最新のトラフィックと過去のトラフィックを比較する必要がありました。これを行ったことで、初めてのクエリや再度見かけることのない 1 回限定のクエリといったケースを処理するために、状態の集約と管理ならびにシステムの効率改善に関して初期に行った多くの作業がはかどりました。
MillWheel の構築時には、現在ストリーミング データ処理に取り組んでいるデベロッパーにはなじみ深い、多くの問題に直面しました。まず、ストリーミング システムに関しては、バッチ パイプラインを再実行することにより、任意の入力に対して同じ「最適」出力が生成されるかどうかを確認できないため、正確性をテストして検証することがはるかに困難です。Google が行ったストリーミング テストでは、Google が開発した初期のフレームワークの 1 つを「数字」パイプラインと呼んでいました。これは、1～1e6 の入力を異なる時間帯にずらして配置し、これらを集約して、最後に出力を検証するものでした。この構築には少々の困難が伴いましたが、多くのバグを発見できたため、構築した甲斐がありました。
Dataflow は、Google が過去に成し遂げてきた数々のイノベーションにおける最新の成果です。Dataflow を構築したエンジニア（共同リーダーは Frances Perry）はまず、MillWheel を構築することでストリーミング システムの試験運用を行いました。このシステムではタイマー、状態管理、ウォーターマークに関する中心的なセマンティクスの一部が定義されましたが、多くの用途で使用が困難であることがわかりました。これらの問題の多くは、MapReduce（実際には map-shuffle-combine-reduce）の複数のロジック オプションを同時に実行するユーザー向けに Google が Flume を構築するきっかけとなった問題に似ていました。そこで、これらの問題に対処するため、Streaming Flume という、プログラミング パイプライン用の高レベルモデルを試験運用しました（Apache Flume とは関係ありません）。このモデルでは、ユーザーが演算ノードとその間のストリームなどの物理的詳細ではなく、データセットと変換の観点から推論できました。
その後、Google Cloud 用に何かを構築する段階になり、将来に向けた大きな目標を持って学んだことを最適に組み合わせたシステムを構築したいと考えました。Dataflow の構築時には、バッチ形式の Flume と Streaming Flume のセマンティクスを取り込んでストリーミングとバッチのセマンティクスを統合する単一システムに集約できるかが大きな賭けとなりました。実際、Google はシステム構築の基礎となる技術をすでに多数開発しており、その技術を Dataflow のセマンティック モデルから技術を分離することに成功しています。このシステムのおかげで、ユーザー パイプラインを大きく書き換えることなく、この実装を時間の経過に合わせて継続的に改善できています。この過程で Google は、データ処理に対する自社の取り組み、特にストリーミング システムに関する出版物を多数製作しました。これらの出版物は、以下でご覧いただけます。
●Millwheel: Fault-Tolerant Stream Processing at Internet Scale
●FlumeJava: Easy, Efficient Data-Parallel Pipelines
Dataflow の仕組み
ここで、Dataflow の主要なコンセプトを簡単に見てみましょう。ストリーミング システムとしての Dataflow は、ある種の決まったしきい値（レコード数や時間枠など）に従わず、レコードが到着次第処理します（または送出できます）。ユーザーは確認する出力を定義する際にこれらの決まったセマンティクスを指定でき、基盤システムではストリーミング入力とストリーミング出力がサポートされます。Dataflow 内では、イベント時間の考え方が重要コンセプトとなっています。これは、あるイベントが（処理された時間ではなく）発生した時間に対応するタイムスタンプです。多くの有益なアプリケーションをサポートするには、システムでイベント時間を採用することが重要です。これにより、ユーザーは「午前 1 時から 2 時までに何人がログインしたか」といった質問ができるようになります。
Dataflow と比較対象になることが多いアーキテクチャの 1 つにラムダ アーキテクチャが挙げられます。ラムダ アーキテクチャでは、ユーザーがあるパイプラインの並行コピー（1 つのストリーミング、1 つのバッチ）を実行して、結果（多くの場合、部分的な結果）の「高速」コピーと正しいコピーを取得します。この手法には、1 つではなく 2 つのシステムを実行する場合に確実に掛かる費用（計算、運用、および開発に掛かる費用）を含め多くの短所があります。また、ラムダ アーキテクチャではソフトウェア エコシステムの大きく異なるシステムが使用されることが多いため、両方のシステムで複雑なアプリケーション ロジックを複製することが困難であることにも留意する必要があります。最後に 2 つのパイプラインの出力を突合することも重要です。これは、Dataflow で解決された主要な問題の一つです。ユーザーは、一度アプリケーション ロジックを記述すると、早く出力される（ただし不完全な可能性のある）結果が必要か、遅く出力される（ただし正しい）結果が必要か、その両方が必要かを選択できるようになります。
ラムダ アーキテクチャと比較した Dataflow の利点を実証するため、オンライン販売と実店舗での販売を行っている大手小売業者のユースケースについて考えてみましょう。このような小売業者は、実店舗の従業員が使用する実店舗内の BI ダッシュボードの恩恵を受けます。このダッシュボードには、買い物客が欲しいものを探しやすくしたり、顧客に人気の商品を調べたりするのに役立つ、地域および世界中の在庫情報を表示できます。このダッシュボードは、中央または各地域のチームによる在庫配分に関する決定を支援するためにも使用できます。ラムダ アーキテクチャの場合、これらのシステムでは後からバッチ処理で修正される最新情報が遅れて表示される傾向にありますが、特に年末商戦などの書き入れ時など、修正前の段階で、実際には残り少ない商品の在庫数が誤って多く表示されることがあります。このような不適切な結果が表示されることにより、小売業においては顧客に悪い印象を与え、サイバーセキュリティなどの他の業界においては異常に気付かずにシステムへの不正侵入を許すことにつながります。Dataflow を導入すると、データが常に最新状態に保たれ、確保されていない在庫情報の表示を防ぐことで顧客により良いサービスを提供でき、サイバーセキュリティ分野では警報システムの信頼性を確保できます。
以上が Dataflow の大まかな誕生ストーリーですが、この他にも考察すべき興味深いコンセプトがあります。詳細は、Dataflow の他のブログ「仕組み（Under the Hood）」シリーズでご確認ください。
-プリンシパル エンジニア Sam McVeety
-プロダクト マネージャー Ryan Lippert
