Yahoo、2 つのストリーミング ユースケースで Dataflow とセルフマネージド Apache Flink を比較

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

Yahoo は、大規模なデータ処理パイプラインのストリーミングの効率を最適化する方法を常に模索しています。Google Cloud と Yahoo が実施した最近のプロジェクトでは、セルフ マネージド環境の Apache Flink と Google Cloud Dataflow という 2 つのスタック選択肢における、2 つの具体的なユースケースの費用とパフォーマンスのベンチマークに重点を置きました。

この投稿では、ベンチマークの設定、方法論、対象範囲のユースケース、主な調査結果、パフォーマンスの合理化に役立った Dataflow 構成について詳しく説明します。これらの知見が、独自のストリーミング パイプラインを最適化する新たな方法を探している皆様のお役に立てば幸いです。

ベンチマークの設定

ベンチマークの設計では、Yahoo の一般的なユースケースを迅速かつ公平かつ大まかに比較できるよう、コンピューティング負荷の高いワークロードと IO 負荷の高いワークロードという 2 つの代表的なワークロードを選択しました。このベンチマークの結果を見れば、ストリーミング（Bigtable、Cloud Storage、および下記のその他複雑なストリーミング パイプラインへの結果の書き込みを含む）のプラットフォームとして何を Yahoo チームに推奨すべきかがわかります。

テスト セットアップ インフラストラクチャ

テスト セットアップとして、以下のように環境を構成しました。

• 指標: 私たちの主な焦点は、スループット単位あたりのコンピューティング費用、つまり時間単位あたりに処理されるデータ量でした。Apache Flink と Dataflow のパイプラインを 1 秒あたり 20,000 レコードの持続スループットで実行する費用を把握することを目指しました。Flink の「費用」には、それぞれのプラットフォームでジョブを設定して実行する運用オーバーヘッド（エンジニアリングにかかる時間）は含まれません。

• ワークロード: Pub/Sub からの 10 TB のデータ ストリームをシミュレートし、一定の負荷を維持するために 1 億件を超えるレコードのバックログを作成しました。

• 制御された環境: 特定の構成による影響に焦点を当てるために、Flink のリソース割り当てを固定し、Dataflow ワーカー数に制限を設定することで最初は自動スケーリングを無効にしました。これにより、一貫したスループットでの費用、つまりスループット単位あたりの費用を比較できるようになりました。この実験では、ベンチマーク結果が十分でなかった場合、マネージド Flink と Dataflow の操作のしやすさ（運用コスト、リソース管理コスト）の観点から自動スケーリングをテストすることを検討します。ただし、ベンチマーク結果が十二分なものであったため、自動スケーリング管理リソースについて検討する必要はありませんでした。

ユースケースの詳細: 

前述のように、私たちは 2 つの典型的なユースケース（1 つはコンピューティング重視、もう 1 つは I/O 重視）を評価しました。

1. Parquet への Avro の書き込み（I/O 集中型）: このユースケースは、Avro メッセージを読み取り、特定の時間枠（1～5 分）にウィンドウ化して、Parquet として Cloud Storage に出力するストリーミング ジョブです。

2. データの拡充と計算（コンピューティング負荷が高い）: このワークロードは、アクティブ ユーザーの分析とイベントの拡充をシミュレートします。これには、Beam の状態管理、キーの再シャッフル、および別のサービスへの外部呼び出しが含まれます。

注:

• 両プラットフォームのインフラストラクチャを管理するための運用コストは除外しました。

• ベンチマークで Apache Flink と Dataflow 両方のインフラストラクチャの費用が類似していることが示された場合でも、マネージド サービスである Dataflow を選択していたでしょう。上記の 2 つのユースケースが決定的でない場合に備えて、3 番目のユースケースをベンチマークする準備ができていました。  

結果を確認する

結果から、Dataflow は、テストケースにおいてセルフマネージド Apache Flink と比較して 1.5～2 倍ほど費用対効果が高いことがわかります。これらの数値をどのように達成したかを詳しく見ていきましょう。

