[MWAA] Airflow Unable to read remote logs from CloudWatch

Airflow에서 알 수 없는 아래와 같은 에러가 발생하며 Task가 정상적으로 실행되지 않는 문제가 발생하였다. 마이그레이션 이후 아주 간헐적으로 보이던 증상이지만 바로 해소되었었는데 결국 주말 내 문제가 발생하였다.

*** Unable to read remote logs from Cloudwatch (log_group: airflow-Task, log_stream: dag_id=HOURLY_BATCH/run_id=scheduled__2025-11-30T02_00_00+00_00/task_id=TG_COPY_TO_S3_APP_EVNT.UPLOAD_STATUS_BRANCH_app_evnt/attempt=1.log)
*** An error occurred (ResourceNotFoundException) when calling the GetLogEvents operation: The specified log stream does not exist.

*** Could not read served logs: Invalid URL 'http://:8793/log/dag_id=HOURLY_BATCH/run_id=scheduled__2025-11-30T02_00_00+00_00/task_id=TG_COPY_TO_S3_APP_EVNT.UPLOAD_STATUS_BRANCH_app_evnt/attempt=1.log': No host supplied

 

실패한 Task의 실행 로그를 자세히 살펴보면 위와 같은 로그가 찍혀있는 것을 볼 수 있다. 직역하자면, CloudWatch로부터 로그를 읽어들일 수 없다는 내용이다. 또 특이한 점은 실제로 해당 Task가 왜 실패했는지에 대한 로그는 확인할 수 없다는 것이었다.

결국, 약 4시간이 흐른 뒤에 MWAA 재기동을 하고 난 후 시스템이 정상화 되었지만 왜 이런 문제가 발생했는지에 대한 원인 파악이 필요했다. Task 재시도 내역을 자세히 보면, 총 7번 재시도 했고 첫번째와 일곱번째 시도만이 성공한 것을 볼 수 있다. 여기서 이상한 점은 실패한 두번째부터 여섯번째까지의 실패로그는 위와 같이 로그 자체를 읽을 수 없다는 내용 뿐이었다.

로그 그룹에서도 역시나 성공한 첫번째, 일곱번째 로그만 생성되어 있었다. 정말 당황스러웠다. 보통 실패하면 실패 로그를 확인하고 원인을 찾아 분석 후에 수정, 반영을 하게 되는데 어디서 어떤 문제가 발생해서 어떻게 접근해야 하는지 조차 감이 안잡혔기 때문이다.

 

'Airflow와 CloudWatch 사이에 통신 등의 장애가 있어서 문제가 발생한 것이 아니냐' 라는 의견이 있었지만 인프라 측면에서 수정 또는 작업한 내역이 없었기 때문에 좀 더 딥하게 살펴보았다. AWS 공식 문서를 찾아보니 몇가지 살펴볼 사항이 있었는데 MWAA 환경에 대한 INFO 수준에서의 작업 로그는 이미 남기고 있었고, 환경 실행 역할 권한 등은 수정한 게 없었다. 그렇다면 마지막으로 확인해야 하는 건 DAG를 구문 분석할 수 있는 충분한 리소스가 있는지 확인하는 것이었다.

 MWAA 환경 CloudWatch Metrics와 대시보드를 확인해보았다. CloudWatch Metrics 확인 결과 Scheduler 의 CPUUtilization 가 매우 높음을 확인했다. 해당 내용에 대해 AWS에 티켓 문의를 해본 결과, MWAA에서는 정상적이고 최적의 퍼포먼스를 위하여 CPU Utilization는 50% 정도로 유지 할 것을 권장하며, 80%가 넘어가면 워커나 스케줄러가 정상적으로 작동하지 못하고 예기지 못한 이슈를 야기할 수 있음을 안내하고 있었다.

>>> CPUUtilization metrics

2025-11-30 01:26 UTC
1.            Scheduler    99.3872252405
2.            AdditionalWorker    13.4178307839
3.            WebServer    5.81386332959
4.            BaseWorker    5.78402425488
2025-11-30 01:34 UTC
1.            Scheduler    98.4729288816
2.            AdditionalWorker    17.964034515
3.            WebServer    6.37259119749
4.            BaseWorker    2.84444893803
2025-11-30 01:35 UTC
1.            Scheduler    76.5888133049
2.            AdditionalWorker    13.5077726191
3.            BaseWorker    11.5381251399
4.            WebServer    6.13209998608
2025-11-30 01:40 UTC
1.            Scheduler    99.2087888718
2.            AdditionalWorker    66.6400683927
3.            BaseWorker    32.693104177
4.            WebServer    6.08082380891

 

대시보드로 확인한 CPUUtilization

 

현재 운영 중인 Airflow 환경은 약 45개의 DAG로 구성되어 있고, 각 DAG는 여러 개의 파일로 나뉘어 있을 뿐만 아니라 DAG 간 의존성도 깊게 얽혀 있었다. 게다가 실행되는 작업 자체도 전반적으로 무겁다 보니, 전체적으로 상당히 큰 규모의 워크로드를 처리하는 구조이다.

