Amazon MWAA で発生する、「Was the task killed externally」エラーのトラブルシューティング方法を教えてください。

簡単な説明

「Was the task killed externally」というエラーは、Airflow メタデータのデータベースおよび、タスクの発生元の間でタスクの状態が異なる場合に発生します。エラーの原因を次に示します。

• task_queued_timeout 値に達した。デフォルト値は 600 秒です。過去のバージョンの Apache Airflow では、task_adoption_timeout 値を確認してください。詳細については、Apache Airflow のウェブサイトで task_queued_timeout_check_interval を参照してください。
• ワーカーのリソース使用率が高いため、タスクで障害が発生した。

解決策

スケジューラーのログを確認する

次の手順を実行します。

1. Amazon CloudWatch コンソールを開きます。

2. ナビゲーションペインで [ログ] を選択します。

3. [ロググループ] を選択します。

4. 確認するロググループを選択します。

5. [すべてのログストリームを検索] を選択します。

6. タスクで障害が発生した期間において検索するために、時間間隔を更新します。さらに、タスク ID で検索結果を絞り込みます。

   "example-dag-name.example-task-name manual__example-time-202X-XX-XXTXX:XX:XX.758774+00:00"

   注: 実際のものでそれぞれ、example-dag-name を有向非巡回グラフ (DAG) 名に、example-task-name をタスク名に、example-time を指定する期間に置き換えます。

7. 検索結果で、該当するタスクを参照している 2 行のログ行を特定します。

   キューに入っているタスクの例を次に示します。

   [[34m**2024-01-17T11:19:07.487+0000**[0m] [34mscheduler_job_runner.py:[0m713 INFO[0m - Setting external_id for <TaskInstance: dag_name.task_name manual__202X-XX-XXTXX:XX:XX.758774+00:00[queued]> to 8b49b168-992d-4db6-bdc7-a143d55720c8[0m

   停止したタスクの例を次に示します。

   [[34m**2024-01-17T11:30:18.936+0000**[0m] [34mscheduler_job_runner.py:[0m771 ERROR[0m - Executor reports task instance <TaskInstance: dag_name.task_name manual__202X-XX-XXTXX:XX:XX.758774+00:00 [queued]> finished (failed) although the task says it's queued. (Info: None) Was the task killed externally?[0m

次のシナリオでは、より詳細なトラブルシューティングを行うことができます。

task_queued_timeout が原因でタスクに障害が発生した

タスクをスケジュールしたときとタスクが停止したときのタイムスタンプを比較します。その差が task_queued_timeout 値以上である場合は、タスクが過度に長くキューされています。

この問題を解決するには、次の手順を実行します。

• task_queued_timeout 値を増やし、タイムアウトを発生させずに、タスクがキューで長く待機できるようにします。
• 上位の環境クラスにアップグレードすると、各ワーカーコンテナの Celery ワーカースロット数を増やすことができます。環境で実行できる同時実行タスクの数は、maxWorkers * celery.worker_autoscale です。
• DAG とタスクの負荷を分散します。一度に複数の DAG を実行しないでください。
• スケジューラーが過負荷になっていないか確認してください。スケジューラーに負荷がかかっていると、タスクが予定したタイミングでスケジュールされない可能性があります。

注: スケジューラーの数を増やすと、メタデータベースの使用率と解析時間に影響する可能性があります。スケジューラーの数を増やすと、高可用性 (HA) は向上しますが、タスクのスケジュール用のリソースは増えません。task_queued_timeout の値に達していない場合は、ワーカーログを確認してください。

ワーカーログを確認するには、次の手順を実行します。

1. Apache Airflow UI にアクセスします。
2. DAG を選択します。
3. [グラフ] を選択します。
4. タスク実行を選択します。
5. [インスタンスの詳細] を選択します。次に、external_executor_id 値を書き留めておきます。
6. [Amazon CloudWatch コンソール] を開きます。
7. ナビゲーションペインで [ログ] を選択します。
8. [ロググループ] を選択します。
9. 確認するロググループを選択します。
10. [すべてのログストリームを検索] を選択します。
11. タスクで障害が発生した期間において検索するために、時間間隔を更新します。
12. external_executor_id 値で検索を絞り込むと、ワーカー上のタスクに関連するログ行が表示されます。
13. 問題のタスクに関連するエラーメッセージを特定します。ログストリームの名前を選択すると、エラーの詳細が表示されます。

CPU またはメモリの使用率が高いため、タスクで障害が発生した

次のエラーメッセージが表示される場合は、CPU や RAM の使用率の増加など、リソース使用率の問題がワーカーに発生しています。その結果、ワーカーコンテナ上で実行されるワーカープロセスが失敗し、途中で終了します。

"[2023-07-26 13](tel:2023072613):00:49,356: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 15 (SIGTERM) Job: 1049.')"

上記エラーメッセージをトラブルシューティングするには、CPUUtilization および MemoryUtilization メトリクスを確認します。メトリクスが常に高いか、急増が発生している場合は、Amazon MWAA ワーカーに過負荷がかかっています。

過負荷状態のワーカーを解決するには、次の操作を行います。

• celery.worker_autoscale の値を減らすと、ワーカーで同時に実行されるタスクの数が減ります。
• RAM と vCPU を増やすには、上位の Amazon MWAA インスタンスクラスを使用してください。
• DAG を修正し、コンピューティングワークロードを Amazon MWAA から他のコンピューティングプラットフォームにオフロードします。

関連情報

ベストプラクティス (Apache Airflow のウェブサイト)