검색 엔진을 넣을지 지연으로 먼저 재 봤다: 지연 축은 답했고 품질 축은 남았다
상품 목록 페이지 지연의 82.5%가 패싯 집계였다. 검색 엔진 도입 기준을 측정 전에 정해 두고 쟀더니 300ms를 넘긴 원인은 집계가 아니라 포화였고 패싯을 60초 캐시하자 패싯 p95가 90.9ms에서 5.7ms로 줄어 엔진을 검토할 조건이 사라졌다. 그런데 이커머스가 검색 엔진을 들이는 큰 이유는 지연이 아니라 품질이고 그 축은 아직 재지 않았다.
검색 품질을 쟀더니 MySQL 이 따라오지 못했다: Lucene, Elasticsearch, OpenSearch 중 앱 안 Lucene 을 고른 이유
오타와 어형 변화가 섞인 검색어에서 nDCG@10이 지금 검색(LIKE) 0.071, MySQL FULLTEXT 0.324, Lucene 0.808, Elasticsearch 0.814, OpenSearch 0.798이었다. 측정 전에 정한 기준대로 엔진을 넣었고 세 엔진의 품질 차이가 0.02 안이라 운영 비용으로 앱 안 Lucene을 골랐다. 1차에서는 오타 허용이 blazer를 lazer에 밀리게 했다.
검색어와 필터를 함께 걸고 앱 안 Lucene이 몇 건까지 버티는지 쟀다
검색어가 있으면 카테고리·가격·재고 필터가 모두 무시되던 검색에 필터와 패싯을 붙였다. 엔진 안에서 걸면 결과 수가 정답과 171개 쿼리 모두 같았고 상위 500개를 받아 DB에서 거르면 95.5%를 잃었다. 복제 카탈로그로 규모를 늘리자 앱 안 Lucene은 300만 건에서 p95 232ms로 지연 예산을 넘었다.