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

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

リソースのストックアウト エラー:

ジョブ メッセージ:

ジョブ送信エラー:

ワーカーログ:

入出力のエラー:

ワーカーの起動エラー:

ログ:

推奨:

リソースのストックアウト エラー

リソースプールの不足が原因で発生したエラーの解決

Google Cloud リソースの作成時に、リソースプールの不足が原因でエラーが発生することがあります。このエラーは、特定のゾーン内の特定のリソースの一時的なストックアウト状態を示します。メッセージの形式は次のとおりです。

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

この問題を解決するには、一定時間待つか、別のゾーンに同じリソースを作成します。サービスの停止を避けるため、複数のゾーンとリージョンにリソースを分散することをおすすめします。

ジョブ メッセージ

The job failed because a work item failed 4 times.

ワーカーコードが 1 回のオペレーションで 4 回失敗すると、コードが例外をスローするかクラッシュしてジョブが失敗し、「a work item failed 4 times」というメッセージが表示されます。この失敗しきい値は構成できません。詳しくは、パイプラインのエラーと例外の処理をご覧ください。

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

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

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

以前は実行できたジョブが Staged package...is inaccessible というエラーで失敗する

  • ステージングされたパッケージが削除される原因となる TTL 設定が、ステージングに使われる Cloud Storage バケットに含まれていないことをご確認ください。
  • Dataflow プロジェクトのコントローラ サービス アカウントに、ステージングに使用される Cloud Storage バケットにアクセスする権限があることを確認します。権限のギャップの原因として、次のいずれかが考えられます。

    • ステージングに使用される Cloud Storage バケットが別のプロジェクトに存在する。
    • ステージングに使用される Cloud Storage バケットが、きめ細かいアクセスから均一なバケットレベルのアクセスに移行された。IAM ポリシーと ACL ポリシーの間に不整合があるため、ステージング バケットを均一なバケットレベルのアクセスに移行すると、Cloud Storage リソースの ACL が許可されなくなります。これには、ステージング バケットに対して Dataflow プロジェクトのコントローラ サービス アカウントが保持する権限が含まれます。

詳しくは、Google Cloud プロジェクト間での Cloud Storage バケットへのアクセスをご覧ください。

Flex テンプレート ポーリング タイムアウト

Flex テンプレート ジョブから次のエラー メッセージが返される場合があります。

Timeout in polling result file: ${file_path}.
Service account: ${service_account_email}
Image URL: ${image_url}
Troubleshooting guide at https://cloud.google.com/dataflow/docs/guides/common-errors#timeout-polling

これは、次のいずれかの理由によるためです。

  1. ベース Docker イメージがオーバーライドされた。
  2. ${service_account_email} を入力するサービス アカウントに必要な権限が付与されていない。
  3. グラフを作成するプログラムの完了に時間がかかっている。
  4. (Python のみ)requirements.txt ファイルに問題がある。
  5. 一時的なエラーが発生した。

一時的な障害が発生した場合、ジョブのログを確認して再試行する以外にも、次のようなトラブルシューティング手順があります。

Docker エントリ ポイントを確認する

この手順は、提供されたテンプレートを使用せずに、カスタム Docker イメージからテンプレートを実行する場合を対象としています。

次のコマンドを使用して、コンテナ エントリポイントを確認します。

docker inspect $TEMPLATE_IMAGE

次の結果が表示されます。

Java

/opt/google/dataflow/java_template_launcher

Python

/opt/google/dataflow/python_template_launcher

出力が異なる場合は、Docker コンテナのエントリポイントがオーバーライドされています。$TEMPLATE_IMAGE をデフォルトに戻します。

サービス アカウントの権限を確認する

メッセージにあるサービス アカウントに次の権限があることを確認します。

  • メッセージの ${file_path} にある Cloud Storage パスの読み取りと書き込み
  • メッセージの ${image_url} にある Docker イメージの読み取り

ランチャー プログラムを終了できないかどうかを確認する

パイプラインを構築するプログラムは、パイプラインの起動前に終了する必要があります。ポーリング エラーは、時間がかかりすぎたことを示している可能性があります。

コード内で原因を特定するには、次のような方法があります。

  • ジョブのログを調べ、完了までに時間がかかっているオペレーションがあるかどうかを確認します。たとえば、外部リソースのリクエストなどです。
  • プログラムの終了をブロックしているスレッドがないことを確認します。一部のクライアントが独自のスレッドを作成している場合があります。このようなクライアントがシャットダウンされない場合、プログラムはこれらのスレッドが参加するまで待機します。

