一般的なエラーのガイダンス

このページでは、Cloud Dataflow ジョブの実行時に発生する可能性がある一般的なエラーについて説明し、これらのエラーに対処するための一連のアクションを提案します。

ジョブ メッセージ:

ジョブ送信エラー:

ワーカーログ(Stackdriver):

ジョブ メッセージ

「The job failed because a work item failed 4 times」(作業アイテムが 4 回失敗したため、ジョブが失敗しました)

ワーカーコードが 1 回のオペレーションで 4 回失敗すると、コードが例外をスローするかクラッシュしてジョブが失敗し、「a work item failed 4 times」(作業アイテムが 4 回失敗しました)というメッセージが表示されます。

ジョブの Stackdriver ログで、4 つの失敗を調べてください。ワーカーログで、例外またはエラーを示す Error-level または Fatal-level ログエントリを探します。このような例外またはエラーが少なくとも 4 つ表示されるはずです。

ユーザーコード内のエンコーディング エラー、IOException、または予期しない動作

Apache Beam SDK と Cloud Dataflow ワーカーは共通のサードパーティ コンポーネントに依存しています。これらのコンポーネントで追加の依存関係がインポートされます。バージョンが競合すると、サービスで予期しない動作が発生することがあります。次に示すパッケージのいずれかをコードで使用する場合は、一部のライブラリに前方互換性がないことに注意してください。リストに記載されているバージョンに固定し、実行時にその範囲内に収まるようにしなければなりません。 依存関係と必要なバージョンについては、SDK とワーカーの依存関係をご覧ください。

以前は実行できたジョブが、「ステージングされたパッケージ...にアクセスできません」というエラーで失敗する

ステージングされたパッケージが削除される原因となる TTL 設定が、ステージングに使われる Cloud Storage バケットに含まれていないことをご確認ください。

ジョブ送信エラー

「413 Request Entity Too Large」(413 リクエスト エンティティが大きすぎます)/「The size of serialized JSON representation of the pipeline exceeds the allowable limit」(パイプラインのシリアル化 JSON 表現のサイズが上限を超えています)

ジョブの送信時に JSON ペイロードに関するエラーが発生する場合は、パイプラインの JSON 表現が最大リクエスト サイズ 20 MB を超えていることを意味します。こうしたエラーは、コンソールまたはターミナル ウィンドウに次のいずれかのメッセージとして表示されることがあります。

  • 413 Request Entity Too Large
  • 「The size of serialized JSON representation of the pipeline exceeds the allowable limit」(パイプラインのシリアル化された JSON 表現のサイズが上限を超えています)
  • 「Failed to create a workflow job: Invalid JSON payload received」(ワークフロー ジョブの作成に失敗しました: 無効な JSON ペイロードを受信しました)
  • 「Failed to create a workflow job: Request payload exceeds the allowable limit」(ワークフロー ジョブの作成に失敗しました。リクエスト ペイロードが上限を超えています)

ジョブのサイズはパイプラインの JSON 表現に相関しています。パイプラインが大きいほど、リクエストが大きくなります。Cloud Dataflow は現在、リクエストを 20 MB に制限しています。

パイプラインの JSON リクエストのサイズを見積もるには、次のオプションを指定してパイプラインを実行します。

Java: SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Java: SDK 1.x

--dataflowJobFile=< path to output file >

このコマンドは、ジョブの JSON 表現をファイルに書き込みます。シリアル化されたファイルのサイズは、リクエストのサイズにほぼ相当します。リクエストにはいくつかの追加情報が含まれるため、実際のサイズはわずかに大きくなります。

パイプラインの特定の条件により、JSON 表現が制限を超えることがあります。こうした条件のうち一般的なものは次のとおりです。

  • 大量のメモリ内データを含む Create 変換。
  • リモート ワーカーへの送信のためにシリアル化される大きな DoFn インスタンス。
  • シリアル化する大量のデータを(通常は誤って)pull する匿名内部クラス インスタンスとしての DoFn

これらの状況を回避するには、パイプラインを再構築することを検討してください。

「The job graph is too large. Please try again with a smaller job graph, or split your job into two or more smaller jobs」(ジョブグラフが大きすぎます。小さいジョブグラフでもう一度試すか、ジョブを複数の小さいジョブに分割してください)

