Read Original
#Backend

때로는 오버엔지니어링이 필요합니다

때로는 오버엔지니어링이 필요합니다
01

Summary

초당 1건도 안 되는데 Kafka 도입? 올리브영이 '오버엔지니어링'을 선택한 이유

사라질 과도기 시스템에 CDC와 메시지 큐를 때려 박아 레거시 마이그레이션을 안전하게 완수한 아키텍처 엔지니어링 스토리

이 아티클은 올리브영 메시지 발송 시스템의 레거시 데몬을 걷어내며 겪은 점진적 아키텍처 마이그레이션 과정을 다룹니다. 발송량이 적음에도 불구하고 왜 복잡한 CDC와 Kafka 파이프라인을 구축했는지, 그리고 이 '의도된 오버엔지니어링'이 어떻게 전환 위험을 제로로 만들었는지를 명쾌하게 설명합니다. 레거시 시스템을 중단 없이 안전하게 현대화하고 싶은 백엔드 엔지니어들에게 현실적이고 우아한 이정표를 제시합니다.

  • 01수십 개 레거시 서비스를 한 줄도 고치지 않고 시스템을 전환하는 교살자 무화과나무(Strangler Fig) 패턴 적용
  • 02DB 부하를 최소화하면서 실시간으로 발송 테이블의 INSERT 이벤트를 감지하는 CDC 파이프라인 구축
  • 03중복 발송을 원천 차단하기 위해 Kafka 컨슈머 그룹의 배타적 파티션 할당 구조 적극 활용
  • 04데이터 정합성 유지를 위해 큐에는 식별자만 실어 보내는 클레임 체크(Claim Check) 패턴 도입
  • 05설정 테이블 기반의 기능 플래그(Feature Flag)를 활용하여 무중단 및 즉시 롤백이 가능한 배포 프로세스 설계

RECOMMENDATION

빅뱅 방식의 전면 개편이 두려운 대규모 레거시 마이그레이션을 준비 중인 엔지니어에게 강력히 추천합니다. 과도기 아키텍처 구축의 필요성과 타당성을 비즈니스 안정성 관점에서 설득하는 훌륭한 논리적 근거를 배울 수 있습니다.

The Problem

올리브영의 기존 메시지 발송 시스템은 WAS와 격리되지 않은 레거시 데몬 프로세스 기반으로 작동하여 성능 간섭, 모니터링 부재, 동시 기동 시 중복 발송 위험 등 많은 기술 부채를 안고 있었습니다. 또한, 수십 개의 서비스가 발송 대상 DB 테이블에 직접 강하게 결합되어 있어, 이를 한 번에 최신 API 구조로 일괄 전환하는 것은 누락의 위험이 매우 컸습니다.

The Solution

수십 개의 레거시 서비스를 수정하지 않고 점진적으로 전환하기 위해 교살자 무화과나무(Strangler Fig) 패턴을 도입하고, CDC(Change Data Capture)와 Kafka를 구축하여 DB의 INSERT 이벤트를 가로채는 과도기 아키텍처를 설계했습니다. 큐에는 메시지 식별자만 담아 정합성을 보장하는 클레임 체크 패턴을 적용하고, 소비자 그룹과 기능 플래그(Feature Flag)를 활용하여 배포 안정성을 높였습니다.

The Result

평균 초당 1건 미만이지만 일시적으로 분당 수만 건씩 몰리는 트래픽 폭증을 큐가 성공적으로 완충하였으며, WAS 격리 및 표준 모니터링 구축을 통해 시스템 관측성을 확보했습니다. 또한 사람이 직접 수동으로 지키던 중복 발송 방지 규칙을 컨슈머 그룹을 통해 시스템 구조적 제약으로 완벽히 보장하게 되었습니다.

Trade-off

나중에 완전히 걷어낼 과도기 아키텍처를 위해 CDC, Kafka 등의 무거운 인프라를 도입하는 복잡성 비용을 지불해야 했습니다. 또한 큐 전체의 지연을 막기 위해 큐 수준의 재시도 메커니즘을 포기하고 외부 API 단발성 재시도만 허용함에 따라, DB 연결 장애 시 일부 실패 이력이 유실되어 로그 분석을 통한 사후 복구에 의존해야 하는 한계가 존재합니다.

03

Key Concepts

Concept · 01

Strangler Fig Pattern (교살자 무화과나무 패턴)

오래된 레거시 시스템을 한 번에 바꾸는 대신, 주변에 새로운 현대식 서비스를 조금씩 추가하며 구버전을 서서히 감싸 대체해 나가는 점진적 마이그레이션 아키텍처 디자인 패턴입니다. 숙주 나무를 타고 자라나 결국 독립하는 무화과나무의 생태에서 유래했습니다.

  • 수십 개의 레거시 서비스가 발송 테이블을 직접 호출하는 구조를 유지한 채 뒷단만 무중단으로 신규 시스템으로 교체하는 데 활용되었습니다.
Concept · 02

CDC (Change Data Capture)

데이터베이스에 발생하는 생성(Insert), 수정(Update), 삭제(Delete) 등 데이터 변경 정보를 실시간으로 감지하여 다른 시스템이나 데이터 저장소로 전송하는 기술입니다. 주기적인 데이터베이스 조회가 필요 없어 소스 DB에 부하를 거의 주지 않습니다.

  • 레거시 서비스가 발송 대상 테이블에 메시지 정보를 넣을 때(INSERT) 이를 실시간으로 가로채는 이벤트 인터셉션 도구로 사용되었습니다.
Concept · 03

Claim Check Pattern (클레임 체크 패턴)

대용량 메시지를 메시지 큐에 직접 올리는 대신, 메시지의 실제 데이터는 별도의 데이터베이스나 저장소에 저장하고 메시지 큐에는 해당 데이터를 조회할 수 있는 고유 식별자(ID)만 가볍게 실어 보내는 디자인 패턴입니다.

  • Kafka 큐에는 메시지의 전체 본문 대신 DB의 고유 ID만 실어 보낸 뒤, 워커에서 DB 원본 데이터를 재조회하여 데이터 정합성 어긋남을 원천 차단했습니다.