テンプレートを使用せずに直接起動したパイプラインにはこのような制限がありません。パイプラインが直接機能しても、テンプレートとして機能していない場合、これが根本原因である可能性があります。

(Python のみ)要件ファイルから Apache Beam を削除する

Dockerfile に apache-beam[gcp] が指定された requirements.txt が含まれている場合は、ファイルから削除して個別にインストールする必要があります。例:

RUN pip install apache-beam[gcp]
RUN pip install -U -r ./requirements.txt

要件ファイルに Beam を含めると、起動時間が長くなり、タイムアウトが発生することがよくあります。

Python での Flex テンプレート ジョブがキュー格納され、タイムアウトする

Flex テンプレートと Python を使用して Dataflow ジョブを実行する場合、ジョブが一定期間キューに入り、その後、実行が失敗することがあります。「Timeout in polling」というエラー メッセージが表示されます。

このエラーは、必要な依存関係のインストールに使用される requirements.txt ファイルが原因で発生しています。Dataflow ジョブを実行すると、すべての依存関係がステージングされ、これらのファイルがワーカー VM からアクセス可能になります。このプロセスでは、requirements.txt ファイル内の直接的な依存関係と間接的な依存関係をダウンロードして再コンパイルします。一部の依存関係はコンパイルに数分かかることがあります。たとえば、PyArrow は Apache Beam とほとんどの Google Cloud クライアント ライブラリで使用されている間接的な依存関係のため、時間がかかります。

この問題を回避するには、次の手順を行います。

  1. Dockerfile でプリコンパイルされた依存関係を Dataflow ステージング ディレクトリにダウンロードします。

  2. 環境変数 PIP_NO_DEPSTrue に設定します。

    この設定により、pip はすべての依存関係の再ダウンロードと再コンパイルができなくなり、タイムアウト エラーを防ぐことができます。

以下は、依存関係を事前にダウンロードする方法を示すコードサンプルです。

# Copyright 2020 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

FROM gcr.io/dataflow-templates-base/python3-template-launcher-base

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/streaming_beam.py"

COPY . /template

