Dataflow の自動スケーリングのトラブルシューティング

このページでは、Dataflow 自動スケーリング機能の問題を解決する方法と、自動スケーリングの管理方法について説明します。

ジョブがスケールアップまたはスケールダウンされない

このセクションでは、ワーカーがスケールアップまたはスケールダウンできない場合のシナリオについて説明します。

ストリーミング ジョブがスケールアップされない

ストリーミング パイプラインにバックログがある場合、ワーカーはスケールアップされません。

この問題は、バックログが数分未満で継続するか、ワーカーの CPU 使用率が 20% 未満の場合に発生します。

バックログが増加していても CPU 使用率は低いことがあります。一部のタスクでは高い CPU 使用率を必要としないため、ワーカーを追加してもパフォーマンスは向上しません。このようなケースでは、Dataflow はスケールアップされません。詳細については、ストリーミングの自動スケーリングをご覧ください。このシナリオは、次の理由で発生する可能性があります。

  • パイプラインの I/O の負荷が高い。
  • パイプラインが外部 RPC 呼び出しを待機している。
  • ホットキーが、ワーカーの CPU 使用率を不均一にしている。
  • パイプラインに十分なキーがない。

バッチジョブとストリーミング ジョブがスケールアップされない

バッチジョブまたはストリーミング ジョブが想定どおりに実行される場合でも、多くのワーカーが必要な場合、ジョブはスケールアップされません。

この問題は、以下のいずれかの理由で発生する可能性があります。

  • ステージングまたは一時ファイルにアクセスできない状態です。ジョブで Cloud Storage バケットを使用している場合、バケットにバケット内のオブジェクトを削除するライフサイクル構成が含まれている場合があります。削除されるオブジェクトには、ステージング フォルダ、一時フォルダ、ファイルがあります。ファイルが削除されたかどうかを確認するには、バケットのライフサイクル構成を確認します。ジョブの開始後にステージング、一時フォルダ、ファイルが削除された場合、新しいワーカーの作成に必要なパッケージが存在しない可能性があります。この問題を解決するには、バケット内でフォルダとファイルを再作成します。
  • ファイアウォール ルールにより、ワーカーが必要な TCP ポートでトラフィックを送受信することができません。ファイアウォール ルールにより、ワーカーが起動できない場合があります。Dataflow ワーカーは、TCP ポート 12345 と 12346 でトラフィックを送受信できる必要があります。この問題を解決する手順など、詳細については、Dataflow のファイアウォール ルールをご覧ください。
  • カスタムソースには、NULL 値を返す getProgress() メソッドがあります。カスタムソースを使用する場合、バックログ指標は、カスタムソースの getProgress() メソッドの戻り値に基づいてデータの収集を開始します。getProgress() のデフォルトの実装では NULL 値を返します。この問題を解決するには、カスタムソースがデフォルトの getProgress() メソッドをオーバーライドして、NULL 以外の値を返すようにしてください。
  • 垂直自動スケーリングによって更新がトリガーされると、一時的に水平自動スケーリングが無効になります。詳細については、水平自動スケーリングへの影響をご覧ください。
  • Python パイプラインで map オペレーションを使用していて、ジョブがスケールアップされない場合は、パイプライン コードに Reshuffle 変換の追加が必要になることがあります。詳細については、Apache Beam ドキュメントの再シャッフルをご覧ください。

ストリーミング ジョブがスケールダウンされない

