Self-Healing Pipelines
“Building self-healing infrastructure is not about eliminating human judgement — it is about reserving human judgement for problems that actually need it.”
핵심 개념
Self-Healing Pipeline은 데이터 파이프라인의 일반적 장애를 자동으로 감지하고 복구하는 시스템이다. 핵심 원칙은 장애 유형별 전용 복구 로직을 분리하는 것 — 단일 “전부 재시도” 시스템으로는 CDC 체크포인트 계산, 메모리 기반 배치, 점진적 스케일링, 워터마크 중복 제거, 의존성 순회를 동시에 안전하게 처리할 수 없다.
복구 레이어 패턴
Halodoc의 6-레이어 아키텍처가 대표적 사례:
Layer 1: CDC 자동 복구
- 실패 태스크 감지 → 3-gate 적격성 검사(태스크 유형, 현재 상태, 에러 분류) → 안전한 재시작 체크포인트 계산(마지막 커밋 위치 - 버퍼)
- 원칙: 중복보다 데이터 완전성 — 다운스트림은 멱등성을 잘 처리하지만 데이터 갭은 잘 처리하지 못함
Layer 2: 소스-레이크 일관성 검증
- 소스와 레이크 간 고유 식별자 기반 비교
- 원칙: 기반부터 수정 — 다운스트림 보고 테이블 전에 bronze-to-silver 파이프라인을 먼저 복구
Layer 3: 미니 배치 처리
- 누적 파일 크기 기반 배치 할당(예: 2GB 단위)으로 OOM 방지
- 15GB 백로그 + 8GB executor → 8개의 2GB 배치로 안정적 처리
Layer 4: 스마트 메모리 스케일링
- Airflow
on_retry_callback에서 OOM 감지 시 점진적 메모리 증가(+25% → +40% → +60%) - 히스토리컬 메트릭 기반 동적 right-sizing이 기본선, 스케일링은 안전망
Layer 5: 웨어하우스 락 관리
- SQL 주석 워터마크(
-- ETL_INCREMENTAL__schema__table --)로 중복 세션 감지 → 고아 쿼리 취소 - 증분/백필 작업은 별도 워터마크로 동시 실행 허용
Layer 6: 캐스케이딩 의존성 복구
- BFS 탐색으로 전체 의존성 트리 구축 → 레이어별 병렬 실행
- 테이블을 최대 깊이에 배치하여 모든 업스트림 의존성 완료 보장
설계 원칙
- Alert first, act second: 자동 수정 시에도 항상 먼저 알림
- 장애 유형별 전용 로직: 범용 재시도가 아닌 특화된 복구
- 반복 장애부터 시작: 가장 자주 발생하는 장애 모드부터 자동화
- 영향 측정: 수동 개입 감소량 추적
연관 개념
- Data Pipeline Fundamentals — 파이프라인 유형과 운영 패턴
- Data Quality and Validation — 검증 체계와 카나리아 패턴
- Silent Failures and Data Integrity — 에러 없이 데이터가 유실되는 장애
- Change Data Capture — CDC 장애 복구 패턴
- Spark at Scale — Spark OOM 관리와 메모리 스케일링