45분 배치에서 준실시간으로: 다수 도메인 데이터를 Kafka로 통합한 전환기

상품카드에 노출되는 혜택 플래그는 상품, 쿠폰, 증정, 프로모션 등 서로 다른 도메인의 데이터를 한 화면에서 조합해야 했다. 기존에는 10년 넘게 쌓인 프로시저가 이 로직을 떠안고 있었고, 변경이 반영되기까지 최대 45분이 걸리며 강결합과 검증 어려움, 대량 재계산 문제가 함께 누적돼 있었다.

도메인별 데이터 성격도 제각각이었다. 일부는 이미 Kafka 기반 이벤트로 받을 수 있었지만, 쿠폰이나 증정 프로모션처럼 협의가 필요한 필드도 있었고, 모든 데이터를 무조건 실시간으로 바꾸는 방식도 맞지 않았다. 그래서 실시간 전환이 가능한 영역과 배치 발행이 필요한 영역을 나누는 하이브리드 아키텍처를 택했다.

핵심은 배치와 스트리밍이 같은 테이블을 동시에 갱신할 수 있다는 점이었다. 단순한 플래그 폴링은 다중 인스턴스 환경에서 한계가 있어, 배치 시작과 종료 신호를 Redis Pub/Sub으로 브로드캐스트하고, 실제 처리 완료 상태는 별도 플래그로 확인하는 구조를 만들었다. 다만 Pub/Sub은 메시지 유실 가능성이 있으므로, 모든 Task의 중단 여부를 주기적으로 재확인해 안전하지 않으면 배치를 중단하도록 설계했다.

도메인 간 처리 순서 의존성은 Aggregation Topic으로 풀었다.

• 각 토픽의 메시지를 바로 처리하지 않고 하나의 토픽으로 모아 순서를 조율
• 상품ID를 파티셔닝 키로 사용해 같은 상품 이벤트는 같은 파티션으로 라우팅
• 상품 Row가 없을 때 먼저 도착한 쿠폰·행사 메시지는 건너뛰되, 처리 시점에 API로 최신 정보를 조회해 적재

중복 전달과 재시도에 대비한 멱등성(Idempotency) 도 준비했다. 메시지를 배치로 받은 뒤 중복 제거와 최신 발행 타임스탬프 필터링을 거치고, 최종 반영은 UPSERT로 처리해 중복이 남아도 정합성이 깨지지 않도록 했다.

전환 직전에는 Shadow Table로 기존 프로시저 결과와 새 파이프라인 결과를 항목 단위로 비교했다. 약 3주간 병행 운영하며, 특히 올영세일 같은 대규모 트래픽 구간에서도 안정성을 검증한 뒤 실제 테이블로 전환했다. 롤백 시나리오도 미리 정리해 문제가 생기면 즉시 구 구조로 복귀할 수 있게 했다.

전환 이후 혜택 플래그 반영 지연은 수 초 이내로 줄었고, 도메인별 모니터링도 가능해졌다. 성능 지표도 크게 개선돼 buffer_gets는 111.38M → 3.07M으로 97.2% 감소, disk_reads는 약 120K → 8.48K로 93% 감소했다. 더 이상 전시 시스템이 모든 로직을 직접 계산하지 않고, 각 도메인의 최신 정책이 반영된 결과를 받아 조합하는 구조로 바뀐 셈이다.