ボトルネックは、あるステップ、ステージ、またはワーカーがジョブ全体の処理速度を低下させている場合に発生します。ボトルネックは、ワーカーのアイドル状態やレイテンシの増加につながる可能性があります。
Dataflow がボトルネックを検出すると、ジョブグラフにアラートが表示され、[ステップ情報] パネルにボトルネックの種類と原因（わかっている場合）が表示されます。Dataflow は、ボトルネック検出情報を Stackdriver 指標にエクスポートします。この指標は、データを時系列で表示します。これにより、ボトルネックを過去にさかのぼって確認できます。
ボトルネックを理解する
Dataflow がストリーミング パイプラインを実行すると、一連のコンポーネント（ストリーミング シャッフル、ユーザー定義関数（DoFn）処理スレッド、永続状態のチェックポイントなど）でジョブが構成されます。データフローを容易にするため、Dataflow はキューを使用してこれらのコンポーネントを接続します。データはアップストリームからダウンストリームに push されます。
多くのパイプラインでは、全体的なスループット容量が単一のコンポーネントによって制約され、パイプラインにボトルネックが生じます。ボトルネックを通過できるデータのレートによって、パイプラインが入力データを受け入れて処理できる速度が制限されます。
たとえば、ストリーミング シャッフルのダウンストリームで DoFn 処理が行われるパイプラインについて考えてみましょう。これらの間のキューは、シャッフルされた未処理のデータをバッファリングします。DoFn 処理がストリーミング シャッフルで生成されるデータを迅速に消費できない場合、キューが増大します。ボトルネックが長期間続くと、キューが上限に達する可能性があります。上限を上回るシャッフルはこの時点で一時停止され、バックログは上流に伝播されます。上流のキューでもバックログが蓄積されると、最終的にデータソースにまで遅延が拡大し、パイプライン全体が入力に追いつかなくなります。
ボトルネックが発生すると、パイプラインのあるポイントだけがバックログの原因になっている場合でも、パイプラインの大部分が異常に見えることがあります。この挙動により、ボトルネックのデバッグが難しくなることがあります。ボトルネック検出の目的は、正確な場所と原因を特定して推測を排除し、根本原因を修正できるようにすることです。
遅延がしきい値である 5 分を超えると、Dataflow はボトルネックを検出します。遅延がこのしきい値を超えない場合、Dataflow はボトルネックを検出しません。
ボトルネックの検出では必ずしも対応が必要になるわけではなく、ユースケースによって異なります。パイプラインは、一時的な遅延が 5 分を超えても正常に動作します。ユースケースでこの遅延が許容される場合は、示されたボトルネックを解決する必要がない可能性があります。
ボトルネックの種類
Dataflow がボトルネックを検出すると、モニタリング インターフェースに問題の重大度が表示されます。ボトルネックは次のカテゴリに分類されます。
- 処理が停止しており、進行していない。
- このステップでパイプラインの進行が完全に停止します。
- 処理は進行中だが、追いついていない。
- パイプラインが受信したデータを到着した速度で処理できない。その結果、バックログが増加しています。
- 処理は進行中だが、バックログは一定のままである。
- パイプラインは進行中で、処理速度は入力速度と同程度です。処理はバックログが増加しない程度には高速ですが、蓄積されたバックログも大幅には減少していません。
- 処理は進行中であり、バックログを解消しつつある。
- バックログは減少していますが、現在のボトルネックにより、パイプラインのキャッチアップがこれ以上速くなることはありません。バックログを使用してパイプラインを開始した場合、この状態は正常である可能性が高く、介入は必要ありません。バックログが減少し続けているかどうかを確認するために、進捗状況をモニタリングします。
ボトルネックの原因
このセクションでは、検出可能なボトルネックの原因を一覧表示します。問題を解決するには、以下の情報を参考にしてください。複数の原因が存在し、それらが関連している場合もあります。たとえば、ワーカーのプロビジョニングが不足している場合、vCPU 使用率が高くなることがあります。vCPU 使用率が高いと、オペレーションの速度が低下し、キュー遅延が増加する可能性があります。ボトルネックの原因として、これらのすべてが原因分析に表示されることがあります。
- オペレーションの処理時間が長い
計算の処理時間が長い事象は、入力バンドルが
DoFnを実行するワーカーに送信され、結果が利用可能になるまでにかなりの時間が経過した場合に発生します。これは通常、ユーザーコード内のある長時間実行オペレーションの結果として発生します。その他の問題は、オペレーションの処理時間が長くなるという形で現れることがあります。たとえば、
DoFn内でスローされて再試行されたエラー、長期間の再試行、OOM などの要因によるワーカー ハーネスのクラッシュなどは、処理時間の長期化の原因となる可能性があります。影響を受ける計算がユーザーコードにある場合は、コードを最適化するか、実行時間を制限する方法を探します。デバッグを容易にするため、ワーカーログには 5 分以上スタックしているオペレーションのスタック トレースが表示されます。
- 永続状態の読み取りが遅い
計算処理が
DoFnの実行の一部として永続状態の読み取りにかなりの時間を費やしています。これは、永続状態が長すぎるか、読み取りが多すぎることが原因である可能性があります。永続状態のサイズまたは読み取りの頻度を減らすことを検討してください。基盤となる永続状態の遅延が原因で、一時的な問題が発生している可能性もあります。- 永続状態の書き込みが遅い
計算処理が処理結果の commit 中に永続状態の書き込みにかなりの時間を費やしています。これは、永続状態が長すぎるためである可能性があります。永続状態を短くすることを検討してください。これは、基盤となる永続状態の遅延による一時的な問題である可能性もあります。
- コミットが拒否される
データ処理が無効であるため、永続状態にコミットできません。これは通常、オペレーションの上限のいずれかを超えたことが原因です。詳細についてはログを確認するか、サポートにお問い合わせください。
- Apache Kafka ソース パーティションが不十分
Apache Kafka ソースの計算処理に十分なパーティションがありません。この問題を解決するには、次のことを試してください。
- Kafka パーティションの数を増やす。
- Kafka IO 読み取りを構成するときに
.withRedistribute()を使用した再分散を含めて、データをより効率的に並列化します。.withRedistributeNumKeys(N)（N > partitions）を含めて、鍵の合計数の上限を指定します。キーの数を制限することで、レコードのバンドルを通じて効率を高めることができます。 - 再分配シャッフルにかかる費用を最小限に抑えるには、
.withOffsetDeduplication()を使用します。このモードでは、シャッフルの一部として永続化する必要があるデータ量を最小限に抑えつつ、exactly-once 処理を実現します。
詳細については、Apache Kafka から Dataflow に読み込むの並列処理をご覧ください。
- ソースの並列が不十分
ソースの計算処理の並列処理が不十分です。可能であれば、ソース内の並列処理を増やします。並列処理を増やせない場合で、ジョブで at-least-once モードが使用されている場合は、パイプラインに
Redistribute変換を追加してみてください。- ホットキー、またはキーの並列が不十分
ジョブにホットキーがあるか、キーの並列処理が不十分です。
Dataflow は、シャーディング キーごとにメッセージを順次処理します。Dataflow が特定のキーのメッセージのバッチを処理している間、そのキーの他の受信メッセージは、現在のバッチが完了するまでキューに入れられます。
Dataflow が十分な数の異なるキーを並行して処理できないと、ボトルネックが発生する可能性があります。たとえば、データに個別のキーが少なすぎる場合や、特定のキーがデータ内で過剰に表現されている場合（「ホットキー」）などです。詳細については、処理速度が遅いジョブや停止しているストーミング ジョブのトラブルシューティングをご覧ください。
- vCPU のプロビジョニングが不十分
ジョブに十分なワーカー vCPU がありません。この状況は、ジョブがすでに最大までスケーリングされ、vCPU 使用率が高く、バックログが残っている場合に発生します。このジョブにプロビジョニングされるワーカーの最大数を増やす必要がある場合があります。たとえば、自動スケーリングの範囲を変更して、この数を増やすことができます。または、パイプライン コードやワークロードを変更して vCPU 使用率を減らす方法を探します。Cloud Profiler を使用して、最適化の機会を探すことができます。
- vCPU 使用率が高く、アップスケールが必要
ジョブの vCPU 使用率は高いものの、アップスケールする余地があります。この状態は、アップスケーリングが可能になるまで一時的に発生する可能性があります。自動スケーリングをモニタリングして、自動スケーリングの決定を確認できます。この状態が長時間続く場合や頻繁に発生する場合は、別のワーカー使用率のヒントを設定して自動スケーリング構成を変更し、ジョブをより積極的にアップスケールできるようにする必要があります。
- ワーカーとの通信に問題が発生
Dataflow がすべてのワーカー VM と通信できません。ジョブのワーカー VM のステータスを確認します。考えられる原因としては、次のものあげられます。
- ワーカー VM のプロビジョニングに問題がある。
- ジョブの実行中にワーカー VM プールが削除される。
- ネットワークに問題がある。
- Pub/Sub ソースで pull エラーが発生
Pub/Sub ソースからの pull でエラーが発生しています。必要なトピックとサブスクリプションが存在することを確認し、割り当てと構成を確認します。ログでエラーを確認することもできます。
- Pub/Sub ソースの並列が不十分
Pub/Sub ソースの計算に十分な数の Pub/Sub キーがありません。この警告が表示された場合は、サポートにお問い合わせください。
- Pub/Sub ソースに原因不明のスロットリングが発生している
Pub/Sub からの読み取り中に、Pub/Sub ソースの計算がスロットリングされます（原因不明）。この問題は一時的なものである可能性があります。Pub/Sub の構成の問題、IAM 権限の欠落、割り当て上限を確認します。ただし、これらのいずれも根本原因ではなく、問題が解決しない場合は、サポートにお問い合わせください。
- Pub/Sub シンクのパブリッシュが遅い、または停止している
Pub/Sub シンクの計算が遅い、または停止しています。この問題は、構成の問題または割り当て上限が原因で発生する可能性があります。
- ワークキューの時間が長い
キーの数が多く、それぞれのキーの処理速度が追いつていないため、最も古い有効なワークの時間が長くなっています。この場合、各オペレーションの実行時間の長さは異常ではありませんが、キューイング遅延が全体的に長くなります。
Dataflow は、シャーディング キーごとに 1 つの処理スレッドを使用します。処理スレッドの数は制限されています。キューイング遅延は、キーとスレッドの比率に、キーの各処理バンドルのスレッド内レイテンシを掛けた値とほぼ等しくなります。
(key count / total harness threads) * latency per bundle次の修復方法を試してください。
- ワーカーの数を増やす。ストリーミングの自動スケーリングをご覧ください。
- ワーカー ハーネス スレッドの数を増やす。
numberOfWorkerHarnessThreads/number_of_worker_harness_threadsパイプライン オプションを設定してください。 - キーの数を減らす。
- オペレーションのレイテンシを減らします。
- Streaming Engine バックエンドの一時的な問題
Streaming Engine バックエンドに構成または運用上の問題があります。この問題は一時的なものである可能性があります。問題が解決しない場合は、サポートにお問い合わせください。
- 原因を特定できない
バックログの原因を確実に特定することはできません。この問題は一時的なものである可能性があります。問題が解決しない場合は、サポートにお問い合わせください。