[DE Ch-03] 멱등성과 재시도·백오프: 몇 번 돌려도 같은 결과와 흩어지는 재시도
오케스트레이터는 실패한 태스크를 처음부터 다시 돌립니다. 그래서 태스크는 몇 번을 돌려도 같은 결과를 내야 합니다. append와 파티션 덮어쓰기를 DuckDB로 비교하고 지운 직후 죽는 경우를 트랜잭션으로 막습니다. 지터 없는 지수 백오프가 서버가 살아나는 순간 요청을 한꺼번에 몰아오는 것과 지터가 그 대가로 늦추는 것을 시뮬레이션으로 셉니다.
[DE Ch-04] 논리 날짜와 backfill: Airflow 3에서 {{ ds }}가 가리키는 날이 바뀌었다
배치 작업에는 시계가 둘 있습니다. 언제 실행하는지와 어느 구간의 데이터를 처리하는지입니다. Airflow 2는 둘을 data interval로 묶었고 Airflow 3는 기본 timetable을 바꿔 매일 00시 run의 ds가 어제에서 오늘이 됐습니다. 이 차이를 DuckDB로 재현하고 catchup과 backfill이 지난 구간을 다시 돌리는 방식, Argo CronWorkflow가 같은 문제를 다루는 방식을 정리합니다.
[DE Ch-02] 오케스트레이터는 무엇을 맡나: cron 다음에 필요한 것들
cron으로 스크립트를 시간 차를 두고 돌리면 의존성, 재시도, 실행 기록, 지난 날짜 재실행, 실패 알림이 빠집니다. Airflow 3와 Argo Workflows가 이 일을 어떤 부품으로 나눠 맡는지, 실행 상태를 어디에 두는지, 부품 하나가 죽으면 무엇이 멈추는지 공식 문서와 기술블로그로 정리합니다.
[DE Ch-05] 스케줄 트리거와 이벤트 트리거: 시각을 기다릴지, 데이터를 기다릴지
데이터가 언제 도착할지 모르면 cron은 너무 이르거나 너무 늦습니다. 센서로 폴링하면 확인 비용과 발견 지연이 생기고 이벤트로 받으면 중복과 유실을 따로 다뤄야 합니다. Airflow 3의 Asset과 AssetWatcher, Argo Events가 이벤트를 어떻게 합치고 거르는지 공식 문서로 정리하고 폴링 비용을 시뮬레이션으로 셉니다.
[DE Ch-06] 동시성 제한, 중복 실행, 사람 승인: 오케스트레이터가 막아 주는 것과 맡겨 두는 것
Airflow는 동시 실행을 스케줄러, DAG, run, 태스크, pool 다섯 층에서 제한합니다. 그런데 max_active_runs=1은 겹침을 막을 뿐 같은 일이 두 번 도는 것은 막지 않습니다. pool로 외부 API를 보호하는 효과와 이벤트 키로 run_id를 정하는 방법을 시뮬레이션으로 확인하고 오케스트레이터의 락이 왜 최종 방어선이 될 수 없는지 분산 락 이론으로 정리합니다. 사람 승인 단계는 Airflow 3.2와 3.3, Argo suspend를 비교합니다.
[DE Ch-07] 태스크 하나가 Pod 하나가 될 때: 기동 시간을 구간으로 나누기
KubernetesExecutor와 Argo Workflows는 태스크마다 Pod를 띄웁니다. 쿠버네티스의 공식 Pod 기동 SLO는 p99 5초인데, 이 숫자는 이미지 pull과 init 컨테이너를 뺀 값입니다. Pod가 생성되어 컨테이너가 시작하기까지를 condition, 이벤트, kubelet 메트릭으로 나누는 방법과, 이미지 pull, Pod 생성 호출, init 컨테이너가 각각 어디서 시간을 쓰는지, 짧은 태스크가 많을 때의 대안을 정리합니다.