Google Cloud Composer (Managed Airflow) CLI 제어와 Oozie 마이그레이션 노하우
과거 당사의 빅데이터 워크플로 관리 도구(Workflow Designer)인 빅데이터 모니터링 플랫폼의 초기 버전은, 하둡 에코시스템의 정통 기술인 Apache Oozie의 난해한 XML을 마우스 드래그 앤 드롭으로 그려주는(Wrapping) 형태였습니다.
하지만 시대가 흐르면서 복잡한 의존성 관리와 동적 파이프라인 구성의 대세가 Python 기반의 Apache Airflow로 넘어가게 되었고, 일부 앞서나가는 엔터프라이즈 고객사들은 온프레미스의 On-prem 하둡을 버리고 구글 클라우드(GCP)의 완전 관리형 서비스인 Cloud Composer 기술 검증(PoC)으로 아키텍처를 선회하기 시작했습니다.
저희 엔지니어들 역시 기존 Oozie 워크플로 설계 사상을 파이썬 기반 Airflow DAG으로 변환하고 매핑하는 막대한 트랜스포메이션 짐을 안게 되었습니다. 가장 큰 벽은, 로컬 서버였다면 루트 쉘에서 냅다 airflow list_dags를 쳤겠지만, Cloud Composer는 구글이 인프라를 다 틀어막아 놓아서, 철저하게 GCP 래핑 커맨드 도구인 gcloud 명령어의 구멍을 통해서만 신호를 던져야 했다는 점입니다.
1. Cloud Composer의 낯선 Airflow CLI 문법 (--)
GCP 환경 내에서는 Airflow의 로컬 바이너리 파일을 직접 찌를 수 없습니다. 대신 gcloud composer environments run 이라는 길고 긴 대리인 명령어를 적은 다음, 우측 끝단에 더블 대시(--) 옵션 구분자를 둠으로써 좌측은 GCP 파라미터로 처리하고 우측은 Airflow 컨테이너 내부로 쏙 패스 스루(Pass-through)시켜버리는 교묘한 문법을 사용합니다.
$ airflow list_dags -r
# Cloud Composer (GCP) 환경의 래핑된 명령어 체계 (파이프라인 매핑 시 치환 필요)
$ gcloud composer environments run [컴포저 환경 이름] \
--location [GCP 리전, 예: us-central1] \
list_dags \
-- \
-r(참고: 제일 끝의 -- 뒤에 붙는 -r 이 바로 오리지널 Airflow의 Report 옵션입니다.)
2. 데이터 엔지니어가 암기해야 할 필수 Airflow CLI 목록
GUI 화면 외에도, CI/CD 배포 스크립트 작성이나 야간 배치 스케줄러 장애 조치 시 엔지니어가 쉘에서 밥 먹듯 타이핑하게 되는 기초 명령어들입니다.
| Airflow 핵심 커맨드 | 용도 및 실무 시나리오 |
|---|---|
list_dags | 전체 DAG(파이프라인 묶음) 리스트 출력. 새로 배포한 파이프라인 파싱 에러가 없는지 -r옵션으로 디버깅. |
list_tasks {dag_id} | 특정 파이프라인 껍데기 안에 들어간 세부 태스크(Job) 노드 목록 조회 확인. |
dag_state {dag_id} {execution_date} | 특정 날짜 파티션에 돈 DAG의 최종 성공/실패 여부(Success/Failed) 반환. 후행 배치 잡 체커(Checker) 스크립트에서 활용. |
trigger_dag {dag_id} | 외부 API나 센서 서버에서 조건을 충족했을 때, 해당 DAG(파이프라인 뭉치)의 강제 실행 스위치를 눌러주는 역할. |
pause / unpause {dag_id} | 배치 스케줄링 로직의 톱니바퀴를 일시 정지시켰다가 다시 켜는 토글. 유지보수 공지 시 많이 사용. |
test {dag_id} {task_id} {date} | 전체 스케줄 구조를 무시하고 단일 컴포넌트(파이썬 메서드 등) 로직만 메모리 위에 격리하여 실행 로드 모의 테스트. 가장 유용! |
이 커맨드 목록을 래핑하여 기존 플랫폼의 Oozie 커버리지(Coverage) UI를 Airflow로 부드럽게 매핑하던 그 과도기의 마이그레이션 고생길은, 지금의 클라우드 데이터 엔지니어링 역량에 커다란 뼈대가 되었습니다.
- 공식 CLI 매뉴얼: Airflow CLI Documentation