ジョブグラフのサイズが 10 MB を超えてはいけません。パイプライン内の条件によっては、ジョブグラフが制限を超えることがあります。一般的な条件は次のとおりです。

  • 大量のメモリ内データを含む Create 変換。
  • リモート ワーカーへの送信のためにシリアル化される大きな DoFn インスタンス。
  • シリアル化する大量のデータを(通常は誤って)pull する匿名内部クラス インスタンスとしての DoFn

これらの状況を回避するには、パイプラインを再構築することを検討してください。

「Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit」(splitIntoBundles() オペレーションによって生成された BoundedSource オブジェクトの総数が上限を超えています)または「Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit」(splitIntoBundles() オペレーションによって生成された BoundedSource オブジェクトの合計サイズが上限を超えています)。

Java: SDK 2.x

このエラーは、非常に多くのファイルを TextIOAvroIO、その他のファイルベース ソースから読み取っている場合に発生することがあります。具体的な制限はソースの詳細に依存します(たとえば AvroIO.Read 内の埋め込みスキーマで許容されるファイル数が少ないなど)。ただし、単一のパイプラインでのファイル数は数万単位です。

また、パイプライン用にカスタム データソースを作成した場合、ソースの splitIntoBundles メソッドがシリアル化時に 20 MB を超える BoundedSource オブジェクトのリストを返したときにも、このエラーが発生することがあります。

カスタムソースの splitIntoBundles() オペレーションで生成される BoundedSource オブジェクトの合計サイズの上限は 20 MB です。この制限を回避するには、カスタム BoundedSource サブクラスを変更して、生成される BoundedSource オブジェクトの合計サイズを 20 MB の制限より小さくできます。たとえば、最初にソース側で大まかにデータを分割した後、動的作業再調整機能を使ってオンデマンドで入力をさらに分割できます。

Java: SDK 1.x

このエラーは、非常に多くのファイルを TextIOAvroIO、その他のファイルベース ソースから読み取っている場合に発生することがあります。具体的な制限はソースの詳細に依存します(たとえば AvroIO.Read 内の埋め込みスキーマで許容されるファイル数が少ないなど)。ただし、単一のパイプラインでのファイル数は数万単位です。

また、パイプライン用にカスタム データソースを作成した場合、ソースの splitIntoBundles メソッドがシリアル化時に 20 MB を超える BoundedSource オブジェクトのリストを返したときにも、このエラーが発生することがあります。

カスタムソースの splitIntoBundles() オペレーションで生成される BoundedSource オブジェクトの合計サイズの上限は 20 MB です。この制限を回避するには、カスタム BoundedSource サブクラスを変更して、生成される BoundedSource オブジェクトの合計サイズを 20 MB の制限より小さくできます。たとえば、最初にソース側で大まかにデータを分割した後、動的作業再調整機能を使ってオンデマンドで入力をさらに分割できます。

ワーカーログ(Stackdriver)

「Processing stuck in step <step_id> for at least <time_interval> without outputting or completing in state finish at <stack_trace>」(ステップ <step_id> の処理が停止しています。少なくとも <time_interval> にわたって出力がないか、<stack_trace> の完了状態を伴って終了していません。)

<time_interval> で指定された時間を超えて Cloud Dataflow が DoFn を実行し続けてデータを戻さない場合、このメッセージが表示されます。

このエラーには次の 2 つの原因が考えられます。

  • DoFn コードが低速です。または低速な外部オペレーションの完了を待っています。その場合は、この警告を無視してください。
  • あるいは、DoFn コードが停止したか、デッドロックが発生したか、実行速度が異常に遅いために処理が完了しません。このケースに該当すると思われる場合は、Stackdriver のログエントリを展開し、停止したコードのスタック トレースを確認してください。

(Java または Scala を使用して)Java VM 上でパイプラインが構築されている場合は、停止したコードの原因をさらに詳しく調べることができます。以下の手順に沿って、(停止したスレッドだけでなく)JVM 全体の完全なスレッドダンプを取得してください。

  1. ログエントリに含まれるワーカー名をメモします。
  2. GCP Console の [Compute Engine] セクションで、メモしたワーカー名の Compute Engine インスタンスを見つけます。
  3. その名前のインスタンスに SSH で接続します。
  4. 次のコマンドを実行します。

    curl http://localhost:8081/threadz
    

