コンテンツに移動
データ分析

Dataflow の新しいカスタムソース読み取りで費用削減と効率化を実現

2024年9月19日
RuiLong Jiang

Software Engineer

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

ワークロードのスケーリングは、特に、レイテンシが厳しく問われるストリーミング環境では費用が高額になりがちです。費用やレイテンシは非効率によって増大するため、パイプラインをボトルネックなしで実行したくなるのは当然のことです。

これは特に、最新の自動チューニング戦略のほとんどに当てはまります。ホットキーやホットワーカーが処理のボトルネックとなり、バックログが蓄積されるたびに、データの鮮度が損なわれます。Apache Kafka は、パイプライン内にホットスポットを作成する可能性のあるストリーミング環境の一例です。オートスケーラーは、コンピューティング単位を追加して事後的に補おうとする場合がありますが、これは費用だけでなく、時間もかかります。オートスケーラーは蓄積されたメッセージのバックログが発生してからしか反応せず、新しいワーカーをスピンアップするためのオーバーヘッドが発生します。

この解決策として、Google は最近、ソースの読み取りを助けるために Dataflow にロード バランシングを導入しました。ワークロードをより適切に分散し、ロード バランシングによって負荷の高いワーカーの負荷を先を見越して軽減することで、より少ないリソースとより低いレイテンシでより多くのデータをプッシュできるようになります。

ユーザーへの実用的なメリット

以下に、本番パイプラインでロード バランシング導入のメリットを受けている Dataflow の主要なお客様の事例を紹介します。

ケース 1 - ロード バランシングによりユーザーとワーカーのスケーリング イベントが減少し、より少ないワーカーかつより優れたパフォーマンスでパイプラインを運用できるようになりました(ワーカーが 75% 減少した結果、Google Compute Engine での 1 日の費用が 64% 削減され、バックログは 1 分以下から 10 秒以下に減少)。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2-cpu_utilization.max-900x900.png

アイドル状態のワーカーに作業がオフロードされ、CPU 使用率が 10 パーセンタイルで増加

compute.googleapis.com/instance/cpu/utilization

ケース 2 - ロード バランシングにより、大量のバックログのためにワーカーが最大数に留まることがなくなり、入力レートに合わせてスケーリングできるようになりました(同じ入力レートでワーカーが 57% 減少した結果、Google Compute Engine での 1 か月の費用が 37% 削減され、ピーク時のバックログは 4.5 日以下から 5.2 時間以下に減少)。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3-backlog_per_worker.max-900x900.png

注: それぞれの色は、単一のワーカーとそれに割り当てられたワークロードを表しており、これらは外部からはまだ利用できません

ケース 3 - ロード バランシングにより、同じワーカー数でスループットが 27% 向上し、バックログが 1 日以下に減少しました。

ロード バランシングの仕組み

パイプラインの起動時に、Dataflow は特定のデータソースから受け取るデータ量を事前に知ることができません。実際、データ量はパイプラインが存在する間に変化する可能性があります。したがって、複数のトピックが関係する場合、次のような状況に陥る可能性があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5-topic_balancing.max-1800x1800.png

ワーカー 1 30 Mb/s の負荷に対応できない場合、トピック 2 を処理するために 3 つ目のワーカーを投入する必要があります。ロード バランシングを使用すると、パイプラインのバランスを取り戻し、そのパイプラインを 2 つのワーカーだけで対応できるようにして、より優れたソリューションを実現できます。

ロード バランシングを有効にすると、各トピックのライブ入力レートに応じて自動的かつインテリジェントに作業が分散され、ホットワーカーがパイプライン全体のボトルネックになるのを防げます。トピックの不均衡だけでなく、キーレベルごとの不均衡も検出してワーカー間でキーを再分配することで、核となるバランスを実現することもできます*

https://storage.googleapis.com/gweb-cloudblog-publish/images/6-worker_balancing.max-1100x1100.png

デフォルトで有効

Dataflow の本番環境におけるカスタムソース ロード バランシングは、7 月にすべてのリージョンで有効になりました。この機能は、すべての Dataflow ストリーミング エンジン パイプラインにおいて、デフォルトですべてのお客様にご利用いただけます。Dataflow Google Cloud Managed Service for Apache Kafka は、Google Cloud コンソールからご利用を開始できます。今後の最新情報にもご注目ください。詳しくは、Google Cloud セールスチームにお問い合わせください。

* ロード バランシングでは個々のキーを 2 つに分割できないため、ホットキーは軽減することしかできません。作業を適切に分割することが根本的に不可能な場合は、ロード バランシングによってパイプラインを修正することはできません。

ー ソフトウェア エンジニア RuiLong Jiang

投稿先