05. Pipeline 장애 대응 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• pipeline 장애는 API 장애와 어떻게 다르게 발견되고 대응되는가?
• freshness, completeness, accuracy 중 어떤 지표로 장애를 분류해야 하는가?
• 장애가 발생했을 때 raw, fact, mart 중 어디서부터 재처리해야 하는가?
• 백엔드 팀과 데이터 팀은 pipeline 장애에서 어떤 정보를 주고받아야 하는가?

개요

pipeline 장애는 API 장애처럼 즉시 사용자 오류로 드러나지 않을 수 있다.

데이터가 늦게 들어오거나, 일부만 적재되거나, 잘못 변환되어도 dashboard는 계속 열릴 수 있다.

freshness와 completeness 알림이 없으면 분석가나 제품 담당자가 먼저 이상을 발견한다.

pipeline 장애 대응은 task 재실행보다 영향 범위 판단과 데이터 공개 제어가 먼저다.

원리

pipeline 장애는 세 가지로 분류하면 대응이 빨라진다.

• Freshness: 데이터가 늦다.
• Completeness: 데이터가 일부 빠졌다.
• Accuracy: 데이터가 들어왔지만 값이 틀렸다.

task 실패는 원인일 수 있지만, 사용자에게 보이는 영향은 freshness, completeness, accuracy로 설명하는 편이 좋다.

장애 분류

장애	예시	우선 확인
Extract 실패	source 연결 실패	source range, credential, schema
Transform 실패	enum 미처리	raw 존재, parser, rule 변경
Load 실패	warehouse 권한 오류	target partition, upsert, lock
Validation 실패	count mismatch	source/raw/fact/mart 비교
Publish 실패	dashboard stale	공개 상태, stale label

장애 대응자는 어느 task가 죽었는지와 어떤 데이터가 사용자에게 노출되는지를 함께 본다.

첫 10분 체크

1. 어떤 pipeline과 target partition이 실패했는가?
2. 마지막 성공 partition은 무엇인가?
3. source raw는 존재하는가?
4. fact와 mart 중 어디까지 검증됐는가?
5. dashboard나 downstream 공개를 막아야 하는가?
6. 재처리는 raw부터 필요한가, mart만 다시 만들면 되는가?

이 순서를 두면 “일단 전체 재실행”으로 가는 위험을 줄일 수 있다.

장애 알림 예시

[P2] mart_sales_daily freshness breach
pipeline: order_sales_pipeline
target_partition: ds=2026-06-30
last_success_partition: ds=2026-06-29
failed_task: build_mart_sales_daily
raw_status: SUCCESS
fact_status: VALIDATED
mart_status: FAILED
impact: sales dashboard stale
safe_rerun: build_mart_sales_daily from fact_order_payment
runbook: /runbooks/order-sales-pipeline

좋은 알림은 재처리 시작점을 제안한다.

raw부터 다시 추출해야 하는지, mart만 다시 만들면 되는지 알 수 있어야 한다.

재처리 판단

if raw missing:
  rerun extract + raw load
elif fact validation failed:
  rerun transform from raw
elif mart build failed:
  rerun mart from fact
elif publish failed:
  rerun publish only

재처리 시작점은 실패 task만으로 정하지 않는다.

upstream 데이터가 검증되었는지 확인해야 한다.

검증 SQL

SELECT COUNT(*) AS raw_count
FROM raw_orders
WHERE ds = DATE '2026-06-30';

SELECT COUNT(*) AS fact_count, SUM(paid_amount) AS fact_amount
FROM fact_order_payment
WHERE paid_at >= TIMESTAMP '2026-06-30 00:00:00'
  AND paid_at < TIMESTAMP '2026-07-01 00:00:00';

SELECT refreshed_at
FROM mart_sales_daily
WHERE order_date = DATE '2026-06-30'
ORDER BY refreshed_at DESC
LIMIT 1;

장애 대응 SQL은 runbook에 있어야 한다.

운영 중에 새로 만들면 복구 시간이 늘어난다.

공개 제어

pipeline 장애는 잘못된 데이터를 공개하지 않는 것이 중요하다.

dashboard는 stale label을 보여줄 수 있어야 한다.

