Airflow

왜 관측가능성이 중요한가

데이터 파이프라인은 일반적으로 수동 감독 없이 실행되므로, 문제가 발생했을 때 원인을 빠르게 진단할 수 있는 로깅과 메트릭이 필수적이다. Airflow는 여러 로깅 메커니즘과 함께, 다운스트림 시스템에서 수집·처리·시각화할 수 있도록 메트릭을 내보내는 내장 기능을 갖추고 있다.

로깅과 메트릭 외에도 Airflow는 자기 자신의 운영 이상 여부를 감지하는 헬스체크 메커니즘을 지원하며, 프로덕션 환경에서 실시간 에러 알림이 필요하다는 점을 고려해 Sentry 연동도 지원한다.

기본 로깅 아키텍처

기본적으로 Airflow는 로컬 파일 시스템에 로그를 남긴다. 여기에는 웹서버, 스케줄러, 태스크를 실행하는 워커의 로그가 모두 포함되며, 이는 개발 환경이나 간단한 디버깅에는 적합하지만 그 자체로는 클라우드 프로덕션 환경에 충분하지 않다.

클라우드 배포를 위해 커뮤니티가 기여한 태스크 핸들러들이 있어 AWS, Google Cloud, Azure 같은 클라우드 스토리지로 로그를 보낼 수 있다. 로깅 설정 항목은 Airflow 설정 파일에 지정하며, 이 설정 파일은 웹서버·스케줄러·워커 등 모든 Airflow 프로세스에 동일하게 배포되어 있어야 한다.

프로덕션 배포에서는 로그 수집에 FluentD를 사용해 ElasticSearch나 Splunk 같은 목적지로 전달하는 것을, 메트릭 수집에는 StatsD를 사용해 Prometheus 같은 목적지로 전달하는 것을 권장한다.

Airflow 기본 로거 목록

Airflow는 파이썬 표준 logging 프레임워크를 사용하며, 대부분의 로거는 파이썬 패키지/모듈 네이밍 규칙을 따른다. 로그를 읽거나 로깅 동작을 커스터마이즈할 때 알아두면 좋은 로거 이름들이 있다.

``root``는 파이썬 루트 로거로, 태스크 실행 중에는 Airflow가 루트 로거를 재설정해 표준 파이썬 로거로 전파되는 로그가 태스크 로그로 쓰이게 한다. ``airflow.task``는 태스크 로그의 부모 로거이며, 오퍼레이터/훅은 각각 ``airflow.task.operators``, ``airflow.task.hooks`` 하위의 자식 로거를 사용한다. ``airflow.processor``는 Dag 파일 파싱 과정에서 나오는 메시지에 쓰이고, ``airflow.processor_manager``는 스케줄러의 Dag 프로세서 매니저가 Dag 처리 활동을 보고할 때 쓰인다. ``flask_appbuilder``는 웹서버의 Flask-AppBuilder가 쓰는 로거로, Airflow의 기본 설정은 이 로거를 다른 컴포넌트 로거보다 덜 시끄럽게 유지한다.

태스크 로그는 다른 컴포넌트 로그와 별도로 설정되는데, 이는 태스크 로그가 태스크 인스턴스 단위로 그룹핑되어 Airflow UI에서 볼 수 있어야 하기 때문이다.