Data Engineering 실전 플레이북
3줄 요약
- 실전 플레이북은 배치 실패, Kafka lag, backfill, 품질 이상을 “원인 분석”보다 영향 범위, 완화, 재처리, 검증 순서로 다룬다.
- 핵심은 마지막 정상 지점, 처리 key, checkpoint, owner, runbook, 품질 검증 쿼리를 빠르게 찾는 것이다.
- Java/Spring 백엔드 개발자는 API 정상 여부만이 아니라 downstream 데이터가 믿을 수 있는 상태인지 운영 지표로 설명해야 한다.
핵심 정리
Batch 실패 대응 Runbook: 실패한 job을 다시 누르기 전에 last success, 대상 partition, 중복 안전성, 완료 검증을 확인한다.Kafka Lag와 Consumer 장애 대응: lag는 처리량 문제, poison message, downstream DB 장애, partition skew를 나눠서 본다.Backfill 재처리 Runbook: backfill은 range, batch size, throttle, checkpoint, source-target 검증이 있어야 운영 작업이 된다.데이터 품질 이상 대응 Runbook: 품질 이상은 freshness, completeness, accuracy 중 무엇이 깨졌는지 먼저 분류한다.데이터 파이프라인 설계 리뷰 템플릿: 설계 리뷰는 source, key, schema, SLA, failure mode, replay, quality rule을 빠뜨리지 않게 한다.- 이 장은 도구별 사용법이 아니라 장애 상황에서 같은 순서로 판단하게 만드는 운영 문서다.
헷갈리는 지점
- 장애 대응을 원인 규명부터 시작하기 쉽다.
- 실제 운영에서는 사용자 영향, 공개 중단, downstream pause, 재처리 범위를 먼저 정해야 한다.
- 원인 분석은 완화와 검증 경로가 보인 뒤 병렬로 진행한다.
- 재실행과 재처리를 같은 뜻으로 쓰기 쉽다.
- 재실행은 job을 다시 돌리는 행위이고, 재처리는 어떤 range와 key를 어떤 규칙으로 다시 계산하는지까지 포함한다.
- 중복 안전성과 검증 쿼리 없이 재실행하면 장애가 커질 수 있다.
- API가 정상이라면 데이터도 정상이라고 보기 쉽다.
- 데이터 장애는 lag, missing row, wrong aggregate, stale index처럼 API error rate 밖에서 생긴다.
- 그래서 batch history, consumer lag, quality rule, incident note를 함께 본다.
확인 질문
- 장애 대응에서 원인 분석보다 먼저 확인할 것은 무엇인가?
- 사용자 영향, 마지막 정상 지점, 중단 여부, 재처리 범위, 완료 검증 방법이다.
- backfill이 단순 재실행과 다른 이유는 무엇인가?
- 대상 range, 속도 제한, checkpoint, idempotency, source-target 검증이 필요하기 때문이다.
- 플레이북을 닫기 전에 반드시 남겨야 할 기록은 무엇인가?
- 실행 command, 처리 범위, 검증 쿼리 결과, owner, 재발 방지 action이다.