피드로 돌아가기
Dev.toBackend
원문 읽기
Exactly-once 보장을 위한 Kafka Streams 제거 및 Idempotent Sink 기반 Redis Streams 전환
The Operators Regret: How We Blew Up the Event Bus at 3 AM
AI 요약
Context
Kafka → Kafka Streams → Redis 구조에서 RocksDB 상태 저장소의 GC Pause 및 처리 지연으로 인한 18%의 Event Loss 발생. Kafka 단독으로는 외부 저장소에 대한 Exactly-once Semantics 보장이 불가능한 아키텍처적 한계 직면.
Technical Solution
- Kafka Streams를 제거하고 Choreographed Saga 패턴 기반의 TreasureSink 서비스 도입
- 순차적 Sequence Number와 Redis Lua Script를 결합한 Idempotent Sink 설계로 중복 처리 및 데이터 유실 방지
- Redis Streams(XADD, XREADGROUP)를 통한 실시간 Delta 업데이트 방식으로 전체 리더보드 재구축 오버헤드 제거
- Redis Sorted Set(ZINCRBY)과 Lua Script를 활용한 원자적 증분 업데이트 및 메모리 캐싱 구조 구현
- Kafka Producer 설정에서 transactional.id를 제거하고 enable.idempotence=true 및 max.in.flight.requests.per.connection=1 설정을 통한 정밀한 전송 제어
실천 포인트
- 외부 시스템 쓰기가 포함된 파이프라인에서 Exactly-once가 필요한지, At-least-once와 Idempotency 조합으로 대체 가능한지 검토 - Kafka Producer 설정 시 idempotence 사용 시 max.in.flight.requests.per.connection 값을 1로 제한하여 순서 및 중복 제어 확인 - 상태 저장소로 RocksDB 등을 사용할 때 GC Pause가 전체 파이프라인의 Lag 및 데이터 유실로 이어지는 병목 지점인지 분석 - Redis 사용 시 복합 연산의 원자성 보장을 위해 MULTI/EXEC 또는 Lua Script 적용 고려