Data Eng Wiki

Silent Failures and Data Integrity

7 min read

Silent Failures and Data Integrity

에러 로그 없이 데이터가 유실되거나 손상되는 “조용한 장애”를 탐지하고 방지하는 패턴

핵심 개념

Silent failure는 시스템이 에러를 보고하지 않으면서 데이터가 유실·손상되는 장애 유형이다. 분산 시스템에서 특히 위험하며, 발견까지 수일~수주가 걸릴 수 있다. 검증(validation)과 구별되는 핵심 차이는 시스템이 정상으로 보고하는 상태에서 발생한다는 점이다.

대표적 조용한 장애 패턴

ClickHouse 비동기 플러시 실패

분산 테이블 INSERT의 3가지 조용한 실패 모드:

  • Keeper 다운타임: 테이블이 읽기 전용으로 전환, 삽입이 큐에 누적 후 유실
  • 과도한 블록 크기: 실행 타임아웃 초과 시 에러 로그 없이 실패
  • 동시성 슬롯 고갈: 백그라운드 INSERT 워커 기아 → 큐 파일 무한 성장

핵심 대응: /var/lib/clickhouse/data/{db}/{table}/ 분산 큐 파일 크기를 지속 모니터링

Kafka 리밸런스 문제 (KIP-848 이전)

기존 프로토콜의 조용한 데이터 처리 중단:

  • 단일 오동작 멤버가 전체 그룹 리밸런스 방해
  • Fake rebalance로 메트릭 해석 혼동
  • KIP-848의 서버 사이드 점진적 할당으로 해결

Stale 커넥션 재사용

분산 테이블 쿼리 시 TCP 풀의 stale 연결 재사용:

  • 서버의 idle_connection_timeout 만료 후 클라이언트 미감지
  • Broken Pipe 경고 발생 — 설계된 동작이지만, “괜찮아 보인다”와 “괜찮다고 안다”의 차이가 중요

SQLite WAL 동시성 데이터 유실

프로덕션 e-commerce에서 다중 컨테이너가 동일 SQLite WAL 파일에 접근할 때 발생:

  • Blue-green 배포 중 다수 컨테이너 겹침 → WAL 파일 경합 → 쓰기 유실
  • Stripe에서 결제 완료되었으나 DB에 주문 레코드 부재
  • sqlite_sequence 포렌식으로 진단: auto-increment 카운터(17) vs 실제 행 수(15)
  • 교훈: WAL 모드는 단일 프로세스 동시성 전용 — 다중 프로세스 공유 시 데이터 유실 위험

ML 피처 파이프라인 성능 저하 (Whatnot)

시간당 피처 파이프라인이 점진적으로 느려져 실질적으로 2시간 주기로 전환:

  • 에러 없음, 실패 없음, 알림 없음 — “기술적으로 정상”이지만 비즈니스적으로 열화
  • 데이터 증가로 피처 모델 2분→5분, 인제스천 5분→10분으로 점진적 증가
  • 핵심 교훈: “장애 부재”는 약한 신호 — 갱신 주기, E2E 레이턴시, 런타임 추세를 명시적으로 추적해야 함

탐지 전략

행동 메트릭 우선 (Netflix Data Canary)

기술적 메트릭(에러율, 레이턴시)보다 고객 영향 지표가 데이터 손상을 먼저 탐지:

  • SPS(Starts Per Second) 같은 행동 메트릭으로 2.5~4분 내 탐지
  • Baseline/Canary 클러스터 분리로 비교 검증

단조 증가 카운터

파이프라인 각 단계에서 처리 건수를 단조 증가 카운터로 추적:

  • 소스 ↔ Lake 카운트 일관성 검증 (Halodoc Layer 1)
  • 시간 바운드 비교로 불일치 즉시 감지

리소스 쿼터 사전 관리 (Pinterest Piqama)

리소스 고갈이 조용한 장애의 근본 원인이 되기 전에 차단:

  • 이력 데이터 기반 동적 한도 산출
  • 크로스-서비스 쿼터 적용으로 배치/온라인 양쪽 보호

Exactly-Once 보장

Transactional Outbox Pattern

DB 트랜잭션과 메시지 발행의 원자성을 보장하여 메시지 유실 방지:

  • SQLite 샤딩으로 확장
  • 에페머럴 상태와 영구 상태를 명확히 분리

Kafka KIP-848 에포크 기반 수렴

3중 에포크(Group/Assignment/Member)로 점진적 할당 수렴 — 글로벌 동기화 장벽 제거

데이터 파이프라인의 5대 조용한 실패

에러 없이 실행되면서 잘못된 데이터를 생산하는 패턴:

  1. Schema Drift: 헤더리스 SFTP 파일의 컬럼 순서 변경 — 데이터 타입은 맞지만 의미 불일치
  2. Partial Data Load: API 레이트 리밋으로 정확히 10,000행이나 2^16행에서 묵묵히 중단 — 라운드 넘버 의심
  3. Stale Data: 외부 파트너 자동화 실패로 신규 데이터 없이 파이프라인 “성공” — freshness 체크 필수
  4. Late-Arriving Dimensions: Enum 기반 범주형 데이터에 새 값 추가 시 JOIN 실패 → NULL 전파
  5. Outdated Logic: 하드코딩된 고객 티어, 환율, 날짜 범위가 비즈니스 변화에 미적응

공통점: 파이프라인이 기술적으로 “정확히 지시한 대로” 실행하지만, 비즈니스 의미적으로는 틀린 결과를 생산한다.

연관 개념

Source: Pranav Mehta - Silent Data Loss in ClickHouse, ClickHouse Distributed Connection Pooling, The Data Canary - Netflix Catalog Validation, Pinterest - Piqama Pinterest Quota Management Ecosystem, KIP-848 Next Generation Consumer Rebalance Protocol, The 5 Silent Failures in Data Pipelines, SQLite in Production, ML Feature Pipeline That Got Slower at Whatnot

그래프 뷰

백링크