ストリーミング ジョブのバックログと CPU 使用率が低い場合、ワーカーはスケールダウンされません。この問題は、さまざまな理由で発生する可能性があります。

  • ジョブが Streaming Engine を使用していない場合、Dataflow はワーカー間で永続ディスクの数を調整します。そのため、各ワーカーには等しい数の永続ディスクが必要です。たとえば、100 個のディスクと 100 個のワーカーがある場合、各ワーカーでは 1 個のディスクを持ちます。ジョブがスケールダウンされると、ジョブではワーカーあたり 2 個の永続ディスクを持つ 50 個のワーカーを使用できます。ジョブがワーカーあたり 4 個の永続ディスクを持つ 25 個のワーカーが使用可能になるまで、そのジョブは再度スケールダウンされません。また、ワーカーの最小数は、maxNumWorkers の値を 15 で割った値になります。詳細については、ストリーミング自動スケーリング パイプラインのスケーリング範囲をご覧ください。

  • ジョブが Streaming Engine を使用する場合、ダウンスケーリングの目標は、75% の CPU 使用率の目標値に基づきます。この CPU 使用率を達成できない場合、ダウンスケーリングは無効になります。

  • バックログの推定時間は、ワーカーがスケールダウンされる前の最低 2 分間、10 秒を超えないようにする必要があります。バックログ時間の変動により、スケールダウンが無効になる可能性があります。さらにスループットが低いと推定時間に、ずれが発生する可能性があります。

  • PeriodicImpulse は、Apache Beam SDK バージョン 2.60.0 以降でサポートされています。パイプラインで Apache Beam SDK バージョン 2.59.0 以前で PeriodicImpulse を使用している場合、Dataflow ワーカーは想定どおりにスケールダウンしません。

スケールアップの停止

バッチジョブまたはストリーミング ジョブがスケールアップを開始する際、バックログが残っている場合でもワーカーはスケールアップを停止します。

この問題は、割り当ての上限に達した場合に発生します。

  • Compute Engine の割り当て: Dataflow ジョブには、プロジェクトの Compute Engine の割り当てが適用されます。複数のジョブが実行されている場合、プロジェクトが Compute Engine の割り当ての上限に達する可能性があります。この場合、Dataflow はワーカー数を増やすことができません。
  • CPU 割り当て: Dataflow ジョブもプロジェクトの CPU 割り当ての対象になります。ワーカータイプが複数の CPU を使用している場合、プロジェクトが CPU 割り当ての上限に達する可能性があります。
  • 外部 IP アドレスの割り当て: ジョブで外部 IP アドレスを使用してリソースと通信する場合、ワーカーと同じ数の外部 IP アドレスが必要です。ワーカーの数がスケールアップすると、外部 IP アドレスの数も増加します。IP アドレスの上限に達すると、ワーカーはスケールアップを停止します。

また、選択したリージョンでリソースが不足している場合、リージョンまたはプロジェクトで割り当てが残っていても、その種類のリソースを新たに作成することはできません。たとえば、us-central1 に外部 IP アドレスを作成できるだけの割り当てが残っていても、そのリージョンには利用可能な IP アドレスがないという場合もあります。詳細については、割り当てとリソースの可用性をご覧ください。

この問題を解決するには、割り当ての増加をリクエストするか、別のリージョンでジョブを実行します。

ワーカー使用率のヒントに効果がない

ワーカー使用率のヒントを設定しても、自動スケーリングの動作が変わりません。

この問題を理解するには、ワーカーの CPU 使用率グラフに移動し、ワーカー使用率のヒントがアクティブに使用されているかどうかを確認します。ヒントが使用されている場合、グラフに CPU utilization hint (actively used by autoscaler) が表示されます。それ以外の場合は、CPU utilization hint (not actively used by autoscaler) が表示されます。

使用率のヒントは、自動スケーリングに影響する要因の一つにすぎません。次の表に、オートスケーラーがヒントをアクティブに使用しない理由を示します。

観察されたスケーリングの動作 原因 確認する指標
変化なし
  • ワーカー数が最小または上限に達しました。
  • ワーカーの数は、並列処理される鍵の数によって制限されます。
  • ジョブは外部 RPC によってスロットリングされます。
  • ダウンスケーリングの調整が小さすぎるか、Dataflow がダウンスケーリングを減衰させています。詳細については、ストリーミングの自動スケーリングのヒューリスティックをご覧ください。