このベンチマークの目的は、同様のスループットを達成できる Flink と Dataflow の費用を計算し、各ストリーミング アプリケーションで 1 秒あたりに処理されるメッセージ数をできるだけ近づけることです。上の表では、エンリッチメント ユースケースの場合、GKE でプロビジョニングされた vCPU の数が Dataflow と比較して約 13 倍多くなっています。これは、Flink が非効率的だからではなく、Dataflow では Streaming Engine が大量かつ負荷の高いコンピュート処理を Dataflow バックエンドに送信するからです。もちろん、Flink の使用率を改善する余地はありましたが、それを行うとジョブが不安定になることが判明したため、それ以上の時間を費やすことはせず、使用率が約 75% であるとして 32 個の vCPU（2 x n2d-standard-16 マシン）の費用を計算しました。

Dataflow バックエンドは、Dataflow のワーカーで実行するのではなく、負荷の高いコンピュート処理（シャッフルなど）を実行するための Google Cloud バックエンド リソースと考えることができます。これにより、Dataflow に必要な vCPU の数が少なくなり、堅牢性と、より一貫したスループットが実現します。これは、Yahoo のユースケースで Streaming Engine を活用できるようにするうえで重要です。

下の画像では、Dataflow パイプラインは、Streaming Engine Processing Unit に基づいて費用を計算する、新しくリリースされた費用課金機能を使用しています。テストの結果、新しい課金機能は、スループットに基づくワークロードのパイプライン費用を最適化できることがわかりました。Flink 側では、テレメトリをインストールし、Pub/Sub スループットをモニタリングして、使用されているリソースの量を確認しました。Flink のセットアップでは、ジョブのチューニングにあまり時間をかけなかったため、使用率が向上した場合の費用が最も低くなると想定しました。つまり、ベストケースとして約 75% の CPU 使用率が得られると想定して、32 個の vCore を使用することを前提とした費用にしていました。

Dataflow の費用の詳細な内訳を確認するには、次のように Dataflow の [費用] タブに移動します。

設定をデプロイするために使用する Dataflow コマンドは次のとおりです（Gradle 内）。

元の Dataflow Streaming Engine の使用量は、現在、Streaming Engine によって処理されるデータの量に基づいて計測および課金されます。リソースベースの課金モデルでは、ジョブは消費されたリソースに基づいて計測され、ユーザーは消費されたリソースの合計に対して課金されます。つまり、Streaming Engine コンピューティング単位は「リソース ベースの課金」の計算に使用されます。以前は、Streaming Engine の費用は送信 / 処理されるデータの量（処理されるデータの合計 GB）によって計算されていました。

新しいリソースベースの課金モデルが使用されたかどうかを確認する

• 「リソースベースの課金モデル」を使用する場合は、処理されたストリーミング データの量ではなく、SKU（在庫管理単位）に基づいて課金されます。

• [費用] タブには、[処理済みデータ] ではなく [Streaming Engine コンピューティング単位] が表示されます。

基本的なパラメータを調整するだけでなく、マシンタイプを特定のワークロードに合わせて慎重にカスタマイズすることで、Dataflow をさらに最適化できます。Dataflow Prime は、シナリオによってはパフォーマンスと費用効率の両方を向上させることもできます。

Dataflow パイプラインを最適化する

Dataflow パイプラインを最適化する場合、慎重な構成と継続的なテストが重要であることがベンチマークによってよくわかります。Dataflow デプロイの理想的な設定は、特定のワークロード、データ速度、許容できるコスト パフォーマンスのトレードオフに大きく依存します。ワーカー構成から自動スケーリングなどの機能まで、Dataflow 内のさまざまな最適化ツールを理解することは、効率を最大化し、費用を最小限に抑えるために不可欠です。

この調査でテストした 2 つのユースケースでリソースベースの課金を使用したところ、Apache Flink のコンピューティング費用は Dataflow と同等であることがわかりました。ただし、このフラグを使用しないと、Dataflow は 5 倍高額になります（これも、この調査の範囲内の 2 つのユースケースの場合）。費用を管理するには、利用可能な自動化ツールを活用することを強くおすすめします。

最後に、Dataflow の新機能にもご注目ください。最近導入された 1 回以上のストリーミング モードにより、費用の削減とレイテンシの短縮のために重複が場合によって許容されるユースケースで柔軟性が向上します。

Dataflow を試す準備はできましたか？詳細をご確認のうえ、$300 分のクレジットを使用して今すぐお試しください。

-Google、データ エンジニア Ihaffa Murtopo

-Yahoo、シニア プリンシパル ソフトウェア エンジニア Abel Lamjiri 氏