Dataflow のボトルネックのトラブルシューティング

ボトルネックは、あるステップ、ステージ、またはワーカーがジョブ全体の処理速度を低下させている場合に発生します。ボトルネックは、ワーカーのアイドル状態やレイテンシの増加につながる可能性があります。

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 に読み込むの並列処理をご覧ください。

Apache Kafka ソースの永続状態の量が多い

Apache Kafka ソースの計算で大量のデータが再分配されているため、レイテンシと費用が増加する可能性があります。この問題を解決するには、次のことを試してください。

パイプラインで exactly-once 処理が必要な場合は、オフセット重複除去モードを利用して、再分配シャッフルの費用を最小限に抑えます。このモードでは、シャッフルの一部として保持する必要があるデータ量を最小限に抑えつつ、exactly-once 処理を行います。
パイプラインで at-least-once 処理で十分な場合は、重複を許可構成を有効にします。

詳細については、Apache Kafka から Dataflow に読み込むをご覧ください。

ソースの並列処理が不十分

ソースの計算処理の並列処理が不十分です。可能であれば、ソース内の並列処理を増やします。並列処理を増やせない場合で、ジョブで at-least-once モードが使用されている場合は、パイプラインに Redistribute 変換を追加してみてください。

ホットキー、またはキーの並列が不十分

ジョブにホットキーがあるか、キーの並列処理が不十分です。

Dataflow は、シャーディングキーごとにメッセージを順次処理します。Dataflow が特定のキーのメッセージのバッチを処理している間、そのキーの他の受信メッセージは、現在のバッチが完了するまでキューに入れられます。

Dataflow が十分な数の異なるキーを並行して処理できないと、ボトルネックが発生する可能性があります。たとえば、データに個別のキーが少なすぎる場合や、特定のキーがデータ内で過剰に表現されている場合（「ホットキー」）などです。詳細については、処理速度が遅いジョブや停止しているストーミングジョブのトラブルシューティングをご覧ください。

vCPU のプロビジョニングが不十分

ジョブに十分なワーカー vCPU がありません。この状況は、ジョブがすでに最大までスケーリングされ、vCPU 使用率が高く、バックログが残っている場合に発生します。このジョブにプロビジョニングされるワーカーの最大数を増やす必要がある場合があります。たとえば、自動スケーリングの範囲を変更して、この数を増やすことができます。または、パイプラインコードやワークロードを変更して vCPU 使用率を減らす方法を探します。Cloud Profiler を使用して、最適化の機会を探すことができます。

vCPU 使用率が高く、アップスケールが必要

ジョブの vCPU 使用率は高いものの、アップスケールする余地があります。この状態は、アップスケーリングが可能になるまで一時的に発生する可能性があります。自動スケーリングをモニタリングして、自動スケーリングの決定を確認できます。この状態が長時間続く場合や頻繁に発生する場合は、自動スケーリング構成を変更して別のワーカー使用率のヒントを設定し、ジョブをよりプロアクティブにアップスケールできるようにする必要があります。

vCPU がロードバランスされておらず、一部の異常なワーカーでボトルネックが発生している

ジョブには十分なワーカー vCPU がありますが、一部のワーカーの vCPU 使用率が非常に高くなっています。多くの場合、作業が均等に分散されていないことが原因です。原因として、ソースパーティション間の負荷の不均等やホットキーなどが考えられます。

この問題を解決するには、次のことを試してください。

不均等な負荷の原因を特定し、修正を試みます。たとえば、ソースパーティションが均等に分散されていることを確認します。
負荷の不均等を修正できない場合は、ワーカー VM のシェイプを変更してワーカーあたりの vCPU を増やし、ピーク使用率を下げることを検討してください。ワーカーあたりの vCPU の構成の詳細については、Dataflow ワーカー VM を構成するをご覧ください。

ワーカーとの通信に問題が発生

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 バックエンドに構成または運用上の問題があります。この問題は一時的なものである可能性があります。問題が解決しない場合は、サポートにお問い合わせください。

原因を特定できない

バックログの原因を確実に特定できません。この問題は一時的なものである可能性があります。問題が解決しない場合は、サポートにお問い合わせください。

ボトルネックの指標

次のジョブ指標は、ボトルネックに関する情報を提供します。

job/is_bottleneck: 特定の Dataflow パイプラインステージがボトルネックになっているかどうか、ボトルネックの種類、考えられる原因。
job/backlogged_keys: ボトルネックステージのバックログに記録されたキーの数。
job/recommended_parallelism: ボトルネックを減らすためにステージで推奨される並列処理。