pile·
백엔드·oliveyoung올리브영 테크블로그·

올리브영 온라인몰의 전시, 그리고 백엔드 여정

문제모놀리식 구조의 온라인몰 홈은 올영세일 같은 대규모 트래픽에서 스케일아웃이 어렵고, 컴포넌트 하나가 느려지면 홈 전체가 느려졌으며, 작은 변경에도 영향 분석·통합 테스트에 몇 달이 걸렸다.
접근홈을 모두에게 동일한 정적 데이터 API와 유저별 개인 데이터 API로 쪼개 MSA로 전환했다. Redis·MongoDB·Oracle을 혼합해 캐싱과 버전 검증을 하고, WebClient zip/parallel로 다중 호출을 묶었으며, 2~3단 폴백을 가진 서킷 브레이커로 장애를 격리했다. 사용자 9%만 홈 하단까지 스크롤한다는 데이터를 근거로 초기 페이로드를 300KB의 3% 수준까지 줄였다.
결과6월 대비 9월 평균 응답 ~10,400ms→~92ms, 피크 ~33,550ms→~60ms로 99% 이상 개선됐다. 부하·성능·스트레스 테스트와 서킷 브레이커 상태 변경 Slack 알림 체계까지 함께 갖췄다.
oliveyoung
올리브영 테크블로그 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 백엔드·github-engGitHub Engineering·

    조기 종료를 없애야 벡터화된다 — 메모리 속도 소스 코드 케이스 폴딩

    GitHub의 코드 검색 엔진 Blackbird는 480TB 이상의 소스 코드를 인덱싱하기 전 모든 바이트에 case folding을 적용한다. 이 글은 Rust로 구현한 case folding을 메모리 대역폭 한계(45+ GiB/s)까지 끌어올린 두 가지 반직관적 최적화를 상세히 다룬다. 핵심은 루프 조기 종료(break) 제거로 LLVM 벡터화를 유도하고, UTF-8을 디코딩하지 않고 바이트 공간 산술만으로 fold를 수행하는 것이다.

    #rust#unicode#simd+2
  2. 백엔드·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    트랜잭션 스크립트에서 숙소 메타 + 가격 계산 모듈로 — 전시 아키텍처 개선기 (2/3)

    여기어때 전시개발팀이 숙소 상세(PDP) API를 해부한 결과, 코드상으로는 DB 호출 3번처럼 보이던 요청이 실제로는 MongoDB $lookup 체인으로 컬렉션을 19회 접근하는 구조였다. 이 트랜잭션 스크립트 방식의 핵심 문제는 "aggregation이 I/O를 가린다"는 점으로, 독립적인 쿼리 10개가 단일 파이프라인에 직렬화되어 병렬화 기회를 잃고, 가격 때문에 거의 안 바뀌는 이미지까지 매 요청마다 읽어야 하는 읽기 증폭이 발생했다. V3에서는 "조회 시점 조립"을 "쓰기 시점 사전 조립"으로 전환하고, 화면별로 복제되던 가격 계산 로직을 goodsprice 단일 모듈로 수렴했다. 4개 API(PLP/PDP/RDP/ILP)의 반복 마이그레이션은 Claude Code skill로 절차를 고정하고 쉐도잉 + 동일성 검증으로 안전망을 마련하는 방식으로 진행됐다.

    #architecture#migration#caching+2