pile·
DB / 데이터·oliveyoung올리브영 테크블로그·

옴니채널 재고 정합성 한계에 대응하는 인벤토리 데이터 파이프라인 구축기

올리브영 인벤토리 스쿼드가 전국 1,400개 매장·1,200만 건 기초재고 생성 리드타임 증가, 동기식 파이프라인 병목, API 과부하 등 세 가지 구조적 한계를 Spring Batch Partitioning·Kafka Fan-Out·Push/Pull 분리로 해결한 아키텍처 전환 사례다.

핵심 포인트
  • 기초재고 생성 시간을 Spring Batch Partitioning으로 평균 2시간에서 25분으로 단축하고, 기존 약 2만 라인의 Oracle 프로시저도 제거했다.
  • 단일 동기 파이프라인을 Kafka Fan-Out으로 분리해 한 컨슈머 그룹의 지연이 다른 그룹에 전파되지 않게 했다.
  • 자체 데이터 스토어 보유 서비스는 Kafka 토픽 구독(PUSH), 결제 경로는 실시간 API(PULL)로 성격에 따라 분리했다.
  • PUSH 전환으로 특정 서비스의 API 호출을 약 90% 줄였다.
  • 최종적으로 단일 동기 구조에서 이벤트 기반 아키텍처(EDA)로 전환했다.
상세 정리
  • 시스템 개요: 오프라인 POS 데이터는 Kafka로, 내부 변동(입고·이동·반품·폐기)은 Oracle GoldenGate CDC로 수집. 매장재고·시계열재고·품절여부·증정품재고·재고이력 5가지 모델로 처리한다.
  • 한계 1 — 기초재고 리드타임: 매출 증가로 연산량이 늘면서 기초재고 생성이 평균 2시간까지 늘어 재고 부정합과 고객 경험 저하가 발생했다.
  • 한계 2 — 동기식 병목: 매장재고·시계열재고·품절여부가 단일 파이프라인에서 동기적으로 처리돼 하나의 지연이 전체로 전파됐다.
  • 한계 3 — API 과부하: 검색·전자라벨 같이 자체 스토어를 보유한 서비스가 주기적으로 전체 재고를 API로 조회해 과도한 Read 부하가 발생했다.
  • 해결 1 — Batch Partitioning: 매장 그룹을 파티션 키로 사용해 서브 Step을 병렬 실행. 기초재고 생성 2시간→25분(약 80% 단축), 기존 약 2만 라인 프로시저 제거. Amazon MWAA로 파이프라인 스케줄링 자동화.
  • 해결 2 — Kafka Fan-Out: 매장재고 우선 적재 후 변동 재고 토픽 발행. 품절여부·시계열재고·재고이력 등 컨슈머 그룹이 각자 독립적으로 구독. Kafka가 그룹별 오프셋을 따로 관리해 연쇄 지연 문제 해소.
  • 해결 3 — PUSH: 자체 데이터 스토어 보유 서비스는 변동 재고 또는 품절여부 토픽을 직접 구독해 자율 동기화. 특정 서비스 API 호출 약 90% 감소.
  • 해결 3 — PULL: 상품 상세·장바구니·주문서처럼 결제 결정 순간에 직결되는 서비스는 매장재고를 실시간 API로 제공. 매장재고만 적재하므로 지연이 낮고 안정성 유지.
  • 최종 효과: 단일 동기 구조에서 EDA로 전환해 각 서비스가 성격에 맞는 방식으로 재고를 소비하는 구조적 토대를 마련했다.
왜 읽나대규모 옴니채널 재고·주문 시스템에서 파이프라인 병목과 API 부하 문제에 직면한 백엔드·데이터 엔지니어, 특히 Kafka Fan-Out과 Push/Pull 분리 설계를 실제 적용한 사례가 필요한 팀에게 유용하다.
oliveyoung
올리브영 테크블로그 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5