이런 이유로 MWAA 환경도 기존 GCP에서 사용하던 사양과 동일하게 맞추기 위해 mx1.xlarge로 구성해 두었는데, 실제 운영을 해보니 이 스펙으로는 처리해야 할 작업량을 감당하기에 부족했다. 또한, 시간이 지남에 따라 처리할 데이터는 늘면 늘었지 줄어들진 않을테고, 그럼 DAG는 더 무거워질 수 밖에 없다. 결국 리소스 부족으로 인한 성능 문제와 장애가 발생하는 상황이 나타났다.

이러한 방법을 해결하기 위해서는 장기적으로는 Airflow로 처리해야 하는 Job을 줄인다던지, 데이터 관점에서 처리할 데이터 양을 조절하는 방식을 고려해야 하지만, 지금 당장 위 문제를 해결하기 위해서는 MWAA 리소스 관점에서 해결해야 하는 방법 뿐이었다.

 

MWAA에서는 Configure 설정을 통해 파라미터 튜닝도 가능하고, 환경 업데이트를 통해 리소스 업데이트도 가능하다. 물론 두 작업 모두 재기동은 필요하다.

 

튜닝

Airflow의 configuration을 좀 찾아보니 스케줄러의 CPU 사용량에 영향을 주는 파라미터를 확인할 수 있었다.

 

1) scheduler.dag_dir_list_interval

“DAG 파일이 있는 디렉토리를 몇 초마다 스캔할 것인지”

• Scheduler는 /dags 폴더를 일정 주기로 스캔해서 변경된 DAG이 있는지 확인함
• 이 스캔 주기가 바로 dag_dir_list_interval

기본값: 300초 (5분)

Airflow는 기본적으로 5분마다 한번씩 DAG 디렉토리 전체를 읽음

 

현재 값: 600초 (10분)

➡ 10분마다 한 번만 스캔함.

항목	영향
DAG 파일 변경 감지	느려짐 (10분까지 느려질 수 있음)
Scheduler 부하	줄어듦
파일 수가 많은 환경	성능엔 유리
빠른 배포/테스트	불리

 

2) scheduler.min_file_process_interval

“각 DAG 파일을 최소 몇 초 이후에 다시 파싱할지”

Scheduler는 모든 DAG 파일을 스캔 후 DAG 내 Python 코드를 파싱하는데, 파일 수가 많을 경우 자원이 많이 듦.

그래서 Airflow는 "한번 파싱한 파일은 최소 X초가 지나야 다시 파싱"하도록 해줌.

 

기본값: 30초

같은 DAG이라도 최소 30초마다 다시 파싱할 수 있음.

현재 값: 600초 (10분)

➡ 같은 DAG 파일을 최소 10분 동안 다시 파싱하지 않음.

항목	영향
DAG 파싱 빈도	대폭 감소
Scheduler CPU 사용량	크게 감소
DAG 코드 변경 반영 시간	늦어짐 (최대 10분 지연)
DAG 수가 많은 환경	유리

 

3) core.min_serialized_dag_update_interval

“Serialized DAG을 DB에 업데이트하는 최소 주기”

Airflow 2.x에서는 Webserver·Scheduler 성능을 위해 DAG 파일을 직접 읽지 않고 Scheduler가 DAG을 “Serialized DAG” 형태로 DB에 저장 → 웹서버는 이것만 읽음.

즉, DAG 정의 변경 → Scheduler가 Serialized DAG 갱신 → Webserver 반영 흐름임.

이 갱신 주기를 설정하는 것이 이값.

 

기본값: 30초

현재 값: 300초 (5분)

➡ Serialized DAG이 최소 5분 동안은 갱신되지 않음

항목	영향
Web UI 반영 속도	최대 5분 지연
Scheduler 부하	거의 감소
DAG 변경 직후 Trigger DAG	바로 반영될 가능성 낮음

 

위 값들은 모두 변화 감지 주기를 늘려서 스케줄러 성능을 안정시키기 위한 값들이다. 각 영향도를 살펴보면 스케줄러 부하는 확실히 잡아 안정성은 확보할 수 있을 것 같은데 DAG 반영이 느려진다는 단점이 있다. Web UI 반영도 느려지게 될거라 운영 편의성 관점에서는 여러가지 제한이 걸린다.

 

결론적으로 말하면, DAG 파일 수가 많고 스케줄러 CPU가 높다면, 스케줄러 갯수를 늘리는 것이 가장 효과적이라고 한다. 소형차에 여러가지 튜닝을 하는 것보다 중형차를 사는 것이 더 간단한 방법으로 확실한 성능 보장을 가져오는 것과 같다고 이해했다. 물론 비용은 좀 더 들긴 하지만, 비용 대비 효율성 측면에서 본다면 실제 운영 환경 스케줄러 부하 감소 효과가 매우 크다는 것을 알 수 있다.