11번가 프레젠테이션 서비스 팀이 외부 Oracle DB에 의존하던 딜(기획행사) 정보 관리를 MongoDB 기반 내재화 시스템으로 전환한 프로젝트 회고다. Kafka ZeroPayload 패턴, 멀티스레드 처리, 기능 플래그 기반 롤백, 이중 검증 체계까지 실전 전환 과정의 함정과 해결책을 상세히 공유한다.
핵심 포인트- Oracle PL/SQL 프로시저 → MongoDB + Kafka 파이프라인으로 전환해 API 호출당 이중 DB 풀 연결 소비 제거
- Kafka ZeroPayload 패턴(키만 전송)과 딜 중요도별 토픽 분리로 메시지 처리 효율화 및 우선순위 역전 방지
- 기능 플래그(Feature Flag)로 Oracle ↔ MongoDB 즉각 전환, 재배포 없이 4개 롤백 지점 → 단일 스테이지로 단순화
- 임베디드 문서 동기화 문제: 딜 내 상품 정보 중복 저장 → 참조 정규화로 전환해 상품 변경 시 불일치 해소
- 이중 검증 체계: MongoDB vs Oracle 데이터 비교 + API 응답 비교, ELK 스택으로 중앙화된 검증 대시보드
상세 정리- 기존 구조: MongoDB(상품) + OracleDB(딜) 이중 조회 후 API에서 합산, 커넥션 풀 2배 소비
- 전환 이유: 1) API 호출당 Oracle/MongoDB 두 커넥션 풀 소비 2) 디버깅 시 두 시스템 동시 조사 3) 딜 로직 변경 시 Oracle 프로시저 수정 필요
- TO-BE 흐름: 원본 DB → Kafka 발행(ZeroPayload) → 컨슈머 처리 → MongoDB 저장 → API 조회
- 시간 민감 딜과 대용량 딜을 별도 배치로 분리해 갱신 속도 차별화
- 멀티스레드 추출(thread-pool=5)과 멀티스레드 컨슘(concurrency=3)으로 처리량 확대
- 쿼리 패턴에 최적화된 단일·복합 인덱스 설계로 응답 성능 확보
- 데이터 증가 함정: 16만 → 37만 레코드로 증가해 배치 주기가 1-2분에서 10분으로 저하 → 멀티스레드 + 토픽 분리로 해결
- 검증 함정: 저장 데이터만 검증했다가 로직 레이어 결함 미탐지 → API 응답 최종 비교로 보완
- 결과: Oracle 커넥션 병목 제거, API 레이턴시 감소, 단일 디버깅 표면(MongoDB만), Oracle 의존성·비용 제거
왜 읽나외부 레거시 DB(Oracle)를 내부 NoSQL(MongoDB)로 무중단 전환하면서 Kafka 파이프라인, 기능 플래그, 이중 검증을 엮어 실제로 겪은 함정과 해결책을 솔직하게 공유하는 실전 회고다.