スケールアップ
  • バックログまたはレイテンシの目標値が高いため、ヒントがオーバーライドされています。
  • ワーカーの最小数が現在のワーカー数よりも高い値に更新されました。
スケールダウン
  • ワーカーの最大数が現在のワーカー数よりも小さい値に更新されました。

詳細については、ストリーミング自動スケーリングのヒューリスティックをご覧ください。

自動スケーリング指標のギャップ

自動スケーリングの指標に短時間の一時的なギャップがあります。

この問題は、バックエンド タスクが再起動された場合に発生することがあります。このようなギャップは、自動スケーリングの問題やストリーミング ジョブの正常性の問題を示しているわけではありません。

CPU が均等に分散されていない

ジョブが自動スケーリングされているときに、CPU 使用率がワーカー間で均等に分配されません。ワーカーによっては、CPU 使用率、システム レイテンシ、データの更新頻度が高いものもあります。

この問題は、データにホットキーが含まれている場合に発生します。ホットキーは、パイプラインのパフォーマンスに悪影響を与える数の要素が含まれるキーです。各キーは 1 つのワーカーで処理する必要があるため、作業をワーカー間で分割することはできません。

詳細については、ホットキー エラーのガイダンスをご覧ください。

状態読み取りをリクエストした作業項目がバックエンドで無効になっている

ワーカー VM インスタンスとストリーミング パイプラインでの Streaming Engine タスク間の通信中に、次のエラーが発生します。

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

自動スケーリング中、ワーカー VM インスタンスは複数の Streaming Engine タスクと通信し、各タスクは複数のワーカー VM インスタンスを提供します。 作業を分散させるために、アイテムのキーを使用します。各タスクとワーカー VM インスタンスにはキー範囲のコレクションがあり、これらの範囲の分布は動的に変更される可能性があります。たとえば、自動スケーリング中にジョブのサイズを変更すると、キー範囲の分布が変更される可能性があります。キー範囲が変更されると、このエラーが発生する可能性があります。これは予想されるエラーであり、これらのメッセージとパフォーマンスが低下したパイプラインに相関関係がない限り、無視してかまいません。

Streaming Engine リソースが不足している

Streaming Engine で、リクエストされるワーカーの最小数を割り当てることができない場合は、次のエラーが返されます。

Streaming Engine does not currently have enough resources available to fulfill
the request.

この問題を解決するには、ワーカーの最小数を減らしてみてください。自動スケーリングの範囲を設定するをご覧ください。

ストリーミング自動スケーリング パイプラインのスケーリング範囲

このセクションでは、ストリーミング自動スケーリング パイプラインのスケーリング範囲について詳しく説明します。

Java

ストリーミング エンジンを使用しないストリーミング自動スケーリング ジョブの場合、Dataflow サービスは各ワーカーに 1～15 個の Persistent Disk を割り当てます。この割り当てでは、ストリーミング自動スケーリング パイプラインに使用されるワーカーの最小数は N/15 になります（N は --maxNumWorkers の値です）。

ストリーミング エンジンを使用するストリーミング自動スケーリング ジョブの場合、ワーカーの最小数は 1 です。

Dataflow は、ワーカー間で永続ディスクの数を調整します。たとえば、パイプラインで安定状態のワーカーが 3 つまたは 4 つ必要な場合は、--maxNumWorkers=15 を設定できます。パイプラインは、1～15 のワーカーの間で自動的にスケーリングします（使用するワーカー数は 1、2、3、4、5、8、15 のいずれか）。ワーカーあたりの永続ディスクの数はそれぞれ 15、8、5、4、3、2、1 のいずれかになります。

--maxNumWorkers は 1,000 以下にしてください。

Python

