[NHN FORWARD 22] 엘라스틱서치를 이용한 상품 검색 엔진 개발 일지

MSSQL DB의 상품 데이터를 Elasticsearch로 밀어 넣어 검색되게 하는 구조로, 검색 API를 제공하는 서치 서버, 스프링 스케줄러로 10초마다 도는 인덱싱 서버, 쿠버네티스 크론잡으로 매일 새벽 2시 도는 배치 서버 세 종류를 띄운다. 오른쪽에는 Elasticsearch·Kibana·Beats 세 기술로 검색엔진을 운영한다.

색인은 원본 문서를 검색어 토큰으로 변환하는 과정으로, 책 뒤 찾아보기(색인 페이지)에 비유된다. 매일 한 번 모든 상품을 넣는 전체 색인과 10초마다 수정 상품만 재색인하는 부분 색인으로 나눴는데, 이유는 데이터 정합성이다. 전체 색인과 부분 색인이 동시에 진행되면 정합성이 깨지므로 둘은 절대 겹치지 않도록 제어한다.

전체 색인은 상품 데이터를 CSV로 만들어 오브젝트 스토리지에 올린 뒤 배치가 다운로드·파싱해 Elasticsearch로 넣으며, Redis 락으로 부분 색인과 충돌을 막는다. 항상 새 인덱스를 만들고 기존 인덱스는 백업으로 남기는데, alias API의 멀티플 액션으로 별칭을 무중단 교체해 언제든 롤백 가능한 구조를 만들었다.

부분 색인은 이미 색인된 데이터를 최신화하는 과정으로, 상품 수정 시 Kafka의 product-update 토픽을 발행하고 컨슈머가 동기화해 인덱싱 서버로 전달한다. 장애 대비로 1차는 MongoDB에 update/delete 액션 구조로 저장한 뒤 10초 스케줄러가 Redis 락을 확인하고 Elasticsearch로 bulk API 재색인한다. 300만+ 상품 전체 색인은 5000건 순차 벌크로 약 50분~1시간 걸렸다.

만족스러운 검색 품질을 위해 nori 토크나이저로 형태소 분석을 적용해 '남성 운동화'를 올바르게 토큰화하고, '운동화'가 운동복·운동기구까지 끌어오는 문제는 사용자 사전 등록으로 막았다. 또 '신발=러닝화·스니커즈' 같은 동의어 사전을 도입하고, 사전 파일은 NHN 클라우드 스토리지 업로드 시 전 노드에 자동 배포·반영되도록 자동화했다.

여러 필드를 하나로 합치는 copy_to, 분석된 단어가 모두 일치해야 검색되는 minimum_should_match, 그리고 형태소 분석을 거치는 match와 원문 그대로 매칭하는 term 쿼리를 병행해 정확도와 다양성을 함께 높였다. 성능 개선에선 샤드가 작을수록·서치 스레드가 많을수록·노드 스펙이 좋을수록 빨라진다는 가정을 세우고, 데이터 5GB 규모에 맞춰 노드별 샤드 1개를 유지했다.

부하 테스트에서 8코어·8GB 노드의 CPU 로드가 100%까지 치솟자 16코어·16GB로 스케일업해 레이턴시를 해결했다. 마지막으로 샵바이 서버와 검색엔진 서버 사이에 nginx 웹캐시 서버를 두어 캐시 히트 시 응답을 1.1~1.5초에서 0.2~0.7초로 단축했다. 모든 방안을 적용해 100~200 TPS·1.2초에서 400~500 TPS·0.7초 이하로 개선했다.