このページでは、Pub/Sub からの読み取り、BigQuery への書き込み Dataflow パイプラインの最適化のためのベスト プラクティスについて説明します。ユースケースによっては、次の方法によりパフォーマンスが向上する可能性があります。
パイプラインのバックログにおける初期的なソリューション
Pub/Sub から BigQuery へのパイプラインでバックログが増加し、受信メッセージに対応できなくなった場合は、すぐに次の手順を実行します。
- Pub/Sub の確認応答期限を延長する: 関連する Pub/Sub サブスクリプションの確認応答期限を延長し、想定されるメッセージ処理の最大時間よりも少し長い値にします。これにより、処理中のメッセージが早くに再配信されるのを防ぐことができます。
- ワーカーをスケールアウトする: 未確認メッセージの数とサブスクリプション バックログが急速に増加している場合、パイプラインの処理能力が不足している可能性があります。メッセージ量を処理するために、Dataflow ワーカーの数を増やします。
- 指数バックオフを有効にする: 指数バックオフを有効にして、パイプラインが一時的な問題の再試行処理の方法を改善し、復元力を高めます。
コードとパイプラインの長期的な最適化
パフォーマンスと安定性を維持するには、アーキテクチャとコードを次のように変更することをおすすめします。
- BigQuery への
getTable呼び出しを減らす:getTableメソッドの呼び出しが多すぎると、レート制限やパフォーマンスのボトルネックが発生する可能性があります。この問題を軽減するには:- 同じテーブルに対する呼び出しが繰り返されないように、ワーカーのメモリにテーブルの存在情報をキャッシュに保存します。
- 個々の要素ごとではなく、バンドルごとに
getTable呼び出しをバッチ処理します。 - すべてのメッセージごとにテーブルの存在を確認する必要がないように、パイプラインコードをリファクタリングしてください。
- BigQuery Storage Write API を使用する: BigQuery に書き込むストリーミング パイプラインの場合は、標準のストリーミング挿入から Storage Write API に移行してください。Storage Write API を使うとパフォーマンスが向上し、割り当てが大幅に増加します。
- カーディナリティの高いジョブには以前の Dataflow ランナーを使用する: 非常に多くの一意のキー（カーディナリティが高い）を処理するジョブでは、クロス言語変換が必要な場合を除き、以前の Dataflow ランナーの方が Runner v2 よりもパフォーマンスが優れている可能性があります。
- キー空間を最適化する: パイプラインが数百万のアクティブ キーを操作する場合、パフォーマンスが低下する可能性があります。より小さく管理しやすいキー空間で処理が行われるよう、パイプラインのロジックを調整してください。
リソース、割り当て、構成の管理
パイプラインの健全性を維持するには、リソースの適切な割り当てと構成が不可欠です。
- 割り当てを事前に管理する: 割り当てをモニタリングし、スケーリング イベント中に上限に達する可能性がある割り当ての引き上げをリクエストします。たとえば、次のスケーリング イベントについて考えてみましょう。
TableService.getTableメソッドまたはtabledata.insertAllメソッドの呼び出しレートが高いと、最大秒間クエリ数（QPS）を超える可能性があります。上限と割り当ての追加をリクエストする方法については、BigQuery の割り当てと上限をご覧ください。- 使用中の IP アドレスと CPU の Compute Engine の割り当てが上限を超えることがあります。上限と割り当ての増加をリクエストする方法について詳しくは、Compute Engine の割り当てと上限の概要をご覧ください。
- ワーカー構成を最適化する: メモリ不足（OOM）エラーを防ぎ、安定性を向上させるには: