Airflow

감사 로그란 무엇인가

감사 로그는 Airflow 시스템의 역사적 기록으로서 누가 어떤 작업을 언제 수행했는지 문서화한다. 이는 시스템 무결성 유지, 컴플라이언스 요구사항 충족, 문제 발생 시 포렌식 분석을 위해 필수적이다. 감사 로그는 본질적으로 Who(누가), What(무엇을), When(언제)이라는 세 가지 근본 질문에 답한다.

감사 로그의 주요 목적은 규제 컴플라이언스(데이터 거버넌스와 감사 추적 요구 충족), 보안 모니터링(비인가 접근이나 의심스러운 활동 탐지), 운영 트러블슈팅(문제로 이어진 사건의 순서 파악), 변경 관리(핵심 시스템 구성요소에 대한 수정 추적)로 요약된다.

감사 로그 열람에는 Audit Logs.can_read 권한이 필요하다. 이 권한을 가진 사용자는 자신의 DAG별 접근 권한과 무관하게 모든 감사 로그 항목을 볼 수 있다 — 즉 특정 DAG에 대한 열람 권한이 없어도 그 DAG에서 벌어진 일에 대한 감사 기록은 볼 수 있다는 뜻으로, 감사 권한 부여 시 유의해야 할 지점이다.

감사 로그 vs 이벤트 로그

이벤트 로그는 시스템의 운영상 심장 박동이라 할 수 있다. 책임 소재와 컴플라이언스에 초점을 둔 감사 로그와 달리, 이벤트 로그는 시스템 동작, 애플리케이션 성능, 운영 지표의 기술적 세부사항을 담는다. 디버깅과 트러블슈팅(상세 에러 메시지와 스택 트레이스), 성능 모니터링(실행 시간, 리소스 사용량), 운영 인사이트(시스템 헬스, 컴포넌트 상호작용), 개발 지원(코드 디버깅 정보)이 이벤트 로그의 주요 기능이다.

두 로그 시스템은 목적과 대상이 뚜렷이 다르다. 감사 로그는 보안팀·감사관·컴플라이언스 담당자를 대상으로 사용자 행위와 관리 변경 내역에 집중하며, 구조화된 데이터베이스 테이블(log)에 장기간(컴플라이언스를 위해 몇 달에서 몇 년, DB에서 정리되지 않는 한) 보관된다. 반면 이벤트 로그는 개발자·시스템 관리자·운영팀을 대상으로 시스템 동작·에러·성능 데이터에 집중하며, 로그 파일이나 외부 로깅 시스템에 단기~중기(며칠~몇 주)로 보관된다.

질의 패턴도 다르다. 감사 로그는 "누가 이 태스크 인스턴스를 재실행을 위해 클리어했는가?" 같은 질문에 답하도록 설계되어 있고, 이벤트 로그는 로그 집계 프레임워크를 쓰지 않는 한 별도의 질의 없이 태스크 실행 단위로 읽히며 "이 태스크 실행이 왜 실패했는가?"를 설명하는 데 쓰인다.

감사 로깅의 세 영역과 접근 방법

Airflow의 감사 로깅 시스템은 세 가지 서로 다른 운영 영역에 걸친 이벤트를 포착한다. 사용자 주도 작업(User-Initiated Actions)은 웹 UI, REST API, CLI 등 어떤 인터페이스를 통해서든 사용자가 Airflow와 상호작용할 때 발생하며, 수동 DAG 실행 트리거, 변수/커넥션/풀 설정 변경, 태스크 인스턴스 상태 수정(클리어, 성공/실패 표시), 관리 작업과 사용자 관리 활동을 포함한다. 시스템 생성 이벤트(System-Generated Events)는 Airflow 내부 프로세스가 정상 동작 중 자동으로 만들어내며, 태스크 생애주기 상태 전이(queued, running, success, failed), 시스템 모니터링 이벤트(하트비트 타임아웃, 외부 상태 변경), 자동 복구 작업(재스케줄링, 재시도), 리소스 관리 활동을 포함한다. CLI 작업(Command-Line Interface Operations)은 Airflow CLI 도구를 통해 수행된 활동을 포착하며, 직접적인 태스크 실행 명령, DAG 관리 작업, 시스템 관리/유지보수 작업, 자동화된 스크립트 실행을 포함한다.

감사 로그 데이터에 접근하는 방법은 크게 두 가지다. 웹 UI에서는 Browse → Audit Logs 메뉴로 필터링·정렬·검색 기능을 갖춘 인터페이스에 접근할 수 있어 임시 조사나 일상적 모니터링에 적합하다. 프로그래밍적 접근과 시스템 통합에는 /eventLogs REST API 엔드포인트를 사용하며, 이는 자동화된 모니터링, 외부 보안 도구와의 연동, 커스텀 리포팅 애플리케이션 구축에 쓰인다.

이벤트 카탈로그와 로그 엔트리의 구조

태스크 인스턴스 이벤트는 세 갈래로 나뉜다. 시스템 생성 이벤트에는 running/success/failed/skipped/upstream_failed/up_for_retry/up_for_reschedule/queued/scheduled/deferred/awaiting_input(휴먼 인 더 루프 대기)/restarting/removed가 있고, 시스템 모니터링 이벤트에는 heartbeat timeout, state mismatch, stuck in queued reschedule, stuck in queued tries exceeded가 있으며, 사용자 개입 이벤트에는 fail task/skip task와 action_set_failed/action_set_success/action_set_retry/action_set_skipped/action_set_running/action_clear가 있다.

사용자 액션 이벤트는 DAG 실행(trigger_dag_run, delete_dag_run, patch_dag_run 등), 태스크 인스턴스 조작, 변수·커넥션·풀 CRUD, 자산(Asset) 조작, 백필(backfill) 관리, 사용자·역할 관리 등 도메인별로 세분화되어 있다. CLI 이벤트 카탈로그는 특히 방대해서, 현재 쓰이는 명령(cli_dags_trigger, cli_tasks_run 등)뿐 아니라 레거시 명령(cli_run, cli_backfill, cli_migratedb, cli_initdb 등)도 하위 호환을 위해 함께 기록된다. 각 CLI 감사 로그 항목에는 실행자 식별, 인자를 포함한 전체 명령, 작업 디렉터리·환경변수 같은 실행 컨텍스트, 타임스탬프, 성공/실패 종료 상태가 담긴다. Airflow는 또한 airflow.models.log.Log 모델을 이용해 프로그래밍적으로 커스텀 감사 이벤트를 남기는 것도 지원한다.

감사 로그 레코드 하나는 dttm(UTC 타임스탬프), event(작업/이벤트 이름), owner(사용자 액션이면 사용자명, 시스템 이벤트면 "airflow"), dag_id, task_id, run_id, try_number, map_index, logical_date, extra(파라미터·에러 상세 등을 담은 JSON) 필드로 구성된다.

실전 감사 질의 패턴

감사 로그 분석에는 몇 가지 반복되는 질의 패턴이 있다. "누가 이 DAG를 트리거했는가?"는 log 테이블에서 event='trigger_dag_run'과 dag_id 조건으로 dttm 역순 정렬해 조회하고, "이 실패한 태스크에 무슨 일이 있었는가?"는 dag_id와 task_id로 필터링해 dttm 역순으로 조회하며, "누가 최근 변수를 변경했는가?"는 event가 variable을 포함하는 항목을 최근순으로 조회한다.

REST API를 통한 조회에서는 event, dag_id, after/before 같은 쿼리 파라미터로 /eventLogs 엔드포인트를 필터링할 수 있다. 실전 시나리오별로는, 보안 조사는 특정 owner의 최근 24시간 행위를 조회하는 질의를, 컴플라이언스 리포팅은 특정 기간 동안의 변수·커넥션 생성/수정/삭제 이벤트(post_variable, patch_variable, delete_variable, post_connection 등)를 모아 조회하는 질의를, DAG 트러블슈팅은 특정 dag_id와 run_id에 속한 모든 이벤트를 시간순으로 조회하는 질의를 사용한다.