Amazon MWAA에서 발생한 "Was the task killed externally" 오류 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

Airflow 메타데이터 데이터베이스와 작업 이니시에이터의 작업 상태가 서로 다른 경우 "Was the task killed externally" 오류가 발생합니다. 오류의 원인은 다음과 같습니다.

• 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을 Directed Acyclic Graph(DAG) 이름으로 바꾸고, example-task-name을 작업 이름으로 바꾸고, example-time을 사용하려는 기간으로 바꾸십시오.

7. 검색 결과에서 작업을 참조하는 두 개의 로그 라인을 확인합니다.

   다음은 대기열에 있는 작업의 예입니다.

   [[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 인스턴스 클래스를 사용합니다.
• Amazon MWAA에서 다른 컴퓨팅 플랫폼으로 컴퓨팅 워크로드를 오프로드하도록 DAG를 다시 작성합니다.

관련 정보

Apache Airflow 웹사이트의 모범 사례