ストリーミング エンジンを使用しないストリーミング自動スケーリング ジョブの場合、Dataflow サービスは各ワーカーに 1～15 個の Persistent Disk を割り当てます。この割り当てでは、ストリーミング自動スケーリング パイプラインに使用されるワーカーの最小数は N/15 になります（N は --max_num_workers の値です）。

ストリーミング エンジンを使用するストリーミング自動スケーリング ジョブの場合、ワーカーの最小数は 1 です。

Dataflow は、ワーカー間で永続ディスクの数を調整します。たとえば、パイプラインで安定状態のワーカーが 3 つまたは 4 つ必要な場合は、--max_num_workers=15 を設定できます。パイプラインは、1～15 のワーカーの間で自動的にスケーリングします（使用するワーカー数は 1、2、3、4、5、8、15 のいずれか）。ワーカーあたりの永続ディスクの数はそれぞれ 15、8、5、4、3、2、1 のいずれかになります。

--max_num_workers は 1,000 以下にしてください。

Go

ストリーミング エンジンを使用しないストリーミング自動スケーリング ジョブの場合、Dataflow サービスは各ワーカーに 1～15 個の Persistent Disk を割り当てます。この割り当てでは、ストリーミング自動スケーリング パイプラインに使用されるワーカーの最小数は N/15 になります（N は --max_num_workers の値です）。

ストリーミング エンジンを使用するストリーミング自動スケーリング ジョブの場合、ワーカーの最小数は 1 です。

Dataflow は、ワーカー間で永続ディスクの数を調整します。たとえば、パイプラインで安定状態のワーカーが 3 つまたは 4 つ必要な場合は、--max_num_workers=15 を設定できます。パイプラインは、1～15 のワーカーの間で自動的にスケーリングします（使用するワーカー数は 1、2、3、4、5、8、15 のいずれか）。ワーカーあたりの永続ディスクの数はそれぞれ 15、8、5、4、3、2、1 のいずれかになります。

--max_num_workers は 1,000 以下にしてください。

自動スケーリングをストリーミングするワーカーの最大数

Java

Dataflow は、プロジェクトの Compute Engine インスタンス数の割り当てまたは maxNumWorkers（いずれか少ないほう）の制限内で動作します。

Python

Dataflow は、プロジェクトの Compute Engine インスタンス数の割り当てまたは max_num_workers（いずれか少ないほう）の制限内で動作します。

Go

Dataflow は、プロジェクトの Compute Engine インスタンス数の割り当てまたは max_num_workers（いずれか少ないほう）の制限内で動作します。

自動スケーリングを制限して請求額への影響を軽減する

自動スケーリングによる請求額の増加が望ましくない場合は、ストリーミング ジョブが使用できるワーカーの最大数を制限できます。

Java

--maxNumWorkers を指定して、ジョブの処理に使用するスケーリング範囲を制限します。

Python

--max_num_workers を指定して、ジョブの処理に使用するスケーリング範囲を制限します。

Go

--max_num_workers を指定して、ジョブの処理に使用するスケーリング範囲を制限します。

スケーリング範囲を変更する

ストリーミング パイプラインのスケーリング範囲を変更する方法については、自動スケーリングの範囲を設定するをご覧ください。

ストリーミング パイプラインの自動スケーリングをオフにする

ストリーミング パイプラインで自動スケーリングをオフにするには、次の手順を行います。

Java

--autoscalingAlgorithm=NONE を設定します。詳細については、水平自動スケーリングを無効にするをご覧ください。

Python

--autoscaling_algorithm=NONE を設定します。詳細については、水平自動スケーリングを無効にするをご覧ください。

Go

--autoscaling_algorithm=NONE を設定します。詳細については、水平自動スケーリングを無効にするをご覧ください。

固定数のワーカーを使用する

Streaming Engine を使用しないストリーミング ジョブの場合、デフォルトの動作では固定数のワーカーが使用されます。これらのパイプラインでは、ストリーミング自動スケーリングがデフォルトで有効になっていないため、明示的に有効にする必要があります。