주문 검색 개선 배경
NHN 커머스 발표자가 샵바이 주문 검색 개선기를 소개한다. 왜 검색엔진을 도입했는지, 도입 과정, 도입 후 결과라는 세 흐름을 예고하며, 기존 RDB 기반 주문 검색이 잘 돌아가다가 문제를 겪게 된 상황으로 이야기를 연다.
한 달치 조회에 20초씩 걸릴 만큼 검색이 느려진 근본 원인이 데이터량 증가임을 밝힌다. 인덱스는 이미 잘 적용돼 있었지만 결과 데이터가 너무 많아 나머지 조건과 정렬 처리가 느려졌고, 주문 데이터 구조가 복잡해 쿼리 튜닝에도 한계가 있어 검색엔진 도입을 결정한다.
오픈소스 검색엔진 Elasticsearch·Solr·Sphinx 셋을 비교한다. 실시간성이 중요한 주문 데이터 특성상 인덱싱 성능이 낮은 Solr를 먼저 제외하고, 빠르지만 자료가 부족한 Sphinx도 유지보수 우려로 제외한 뒤, 준실시간 인덱싱과 풍부한 자료를 갖춘 Elasticsearch를 최종 선택한다.
구두·후드티·바지를 사는 예제로 주문 데이터의 복잡한 관계를 설명한다. 상품 하나에 여러 옵션, 주문 하나에 여러 상품, 배송 하나에 여러 옵션이 묶일 수 있는 다층 1:N 구조를 보여주고, 이를 주문-상품-옵션-배송 테이블의 일대다 관계로 설계했음을 정리한다.
공식 문서의 모델링 방식 중 네스티드와 비정규화를 비교한다. 네스티드는 JPA 엔티티처럼 직관적이나 중첩이 많아 도큐먼트가 폭증하고 쿼리가 복잡해지고, 비정규화는 옵션 단위 평탄 저장이라 페이징·카운팅이 어렵다. 두 방식의 장점만 섞어 쓰기로 결정한다.
DB 데이터를 Elasticsearch로 누락 없이 옮기는 동기화 전략을 다룬다. 처음엔 카프카 커넥트로 파이프라인을 구성했으나 운영·문서·커스터마이징의 어려움으로 포기하고, 5초 주기로 변경분을 조회해 동기화하는 자체 스케줄러를 6초 범위 중복 조회 방식으로 구현한다.
긴 트랜잭션이 아직 커밋되지 않아 스케줄러가 변경 데이터를 못 읽는 누락 문제를 분석한다. 조회 시 격리수준을 Read Uncommitted로 바꿔 커밋 전 데이터까지 확인하고, 그중 가장 빠른 수정 시간을 다음 동기화 시작 시각으로 설정해 누락을 방지한다. 수동 동기화·검증 배치도 별도로 둔다.
천만 건 대상 결과를 공유한다. 3일치 2초→0.4초(약 5배), 일주일치 5초→0.4초(약 15배), 한 달치 20초→0.4초(약 52배), 3달치는 타임아웃→0.4초로 개선됐다. 개발자 2명이 6개월간 업무와 병행한 가성비 좋은 프로젝트였다며 Elasticsearch 활용을 권한다.