6/19일 월요일 아침 주말을 잘 쉬고 출근했는데 airflow 배치가 이상함을 발견했다..
평상시 처럼 배치 에러가 떴다면, failed 가 떠서 log 확인 후 대응하면 되었는데.
이번에는 failed 는 없고, 새벽 사이에 마쳤어야 할 task 가 not yet started 상태였다.
새벽 일배치로 실행되어야하는 첫 dag 부터 돌지 않아서, 해당 dag 의 로그를 살펴보며 에러를 찾으려 했지만 아예 실행이 되지 않은 queued 상태이므로 로그파일 자체가 생성되지 않았다.
첫 번째 dag (06/18)
- dag 가 18일 3시 부터 계속해서 running 중이고, 3번째 task 가 queued (회색 네모) 상태이다.
- running 상태를 멈추기 위해 queued 인 task 를 일단 Mark Failed 로 상태 변경했다.
하위 dag (06/17)
- 17일 3시 30분 즘에 running 된 하위 dag 가 계속 runnig 상태로 존재
- 해당 task의 log 를 살펴 본 결과, spark 로 읽어오는 parquet 파일을 읽어오는 작업 중간에 멈춘 것 으로 보였다.
평소에는 실행하는 task 에 에러가 있으면 failed 가 되어서 dag 실행이 중지되었는데,
이번 경우에는 특이하게 계속해서 running 상태로 있어서 다음 날 배치까지 영향을 준것으로 파악 했다.
해결 방법
하루가 넘는 시간 동안 running 되고 있는 task 를 모두 failed 로 상태 변경을 하고.
스케줄 순서를 보고 가장 마지막으로 실행되지 않은 task 가 있는 dag 부터 trigger dag 로 강제로 실행했다.
💡 배치가 실패한 일자의 배치 중 주 단위 또는 월 단위 배치가 없어서 trigger dag 만으로도 문제가 없었다.
일 배치로 가져오는 데이터는 이전 날 업데이트 된 데이터까지 한꺼번에 오늘 기준으로도 가져올 수 있지만, 실패한 날 주 or 월 배치가 있다면, 반드시 실패한 날을 기준으로 데이터를 가져와야 한다.이 경우 airflow 서버 cli 를 통해 backfill 해야 한다.
혼란을 준 부분
가장 위의 첫번째 dag 의 running 되던 task 를 보면 3번째 task 이고 이전 task 들은 정상 실행했음을 알 수 있다. (초록색 네모)
즉 하위 dag 가 running 되는 와중에 첫 번째 dag 의 1,2 번째 task 는 잘 실행이 되었던 것이다.
3번 째 task 에서 가져오는 데이터 사이즈가 1, 2번째 보다 큰데 spark 메모리가 3번 째 task 부터는 부족했나...? 라고 생각했다 (더 알아보고 확실한 원인을 적을 예정..)
이 부분 때문에 처음에 airflow 에러 원인을 첫 번재 dag 에서 찾으려해서 해결하는데 시간이 좀 더 소요 되었다. 앞으로는 문제가 생겼을 때 전체를 보는 시각을 좀 더 가져야 겠다 생각했다. 🤓
