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

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

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

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

  1. Airflow ログを確認します。
  2. Google Cloud のオペレーション スイートを確認します。
  3. Cloud Console で、環境を実行している Google Cloud コンポーネントのページでエラーを確認します。

  4. Airflow ウェブ インターフェースの DAG のグラフビューで、失敗したタスク インスタンスを確認します。

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

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

演算子の失敗をデバッグする手順は次のとおりです。

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

一般的な問題

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

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

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

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

症状

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

修正

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

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

症状

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

修正

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

DAG で Airflow ウェブサーバーがクラッシュする、または 502 gateway timeout エラーが返される

ウェブサーバーでは、いくつかの理由で失敗が生じる可能性があります。composer-1.5.2 以降を実行している場合は、Cloud 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 のテストをご覧ください。