RPC タイムアウト例外、「DEADLINE_EXCEEDED」例外、または「Server Unresponsive」(サーバー応答なし)エラー

ジョブの実行中に RPC タイムアウト、DEADLINE_EXCEEDED 例外、Server Unresponsive エラーが発生した場合、通常は次の 2 つの問題のいずれかを示しています。

  • ジョブで使用される VPC ネットワークにファイアウォール ルールが欠落している可能性があります。ファイアウォール ルールでは、パイプライン オプションで指定した VPC ネットワーク内の VM 間のすべての TCP トラフィックを有効にする必要があります。詳しくは、ネットワークとサブネットワークの指定をご覧ください。

  • ジョブがシャッフルバインドされています。次のアクションのいずれか一つに従うか、複数を組み合わせることを検討してください。

    Java: SDK 2.x

    • 他のワーカーを追加します。パイプラインの実行時に、より大きな値の --numWorkers を設定してみます。
    • ワーカーに接続されたディスクのサイズを増やします。 パイプラインの実行時に、より大きな値の --diskSizeGb を設定してみます。
    • SSD を使用する永続ディスクを使用します。パイプラインの実行時に、--workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" を設定してみます。

    Python

    • 他のワーカーを追加します。パイプラインの実行時に、より大きな値の --num_workers を設定してみます。
    • ワーカーに接続されたディスクのサイズを増やします。 パイプラインの実行時に、より大きな値の --disk_size_gb を設定してみます。
    • SSD を使用する永続ディスクを使用します。パイプラインの実行時に、--worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" を設定してみます。

    Java: SDK 1.x

    • 他のワーカーを追加します。パイプラインの実行時に、より大きな値の --numWorkers を設定してみます。
    • ワーカーに接続されたディスクのサイズを増やします。 パイプラインの実行時に、より大きな値の --diskSizeGb を設定してみます。
    • SSD を使用する永続ディスクを使用します。パイプラインの実行時に、--workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" を設定してみます。

Java ワーカー ハーネスから Python DoFn への呼び出しがエラー <error message> で失敗しました

Python で実装された DoFn が失敗して例外をスローすると、関連するエラー メッセージが表示されます。

Stackdriver のエラー ログエントリを展開し、エラー メッセージとトレースバックを確認してください。どのコードが失敗したかがわかるので、必要に応じてコードを修正できます。Apache Beam または Cloud Dataflow のバグであると思われる場合は、バグを報告してください。

デバイスに空き領域がありません

ジョブで大量のデータがシャッフルされたり、ローカル ディスクに一時データが書き込まれたりすると、ワーカーの永続ストレージの空き容量が不足する可能性があります。

デバイスに空き容量がないことを通知するメッセージが表示された場合は、関連するパイプライン オプションを設定して、ワーカーの永続ディスクのサイズを増やしてください。Java ジョブの場合は、--diskSizeGb フラグを使用します。Python ジョブの場合は、--disk_size_gb を使用します。

「RESOURCE_EXHAUSTED: IO error: No space left on disk」(RESOURCE_EXHAUSTED: IO エラー: ディスクに空き容量がありません)などのディスク容量エラー

通常、これらのエラーは、割り当てられたローカル ディスク容量がジョブを処理するのに不十分であることを示します。デフォルト設定でジョブを実行している場合、ジョブは 3 つのワーカーで実行され、それぞれ 25 GB のローカル ディスク容量を持ち、自動スケーリングはありません。デフォルト設定を変更して、ジョブに使用可能なワーカー数を増やすか、ワーカーあたりのデフォルト ディスクサイズを増やすか、自動スケーリングを有効にすることを検討してください。

shuffler ログに「Bad request」(不正なリクエスト)という警告が表示される

Cloud Dataflow ジョブの実行中に、Stackdriver ログに次のような一連の警告が表示されることがあります。

Unable to update setup work item <step_id> error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id <lease_id>
with expiration time: <timestamp>, now: <timestamp>. Full status: generic::invalid_argument: Http(400) Bad Request

処理遅延のためにワーカーの状態情報が古くなっているか非同期状態になったことが原因で、「不正なリクエスト」という警告が表示されます。こうした「不正なリクエスト」警告が表示されても、多くの場合、Cloud Dataflow のジョブは成功します。その場合は、警告を無視してください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。