# We could get rid of installing libffi-dev and git, or we could leave them.
RUN apt-get update \
    && apt-get install -y libffi-dev git \
    && rm -rf /var/lib/apt/lists/* \
    # Upgrade pip and install the requirements.
    && pip install --no-cache-dir --upgrade pip \
    && pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE \
    # Download the requirements to speed up launching the Dataflow job.
    && pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

# Since we already downloaded all the dependencies, there's no need to rebuild everything.
ENV PIP_NO_DEPS=True

ジョブ送信エラー

413 Request Entity Too Large / The size of serialized JSON representation of the pipeline exceeds the allowable limit

ジョブの送信時に 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 表現に関連付けられていますパイプラインが大きいほど、リクエストが大きくなります。Dataflow は現在、リクエストを 20 MB に制限しています。

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

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< 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 または Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

Java

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

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

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

「SDK pipeline options or staging file list exceeds size limit. Please keep their length under 256K Bytes each and 512K Bytes in total.」

Google Compute Engine メタデータの上限を超えたため、パイプラインを開始できませんでした。この上限を変更することはできません。Dataflow は、Compute Engine メタデータをパイプライン オプションに使用します。上限については、Compute Engine のカスタム メタデータの制限事項をご覧ください。

ステージングする jar ファイルが多すぎると、JSON 表現が制限を超えることがあります。

完全なパイプライン オプションとその長さを見つけるには、どうしたら良いでしょうか。パイプラインの JSON リクエストのサイズを見積もるには、次のオプションを指定してパイプラインを実行します。

Java

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

この出力ファイルのサイズは 256 KB 未満である必要があります。エラー メッセージにある 512 KB は、上記の出力ファイルと Compute Engine VM インスタンスのカスタム メタデータ オプションの合計サイズを指しています。VM インスタンスのカスタム メタデータ オプションの大まかな推定値は、プロジェクトで実行中のデータフロー ジョブから判断できます。実行中のデータフロー ジョブを選択して VM インスタンスを選択します。その VM の Compute Engine VM インスタンスの詳細ページに移動して、カスタム メタデータ セクションを確認します。カスタム メタデータと上記のファイルの合計長は 512 KB 未満にしてください。このジョブの VM は起動されていないため、失敗したジョブの正確な推定は行えません。

jar のリストが 256 KB の上限に達した場合は、リストを確認して不要な jar を削減してください。それでも大きすぎる場合は、uber jar を使用して Dataflow ジョブを実行してみてください。

ドキュメントの Cloud Functions のセクションには、uber jar を作成して使用する方法のサンプルがあります。

Startup of the worker pool in zone $ZONE failed to bring up any of the desired $N workers. The project quota may have been exceeded or access control policies may be preventing the operation; review the Cloud Logging 'VM Instance' log for diagnostics.

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

  • Dataflow ワーカーの作成で必要となる Compute Engine の割り当てのいずれかを超えている可能性があります。
  • VM インスタンスの作成プロセスの一部を禁止する制約が組織で設定されています(使用するアカウントや作成先のゾーンなど)。

この問題を解決するには、次を行います。

VM インスタンスのログを確認する

  1. Cloud Logging ビューアに移動します。
  2. [監査対象リソース] プルダウン リストで、[VM インスタンス] を選択します。
  3. [すべてのログ] プルダウン リストで、[compute.googleapis.com/activity_log] を選択します。
  4. ログをスキャンして、VM インスタンス作成エラーに関連するエントリがないか確認します。

Compute Engine の割り当ての使用状況を確認する

  1. ローカルマシンのコマンドラインまたは Cloud Shell で次のコマンドを実行して、対象のゾーンの Compute Engine リソースの使用量と Dataflow の割り当てを表示して比較します。

    gcloud compute regions describe [REGION]

  2. 次のリソースの結果を確認して、割り当てを超過しているリソースがないか調べます。

    • CPUS
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • INSTANCE_GROUP_MANAGERS
    • INSTANCES
  3. 必要に応じて、割り当ての変更をリクエストします。

組織のポリシーによる制約を確認する

  1. [組織のポリシー] ページに移動します。
  2. 使用しているアカウント(デフォルトでは Dataflow サービス アカウント)または対象のゾーンのいずれかに対して、VM インスタンスの作成を制限する制約がないか確認します。

ワーカーログ

「Processing stuck/Operation ongoing in step <step_id> for at least <time_interval> without outputting or completing in state finish at <stack_trace>」

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

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

  • DoFn コードが低速です。または低速な外部オペレーションの完了を待っています。
  • あるいは、DoFn コードが停止したか、デッドロックが発生したか、実行速度が異常に遅いために処理が完了しません。

どのケースに該当するかを判断するには、Cloud Monitoring ログエントリを展開してスタック トレースを確認します。DoFn コードが停止している、または問題が発生していることを示すメッセージがないか確認します。ない場合は、DoFn コードの実行速度に問題がある可能性があります。Cloud Profiler やその他のツールを使用してコードのパフォーマンスを調査することを検討してください。

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

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

    curl http://localhost:8081/threadz
    

シャッフルキーが大きすぎる例外

シャッフルキーが大きすぎることを示す例外が発生した場合は、対応するコーダーが適用された後に特定の (Co-)GroupByKey に発行されたシリアル化されたキーが大きすぎることを意味します。Dataflow では、シリアル化されたシャッフルキーに対する制限があります。キーのサイズを小さくするか、スペース効率の良いコーダーを使用することを検討してください。

KeyCommitTooLargeException

ストリーミング シナリオでは、Combine 変換を使用せずに、大量のデータをグループ化する場合や、1 つの入力要素から大量のデータを生成する場合に、この問題が発生することがあります。次の戦略により、この例外が発生する可能性を減らすことができます。

  • 単一の要素を処理しても、出力または状態の変更が制限を超えないようにします。
  • 複数の要素がキーでグループ化されている場合は、キースペースを大きくして、キーごとにグループ化される要素を削減することを検討します。
  • キーの要素が短期間に高頻度で発行されると、ウィンドウでそのキーのイベントが GB 単位で発生する可能性があります。このようなキーを検出するようにパイプラインを書き直し、キーがそのウィンドウに頻繁に存在することを示す出力のみを生成します。
  • 交換演算と連想演算には、必ず劣線形空間 Combine 変換を使用してください。スペースを減らせない場合は、コンバイナを使用しないでください。たとえば、文字列を結合するだけの文字列のコンバイナは、コンバイナを使用しない場合よりも悪くなります。

RPC タイムアウト例外、DEADLINE_EXCEEDED 例外、または Server Unresponsive エラー

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

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

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

    Java

    • ジョブがサービスベースのシャッフルを使用していない場合は、--experiments=shuffle_mode=service を設定して、サービスベースの Dataflow Shuffle を使用するように切り替えます。詳細と可用性については、Dataflow Shuffle をご覧ください。
    • 他のワーカーを追加します。パイプラインの実行時に、より大きな値の --numWorkers を設定してみます。
    • ワーカーに接続されたディスクのサイズを増やします。パイプラインの実行時に、より大きな値の --diskSizeGb を設定してみます。
    • SSD を使用する永続ディスクを使用します。パイプラインの実行時に、--workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" を設定してみます。

    Python

    • ジョブがサービスベースのシャッフルを使用していない場合は、--experiments=shuffle_mode=service を設定して、サービスベースの Dataflow Shuffle を使用するように切り替えます。詳細と可用性については、Dataflow Shuffle をご覧ください。
    • 他のワーカーを追加します。パイプラインの実行時に、より大きな値の --num_workers を設定してみます。
    • ワーカーに接続されたディスクのサイズを増やします。パイプラインの実行時に、より大きな値の --disk_size_gb を設定してみます。
    • SSD を使用する永続ディスクを使用します。パイプラインの実行時に、--worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" を設定してみます。

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

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

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

デバイスに空き領域がない

ジョブのディスク容量が不足すると、ワーカーログに No space left on device エラーが表示されることがあります。

ジョブが実行時に大規模な依存関係をダウンロードする、大規模なカスタム コンテナを使用する、多くの一時データをローカル ディスクに書き込む、などの処理が行われると、ワーカーの永続ストレージの空き容量が不足する可能性があります。

Dataflow Shuffle を使用する場合、Dataflow によりデフォルトのディスクサイズが小さく設定されます。このため、ワーカーベースのシャッフルから移行するジョブでも、このエラーが表示されることがあります。

また、1 秒あたり 50 エントリを超えるログが記録されている場合、ワーカーのブートディスクが満杯になる可能性もあります。

単一のワーカーに関連付けられたディスク リソースを確認するには、ジョブに関連付けられているワーカー VM の VM インスタンスの詳細を調べます。ディスク容量の一部は、オペレーティング システム、バイナリ、ログ、コンテナによって消費されます。

永続ディスクまたはブートディスクの容量を増やすには、ディスクサイズ パイプライン オプションを調整します。

Cloud Monitoring を使用して、ワーカー VM インスタンスのディスク使用量を追跡できます。これを設定する手順については、Monitoring エージェントからワーカー VM の指標を受信するをご覧ください。

また、ワーカー VM インスタンスでシリアルポート出力を表示し、「Failed to open system journal: No space left on device」のようなメッセージを探して、ブートディスクの容量の問題がないか確認することもできます。ワーカー VM インスタンスが多数ある場合は、一度にすべてのインスタンスで gcloud compute instances get-serial-port-output を実行するスクリプトを作成して、その出力を確認することをおすすめします。

詳細については、永続ディスクのリソースをご覧ください。

EOFError: マーシャル データが短すぎる

このエラーは、Python パイプライン ワーカーでディスク容量が不足したときに発生することがあります。デバイスに空き容量がないをご覧ください。

shuffler ログに Bad request という警告が表示される

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

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

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

ホットキー <hot-key-name> が検出された

このエラーは、データにホットキーがあることを示しています。ホットキーは、パイプラインのパフォーマンスに悪影響を与える数の要素が含まれるキーです。これらのキーが存在すると、Dataflow が要素を並列に処理するため、実行時間が長くなります。

ホットキーの存在をログに記録するには、ホットキー パイプライン オプションを使用します。

データが均等に配信されていることを確認します。キーの値が多すぎる場合は、次の一連のアクションを検討してください。

SystemError: 不明なオペコードで Python カスタム コンテナ パイプラインが失敗した

ジョブの送信直後に予期しない Python エラー SystemError: unknown opcode が発生し、スタック トレースに apache_beam/internal/pickler.py が含まれている場合は、メジャー バージョンからマイナー バージョンに至るまで、ローカルで使用している Python のバージョンがコンテナ イメージのバージョンと一致していることを確認してください。3.6.7 と 3.6.8 などのパッチ バージョンの違いは互換性の問題を引き起こしませんが、3.6.8 と 3.8.2 などのマイナー バージョンの違いはパイプラインのエラーを引き起こす可能性があります。

入出力エラー

I/O 指標チャートでは、正規のエラーコードを使用します。ソースまたはシンクでこれらのエラーコードが発生し続ける場合は、次のリストを参照して可能性のある原因と対処方法を確認してください。

  • RESOURCE_EXHAUSTED。プロジェクトで、ソースまたはシンクが使用しているサービスのリソース割り当てが使い果たされた可能性があります。

    ときどきエラーが発生する場合や、秒あたりのリクエスト数のチャートで多数のリクエストが生成されている場合、API レート制限の上限に達した場合があり、その場合は割り当てを増やす必要があります。

  • DEADLINE_EXCEEDED ソースまたはシンクが大量のデータの読み取りまたは書き込みをタイムアウトした可能性があります。レイテンシ チャートとワーカーログを確認します。エラーが解消されない場合は、サポートまでお問い合わせください

  • INVALID_ARGUMENT。ソースまたはシンクに指定されたパラメータの形式が正しくない可能性があります(Pub/Sub トピックなど)。ソースまたはシンクの構成を確認し、ワーカーログを調べます。

  • FAILED_PRECONDITION。ソースまたはシンクの構成を確認し、ワーカーログを調べます。これはバグを示している可能性もあります。

  • OUT_OF_RANGE。ソースまたはシンクで使用されているリソース(Pub/Sub トピックやサブスクリプションなど)が存在することを確認します。

  • UNAUTHENTICATED。特定のサービスに対する Identity and Access Management 権限が Dataflow サービス アカウントにあり、関連する API がプロジェクトで有効になっていることを確認します。

  • PERMISSION_DENIED。特定のサービスに対する Identity and Access Management 権限が Dataflow サービス アカウントにあり、関連する API がプロジェクトで有効になっていることを確認します。

  • NOT_FOUND。ソースまたはシンクで使用されているエンティティ(Pub/Sub トピックやサブスクリプションなど)が存在することを確認します。

  • ABORTED。ソースまたはシンクによるデータの読み取りまたは書き込みの試行をサービスが適切に処理していない可能性があります。エラーが解消されない場合は、サポートまでお問い合わせください

  • ALREADY_EXISTS。すでに存在するエンティティ(Pub/Sub トピックやサブスクリプションなど)を作成しようとする試みが I/O によって行われている可能性があります。エラーが解消されない場合は、サポートまでお問い合わせください

  • CANCELLED。これは、Dataflow ワーカーがシャットダウンされた場合や、ソースまたはシンクのロジックでデータの読み取りまたは書き込みの試行が意図的にキャンセルされた場合に発生する可能性があります。

  • DATALOSS。復元できないデータ損失またはデータ破損が発生したことを示します。ソースに新しいデータセットを作成して、Dataflow ジョブを再実行することをおすすめします。

    また、基盤となる Google Cloud サービスで実行可能なバックアップと復元の手順があるかどうかを確認してください。

  • UNKNOWN。サービスが停止している可能性があります。詳細については、Cloud ステータス ダッシュボードを確認してください。

  • INTERNAL。サービスが停止している可能性があります。詳細については、Cloud ステータス ダッシュボードを確認してください。

  • UNAVAILABLE。サービスが停止している可能性があります。詳細については、Cloud ステータス ダッシュボードを確認してください。

  • UNIMPLEMENTED。ソースまたはシンクが無効な方法でサービスを使用しようとしました。パイプラインが正しく構成されていない可能性があります。エラーが解消されない場合は、サポートまでお問い合わせください

ワーカーの起動エラー

ログタイプ dataflow.googleapis.com/worker-startupdataflow.googleapis.com/harness-startupdataflow.googleapis.com/kubelet のエラーは、ジョブ構成の問題を示します。また、通常のロギングパスが機能しない状態であることを示している場合もあります。

NoClassDefFound エラー

これらのエラーは、Unable to initialize main class [...] の形式で示される場合もあります。NoClassDefFound エラーは、Dataflow サービスにアップロードされる JAR ファイルに、Dataflow の実行に必要なクラスが含まれていないことを示します。この問題は、--filesToStage PipelineOption がオーバーライドされ、必要な JAR ファイルまたはクラスファイルの一部が省略されている場合に最も頻繁に発生します。

イメージの pull リクエストがエラーで失敗した

このエラーは、ワーカーが Docker コンテナ イメージを pull できなかったために起動できなかったことを示します。これは、カスタム SDK コンテナ イメージの URL が間違っているか、ワーカーにリモート イメージへの認証情報またはネットワーク アクセス権がない場合に発生する可能性があります。

ジョブでカスタム コンテナ イメージを使用している場合は、イメージ URL が正しいこと、有効なタグまたはダイジェストがあること、Dataflow ワーカーがイメージにアクセスできることを確認します。

認証されていないマシンから docker pull $image を実行して、公開イメージをローカルで pull できることを確認します。

非公開イメージまたは非公開ワーカーについては、他の考慮事項があります。

  • Dataflow は、Container Registry でホストされている非公開コンテナ イメージのみをサポートします。Container Registry を使用してコンテナ イメージをホストする場合、デフォルトの Google Cloud サービス アカウントは、同じプロジェクト内のイメージにアクセスできます。Google Cloud ジョブの実行に使用しているプロジェクトとは異なるプロジェクトでイメージを使用している場合は、デフォルトの Google Cloud サービス アカウントにアクセス制御を構成してください。
  • 共有 Virtual Private Cloud(VPC)を使用する場合は、ワーカーがカスタム コンテナ リポジトリ ホストにアクセスできることを確認します。
  • ssh を使用して、実行中のジョブワーカー VM に接続し、docker pull $image を実行してワーカーが正しく構成されていることを直接確認します。

このエラーが原因でワーカーが連続して数回失敗し、ジョブで作業が開始されていない場合、ジョブは Job appears to be stuck. ... などのエラーで失敗する可能性があります。イメージ自体を削除するか、Dataflow ワーカー サービス アカウントの認証情報またはイメージへのインターネット アクセスを取り消すことで、ジョブの実行中にイメージへのアクセス権を削除した場合、Dataflow はエラーのみをログに記録し、ジョブが失敗するアクションを実行することはありません。また、Dataflow は、長時間実行されるストリーミング パイプラインの失敗を回避して、パイプライン状態が失われることを回避します。

他にも、リポジトリの割り当ての問題や停止によってエラーが発生する可能性があります。公開イメージの pull や一般的なサードパーティ リポジトリの停止のため Docker Hub の割り当てを超過する問題が発生した場合は、Container Registry をイメージ リポジトリとして使用することを検討してください。

ポッドの同期エラーで「StartContainer」に失敗した

このエラーは、ワーカー Docker コンテナを開始できなかったことを示します。これは通常、コンテナの 1 つが起動時に継続的にクラッシュする場合に発生します。

コンテナがクラッシュした場合は、worker-startup、harness-startup、docker ログで失敗を説明するエラー メッセージを探します。Python ジョブが起動時にクラッシュする一般的な原因は、依存関係の問題による pip のインストール エラー(pip install failed with error...)です。たとえば、互換性のない依存関係が指定されていることや、ネットワークの問題で指定されたリポジトリに到達できないことがあります。コンテナにインストールされている Apache Beam Python SDK は、ジョブの起動に使用する SDK と同じである必要があります。

このエラーは、長時間実行ジョブの期間でコンテナ イメージを pull できない場合にも発生することがあります。詳しくは、イメージの pull リクエストがエラーで失敗したをご覧ください。

「A fatal error has been detected by the Java Runtime Environment」

これは、パイプラインが Java Native Interface(JNI)を使用して Java 以外のコードを実行し、そのコードまたは JNI バインディングにエラーがあることを示します。

ログ

ログが表示されない

ジョブのログが表示されない場合は、すべての Cloud Logging ログルーター シンクから resource.type="dataflow_step" を含む除外フィルタを削除します。

[ログルーター] に移動

ログの除外フィルタの削除については、除外の削除ガイドをご覧ください。

推奨事項

Streaming Engine の転送割り当て使用量が多い

Streaming Engine を使用するジョブには、Streaming Engine との間で転送できるデータ量にリージョンの上限が適用されます。上限に達すると、ジョブのパフォーマンスに影響する可能性があるため、上限を超えないようにするのが重要です。また、転送するバイト数を減らすと、費用が減ることがあります。

プロジェクトの上限については、割り当てと上限をご覧ください。ジョブの現在の使用状況を確認するには、Metrics Explorer を使用します。必要に応じて、ジョブを実行しているプロジェクトを選択します。REGION を目的のリージョンに置き換えて、[クエリを実行] をクリックします。

使用量を減らすための提案事項:

  • GroupByKey 変換と Combine 変換によって処理されるデータの量を減らします。これは、渡す要素の数を減らすか、不要なフィールドを省略することで実現できます。
  • データを効率的にエンコードすることでスペースを節約できます。これにより、ワーカーの CPU 使用率が高くなることがあります。

    • カスタムデータ型の場合、デフォルトのコーダーが非効率的になる可能性があります(Java では SerializableCoder、Python では PickleCoder)。より効率的なカスタムタイプのデフォルト コーダーや、スキーマを含む PCollection を選択してみてください。

      コーダーとその指定方法について詳しくは、Beam プログラミング ガイドのデータのエンコードに関する章をご覧ください。スキーマを含む PCollection の詳細については、スキーマに関する章をご覧ください。

    • 大きな要素の場合、圧縮を適用すると便利な場合があります。

  • 大規模な読み取りを減らします。たとえば、十分な大きさの BagState を持つパイプラインは、取得されるたびに Streaming Engine から転送する必要があります。

    • 状態サイズを小さくしてみてください。
    • 状態の取得頻度を減らしてみてください。
    • 状態は特定のキーとウィンドウに関連付けられます。非グローバルのウィンドウ処理を使用すると、状態サイズを制限できます。

    状態の詳細については、Beam プログラミング ガイドの状態とタイマーに関する章をご覧ください。

自動スケーリング: maxNumWorkers を増やす

Dataflow が、ジョブが許容されるワーカーの最大数 maxNumWorkers(または max_num_workers)を使用していることを検出しています。また、この最大値が引き上げられた場合にジョブがより多くのワーカーを使用する可能性があることを検出しています。たとえば、maxNumWorkers が 50 に設定されていて、50 個のワーカーを使用しており、平均ワーカー CPU 使用率が 80% を超えているジョブの場合、この推奨事項が適用されます。

通常、maxNumWorkers を増やすとパイプライン スループットが向上します。バッチ パイプラインは短時間で完了するようになります。ストリーミング パイプラインは、より大きなデータスパイクを処理できるようになり、1 秒あたりに処理される要素数が増加します。ただし、費用が増加する可能性があります(ワーカー リソースの料金をご覧ください)。自動スケーリング アルゴリズムの仕組みとその構成方法については、自動スケーリング ガイドをご覧ください。

提案事項:

  • maxNumWorkers パイプライン オプションを増やすか、削除してみてください。このオプションを指定しないと、Dataflow は自動スケーリング ガイドに記載されているデフォルトを使用します。
  • パイプラインのパフォーマンスが十分であれば、何もする必要はありません。
    • バッチ パイプラインの場合、合計実行時間が要件を満たしていることを確認します。
    • ストリーミング パイプラインの場合は、ジョブページの [ジョブの指標] タブでデータの更新頻度グラフを確認します。このグラフの値が継続的に増加していないことと、値が許容範囲内にあることを確認してください。

高いファンアウトの検出

Dataflow は、ジョブに 1 つ以上の「高いファンアウト」の変換があることを検出しました。これは、入力対要素数の比率が高い ParDo が、後続の ParDo と融合された場合に発生します。この状況では、2 番目の ParDo は最初のものと順次実行されます。これにより、特定の入力のすべての出力要素が同じワーカーに強制されるため、並列処理が低減し、パフォーマンスが低下します。

提案事項:

  • GroupByKey を挿入し、最初の ParDo の後でグループ化を解除します。Dataflow サービスは、集約で ParDo 操作を融合しません。
  • 中間 PCollection を副入力として別の ParDo に渡します。Dataflow サービスは常に副入力を実体化します。
  • 再シャッフル ステップを挿入します。再シャッフルでは、融合が防止され、データがチェックポイント処理され、データが破棄されないようにウィンドウ処理戦略が再構成されます。再シャッフルは、Apache Beam のドキュメントで非推奨とされていても Dataflow でサポートされています(データを再シャッフルすると、パイプラインの実行費用が高くなる可能性があります)。