レイテンシと費用のバランスを制御する新たな方法で Dataflow ジョブの柔軟性を向上
Yi Ding
Software Engineer, Google Dataflow Streaming
Yuriy Zhovtobryukh
Senior Product Manager, Google Cloud
※この投稿は米国時間 2024 年 5 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。
Dataflow Streaming Engine のユーザーは、「平均的な」ストリーミングのユースケースのようなものはないと認識しています。お客様によっては、レイテンシに関する厳しい要件があり、トラフィックの急増時でもその要件を満たす必要があります。また、費用の方を重視して、ストリーミング パイプラインをできるだけ効率的に実行したいと考えるお客様もいます。問題は、ワークロードについて、ピーク時のレイテンシの低減と、ストリーミング費用の削減のどちらを優先させるかです。
たとえば、ネットワーク脅威検出のユースケースでは、サイバー攻撃をリアルタイムで特定して対応できるようにすることが不可欠です。このようなリアルタイムのシナリオでは、リソースをより積極的にプロビジョニングして、できるだけ低いレイテンシを維持する方が望ましいでしょう。一方、プロダクト分析のようなユースケースでは、30~60 秒の遅延は許容されるため、リソースをより控えめにプロビジョニングして費用を抑えるのが正しい判断と思われます。
オートスケーラーのアルゴリズムは、ピーク時のレイテンシとパイプライン費用に大きく影響します。より積極的な自動スケーリング戦略では、トラフィックの増加時にデータを処理するリソースを迅速に追加することで、低レイテンシを維持します。一方、あまり積極的でない自動スケーリング アプローチでは、リソースを控えめに管理することで、費用を最小限に抑えることを目指します。このようなアルゴリズムは相当な影響を及ぼす可能性があります。では、Pub/Sub イベントを BigQuery に取り込む、次の典型的なストリーミング ジョブについて考えてみましょう。
Pub/Sub から BigQuery へのこの特定の Dataflow パイプラインは、自動スケーリングのヒント値を、レイテンシを最小限にする場合は 0.3 に、費用を最小限にする場合は 0.7 に変更することで、レイテンシを 82% 低減するか、費用を 24.5% 削減するかを選択できる方法を示しています。
![https://storage.googleapis.com/gweb-cloudblog-publish/images/1-TradeLatencyforCost.max-2200x2200.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/1-TradeLatencyforCost.max-2200x2200.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/1-TradeLatencyforCost.max-2200x2200.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/1-TradeLatencyforCost.max-2200x2200.png)
ご自身のストリーミング パイプラインの曲線は、このテスト パイプラインの曲線とは形状がかなり異なる場合もありますが、それでも中心となる考え方は同じです。つまり、Dataflow ストリーミングのユーザーは、自動スケーリング使用率のヒント値を変更することで、レイテンシの低減と費用の削減のどちらを優先させるかを設定および変更できます。
特定のストリーミング パイプラインに最適なヒント値を見つける
オートスケーラーの決定の中心となるのは、パイプラインの計算を実行するワーカーの CPU 使用率です。Dataflow のストリーミング オートスケーラーは、現在のワーカーの使用率がワーカー CPU 使用率の許容上限を超えるとスケールアップし、ワーカー CPU 使用率の下限を下回るとスケールダウンする傾向があります。Dataflow サービス オプションを使用して、自動スケーリング使用率のヒント値をより高い値またはより低い値に設定できます。この値を設定することで、ユースケースの費用とレイテンシに関する決定をエンコードできます。
難しいのは、特定のストリーミング パイプラインに最適なヒント値を見つけることです。経験則として、パイプラインが以下の場合には、自動スケーリング使用率のヒント値を小さくして、レイテンシの低減を実現することを検討する必要があります。
-
スケールアップが遅すぎる: 自動スケーリングがトラフィックの急増に遅れをとり、バックログの秒数が増え始めている場合。
-
スケールダウンしすぎている: 現在のワーカー CPU 使用率が低く、バックログが増えている場合。
逆に、過度のアップスケーリングが観察されており、ワーカー使用率が高く、そのユースケースで高いレイテンシが許容される場合に費用を削減したいときには、自動スケーリング使用率のヒント値を大きくして、費用を削減することを検討する必要があります。
「普遍的な」最小限の費用またはレイテンシの自動スケーリング使用率のヒント値はありません。費用とレイテンシの曲線の形状(上述のグラフ例の曲線のような形状)は、それぞれのストリーミング ジョブに固有なものです。また、パイプラインのプロパティは、たとえばトラフィック パターンのバリエーションなどによって変わるため、最適な値は時間の経過とともに変化または「ドリフト」することもあります。
Dataflow の自動スケーリング UI は、自動スケーリング動作を調整すべきタイミングについての分析情報を提供します。ジョブを停止せずに、リアルタイムで自動スケーリングのヒント値を修正して、変化するデータ負荷に対処し、ビジネス要件を満たすことができます。現在のワーカー使用率指標は重要なヒューリスティックであり、まずは自動スケーリングのヒント値をこれに合わせて調整するとよいでしょう。
変更の影響をモニタリングする
また、自動スケーリングのパフォーマンスを簡単に評価して、好みに合わせてファインチューニングできるように、Dataflow 自動スケーリング UI にダッシュボードと指標が追加されました。
特に、次の 4 つのグラフを観察することから始めるとよいでしょう。
-
自動スケーリング: 現在のワーカー数とターゲットのワーカー数を表示し、時系列の自動スケーリング データを、ワーカーの最小数 / 最大数とターゲット数とともに表示します。
-
自動スケーリングの根拠: 自動スケーリングの決定(アップスケール、ダウンスケール、変更なし)に導いた要素について説明します。
-
ワーカー CPU 使用率: 現在のユーザーのワーカー CPU 使用率とお客様向けのヒント値(自動スケーリングの決定でアクティブに使用されている場合1)を表示します。これは自動スケーリングの決定における重要な要素です。
- 最大バックログの推定秒数グラフは、パイプラインのレイテンシを示します。これは、自動スケーリングの決定におけるもう一つの主要な要素です2。
![https://storage.googleapis.com/gweb-cloudblog-publish/images/2-AutoscalingChart.max-1200x1200.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/2-AutoscalingChart.max-1200x1200.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/2-AutoscalingChart.max-1200x1200.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/2-AutoscalingChart.max-1200x1200.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/3-AutoscalingRationale.max-700x700.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/3-AutoscalingRationale.max-700x700.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/3-AutoscalingRationale.max-700x700.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/3-AutoscalingRationale.max-700x700.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/4-WorkerCPU.max-700x700.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/4-WorkerCPU.max-700x700.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/4-WorkerCPU.max-700x700.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/4-WorkerCPU.max-700x700.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_MaxBacklog.max-600x600.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_MaxBacklog.max-600x600.png)
![https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_MaxBacklog.max-600x600.png](https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_MaxBacklog.max-600x600.png)
ここまでお読みいただきありがとうございます。Dataflow Streaming Engine ユーザーの皆様が、これらの機能を活用して、Dataflow をさまざまな方法で使用してビジネスを変革されることを楽しみにしています。コンソールから直接 Dataflow を使ってみましょう。今後の最新情報にもご注目ください。詳しくは、Google Cloud セールスチームにお問い合わせください。
1. 自動スケーリングに関するお客様向けヒントは、オートスケーラーの決定に影響を与える要素の一つにすぎないことにご注意ください。他の要素との兼ね合いにより、オートスケーラーのアルゴリズムでこれが無効になる可能性もあります。詳しくはこちらをご覧ください。
2. バックログが多い場合、低レイテンシを維持するために、自動スケーリング使用率のヒントは、自動スケーリング ポリシーで無視されます。詳しくはこちらをご覧ください。
ー Google Dataflow ストリーミング、ソフトウェア エンジニア Yi Ding
ー Google Cloud、シニア プロダクト マネージャー Yuriy Zhovtobryukh