DAG(ワークフロー)のトラブルシューティング

このページでは、トラブルシューティングの手順と一般的なワークフローの問題に関する情報を提供します。

ワークフローのトラブルシューティング

トラブルシューティングを開始するには、次の手順を行います。

  1. Airflow ログを確認します。
  2. Stackdriver を確認します。
  3. GCP Console で、環境を実行している GCP コンポーネントのページ上のエラーを確認します。
  4. Airflow ウェブ インターフェースで、失敗したタスク インスタンスの DAG のグラフビューを確認します。

    ヒント: サイズが大きい DAG に移動して、失敗したタスク インスタンスを確認するには、ウェブサーバーのデフォルトの dag_orientation 構成をオーバーライドすることにより、グラフビューの画面の向きを LR から RL に変更します。

演算子の失敗をデバッグする

演算子の失敗をデバッグするには、次の手順を行います。

  1. タスク固有のエラーを確認します
  2. Airflow ログを確認します。
  3. Stackdriver を確認します。
  4. 演算子固有のログを確認します。
  5. エラーを修正します。
  6. dags/ フォルダに DAG をアップロードします。
  7. Airflow ウェブ インターフェースで、DAG の過去の状態を消去します。
  8. DAG を再開または実行します。

一般的な問題

以降のセクションでは、いくつかの一般的なワークフローの問題の症状と可能性のある修正方法について説明します。

ログが出力されずタスクが失敗する

ログはバッファリングされます。バッファリングがフラッシュする前にワーカーが終了した場合、ログは出力されません。ログなしでタスクが失敗する場合は、メモリ不足(OOM)により Airflow ワーカーが再起動されたことを示します。

DAG の実行には RAM の制限があります。各タスクの実行は、タスクの実行とモニタリングという 2 つの Airflow プロセスとともに開始されます。現在は、各ノードは最大 6 つの同時タスク(Airflow モジュールを読み込む、約 12 のプロセス)を実行できます。DAG のサイズによっては、より多くのメモリが消費される可能性があります。

症状

  1. GCP Console で、GKE ワークロード パネルに移動します。
  2. 「Evicted」と表示されている「airflow-worker」というポッドがある場合は、強制排除された各ポッドをクリックして、ウィンドウ上部の The node was low on resource: memory メッセージを確認します。

修正

  1. 現在のマシンタイプより大きいマシンタイプを使用して、新しい Cloud Composer 環境を作成します。
  2. DAG 内のタスクがべき等で再試行可能であることを確認します。
  3. タスクの再試行を構成します

DAG のインポートの読み込みのタイムアウト

症状

  • Airflow ウェブ UI: DAG の一覧ページの上部にある赤いアラート ボックスに、「Broken DAG: [/path/to/dagfile] Timeout」と表示される。
  • Stackdriver: airflow-scheduler ログに、次のようなエントリが含まれる。
    • 「ERROR - Process timed out」
    • 「ERROR - Failed to import: /path/to/dagfile」
    • 「AirflowTaskTimeout: Timeout」

修正

core-dagbag_import_timeoutAirflow 構成をオーバーライドして DAG の解析にかける時間を増やす。

DAG で Airflow ウェブサーバーがクラッシュし 502 gateway timeout エラーが返される

ウェブサーバーでは、いくつかの理由で失敗が生じる可能性があります。composer-1.5.2 以降を実行している場合は、Stackdriver Logging で airflow-webserver ログをチェックして、502 gateway timeout エラーをデバッグします。

重い処理

DAG の解析時には重い処理を実行しないでください。CPU とメモリ容量を増やすためにマシンタイプをカスタマイズできるワーカーノードやスケジューラ ノードとは異なり、ウェブサーバーは固定されたマシンタイプを使用します。そのため、解析時の処理が重すぎる場合、DAG の解析の失敗を引き起こす可能性があります。

ウェブサーバーには 2 つの vCPU と 2 GB のメモリが備わっていますcore-dagbag_import_timeout のデフォルト値は 30 秒です。このタイムアウト値により、Airflow が dags/ フォルダ内の Python モジュールの読み取りに費やす時間の上限が定義されます。

不適切な権限

ウェブサーバーは、ワーカーやスケジューラと同じサービス アカウントでは動作しません。そのため、ワーカーとスケジューラはウェブサーバーがアクセスできない、ユーザー管理のリソースにもアクセスできる場合があります。

DAG の解析中は、非公開リソースへのアクセスは避けることをおすすめします。これを回避できない場合もあります。その場合は、ウェブサーバーのサービス アカウントに権限を付与する必要があります。サービス アカウント名は、ウェブサーバーのドメインから取得されます。たとえば、ドメインが foo-tp.appspot.com である場合、サービス アカウントは foo-tp@appspot.gserviceaccount.com になります。

DAG エラー

ウェブサーバーは App Engine 上で動作し、環境の GKE クラスタとは分離しています。ウェブサーバーにより DAG 定義ファイルが解析され、DAG にエラーがある場合は 502 gateway timeout が発生する可能性があります。問題のある DAG によって GKE で実行中のプロセスが中断されない場合、Airflow は正常に機能しているウェブサーバーなしでも通常に機能します。この場合 gcloud composer environments run を使用して、環境から詳細を取得したり、ウェブサーバーが利用できなくなった場合の回避策にしたりします。

その他の場合には、GKE で DAG の解析を実行して、致命的な Python 例外をスローする DAG やそのタイムアウト(デフォルトは 30 秒)を確認できます。トラブルシューティングを行うには、Airflow ワーカー コンテナ内のリモートシェルに接続して構文エラーをテストします。詳細については、DAG のテストをご覧ください。

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

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