Airflow

왜 새 저장소가 필요한가

Airflow는 늘 태스크를 무상태(stateless)이고 멱등(idempotent)한 작업 단위로 모델링해왔다. 그런데 태스크의 반환값 바깥에 어떤 데이터를 유지해야 하는 워크로드 부류가 점점 늘고 있다 — 워커 크래시를 견뎌내야 하는, 제출된 작업 ID, run마다 전진하는 워터마크, 관측성을 위해 노출하는 row 카운터 같은 것들이다. Task state store와 Asset state store는 기존 XCom이나 Variable 시스템을 건드리지 않고 이 공백을 메운다.

Task state store vs Asset state store

Task state store는 단일 태스크 인스턴스(dag_id + run_id + task_id + map_index)에 스코프되며, 보존 기간을 설정할 수 있고 clear_on_success=True일 때 태스크 성공 시 자동으로 정리된다. 주 용도는 재시도를 버티기, 진행 중인 외부 작업 추적, 하나의 run 안에서 진행 상황 체크포인트, 과거 run이 남긴 체크포인트로부터 진행 상황 재개다.

Asset state store는 특정 run과 무관하게 자산(asset)에 스코프되며, 자산이 비활성화될 때만 제거되어 무기한 보존된다. 주 용도는 run을 가로지르는 워터마크, 증분 로드 커서, 자산별 메타데이터다.

두 저장소 모두 JSON 직렬화 가능한 값만 받는다. 기본 메타스토어 백엔드를 쓸 수도 있고, 커스텀 워커측 백엔드로 오프로드할 수도 있다.

네 가지 메커니즘 중 무엇을 쓸까

XCom은 하나의 Dag run 안에서 태스크 간에 데이터를 전달하거나(한 태스크의 출력을 하류 태스크가 소비), 다른 run의 데이터를 참조해 여러 run에 걸쳐 쓰인다. 재시도 시 초기화되므로 태스크 재시도나 run을 가로지르는 지속 데이터에는 쓰면 안 된다. Variables는 배포/설치 전체 단위의, 자주 바뀌지 않고 태스크가 아니라 운영자가 설정하는 구성값에 쓴다. Task state store는 워커 크래시를 버텨야 하거나 같은 run 안에서 재시도를 가로질러 살아남아야 하는 데이터에 쓴다 — 오래 걸리는 작업이 끝나기 전에 써두는 외부 작업 ID가 대표적인 예다. Asset state store는 자산 이벤트를 가로질러, 또는 자산을 '워칭'하는 동안 지속되어야 하고 태스크가 아니라 자산이 논리적으로 소유하는 데이터에 쓴다 — 파일이 도착할 때마다 전진하는 워터마크가 그 예다.

주의할 점: 기존 구현이 이미 XCom 기반 패턴으로 잘 동작하고 있다면 task state store로 옮길 필요는 없다. task state store는 XCom이 애초에 풀도록 설계되지 않은 문제를 풀기 위한 것이다.