추천 feature나 리포트 API가 mart를 쓰는 경우 fallback 기준을 정한다.

품질 검증 실패 후에도 최신 데이터처럼 보여주면 장애가 더 커진다.

판단 축

• task 실패와 데이터 영향 범위를 분리한다.
• 마지막 성공 partition과 현재 target partition을 비교한다.
• raw, fact, mart 중 검증된 마지막 지점을 찾는다.
• downstream 공개를 멈출지 stale 표시할지 정한다.
• 재처리 후 count, sum, freshness를 다시 검증한다.

실패 모델

• task retry만 반복하고 dashboard stale 상태를 공지하지 않는다.
• raw가 없는 상태에서 transform부터 재실행하려 한다.
• fact 검증이 실패했는데 mart만 다시 만든다.
• 장애 알림에 target partition이 없어 운영자가 범위를 모른다.
• 재처리 후 검증 없이 checkpoint를 성공으로 바꾼다.

운영 지표

• freshness_lag_minutes: target이 얼마나 늦었는지다.
• completeness_diff_count: source와 target count 차이다.
• accuracy_rule_failed_count: 금액, 상태, dimension rule 실패 수다.
• last_success_partition: 마지막 성공 partition이다.
• rerun_duration_seconds: 재처리 소요 시간이다.
• stale_dashboard_exposure_minutes: stale 데이터 노출 시간이다.

백엔드 협업

pipeline 장애가 source schema나 source data 의미에서 시작될 수 있다.

백엔드 팀은 다음 정보를 빠르게 제공해야 한다.

• 최근 DB migration
• event schema 변경
• status 값이나 enum 추가
• 삭제/취소 처리 변경
• source row count 급증 여부
• peak time이나 대량 작업 여부

데이터 팀은 pipeline 실패 task, target partition, 품질 검증 결과를 백엔드에 제공한다.

개인 프로젝트 기준

개인 프로젝트에서는 장애 대응을 간단한 checklist로 시작한다.

마지막 성공 날짜, raw count, target count, 재실행 command, 검증 SQL만 있어도 충분하다.

dashboard가 없다면 README에 “데이터 최신 시각”을 확인하는 SQL을 남긴다.

기업 운영 기준

기업 운영에서는 incident severity를 데이터 영향으로 정한다.

freshness breach가 10분인 경우와 정산 mart가 하루 비는 경우는 등급이 다르다.

owner, on-call, 알림 채널, 공개 차단 권한, 재처리 승인 절차를 runbook에 둔다.

실전 팁

• 장애 알림에는 target partition과 마지막 성공 partition을 넣는다.
• retry 전에 upstream validation 상태를 확인한다.
• 품질 검증 실패는 task 성공보다 우선한다.
• 재처리 후에는 source/raw/fact/mart count를 단계별로 비교한다.
• 장애 회고에는 발견 지표가 충분했는지 확인한다.

위험 신호!

• pipeline 실패를 Airflow task red 하나로만 설명한다.
• freshness 지표가 없어 사용자가 먼저 stale 데이터를 발견한다.
• raw, fact, mart 중 어느 단계가 맞는지 알 수 없다.
• 재처리 시작점을 운영자가 감으로 정한다.
• 장애 후 quality rule이나 알림 기준을 갱신하지 않는다.

확인 질문

확인 질문

• pipeline 장애를 freshness, completeness, accuracy로 나누는 이유는 무엇인가?
  • task 실패보다 데이터 소비자에게 보이는 영향과 복구 우선순위를 더 잘 설명하기 때문이다.
• mart build 실패 시 어디서부터 재처리해야 하는가?
  • raw와 fact가 검증되었다면 mart부터 재처리하고, fact 검증이 실패했다면 raw 또는 fact 단계부터 다시 시작한다.
• 장애 알림에 반드시 들어가야 할 정보는 무엇인가?
  • pipeline 이름, target partition, 마지막 성공 partition, 실패 task, upstream 검증 상태, 영향, safe rerun, runbook이다.

참고 문서

• Apache Airflow Documentation
• dbt Documentation, Source Freshness
• Google SRE Book, Monitoring Distributed Systems
• Martin Kleppmann, Designing Data-Intensive Applications