pile·
DB / 데이터·티몬티몬·

ES플러그인 커스터마이징 (2)핫딜 검색순위 조절하기

티몬 ES 플러그인 커스터마이징 2부로, 검색어에 따라 인기 딜의 노출 순위를 동적으로 바꾸는 Script Sort 플러그인 개발을 다룬다. `AbstractLongSearchScript` 구현부터 모듈 등록, 실제 색인 후 정렬값 확인까지 네 단계로 이어진다.

핵심 포인트
  • 일반 전문 검색은 TF-IDF 기반 score 로 정렬하지만, 티몬은 요구사항을 맞추려고 자체 정렬 로직을 구현해 쓴다.
  • Lucene 쿼리식으로 특정 필드에 가중치를 주는 방법도 있지만, 여기서는 ES 의 Script Sort 로 구현한다.
  • 개발은 네 단계다. `AbstractLongSearchScript` 를 상속해 `runAsLong()` 구현 → `NativeScriptFactory` 의 `newScript()` 에서 그 객체 반환 → `AbstractPlugin` 으로 등록 → 설치.
  • 정렬 로직은 `weightSearchKeyword` 필드로 조정 대상 키워드인지 확인한 뒤, 맞으면 `weight` 값을 정렬 항목에 포함시키는 방식이다.
  • 검색 시점의 검색어는 ES 가 파라미터로 넘겨주는 Map 에서 플러그인 호출 시 지정한 key 로 꺼내 쓴다.
상세 정리
  • 배경: 소셜커머스는 이슈가 된 인기 딜의 노출 우선순위를 높이는 식으로 시장 현황과 트렌드를 반영한 검색 결과를 줘야 한다.
  • 반환 타입 선택: 정렬에 쓸 값의 자바 타입에 맞는 추상 클래스를 골라야 하며, 여기서는 Long 을 반환하므로 `org.elasticsearch.script.AbstractLongSearchScript` 를 쓴다.
  • `NativeScriptFactory` 구현체는 앞서 만든 클래스의 객체를 반환하기만 하면 되어 훨씬 간단하다.
  • 모듈 등록의 함정: `onModule()` 메서드에 `@Override` 가 없는데, ES Core 가 플러그인 등록 시 이 메서드를 **동적으로 호출**하기 때문이다.
  • 정석과 실제의 차이: 원래는 `AbstractPlugin` 의 추상 메서드 `processModule(Module)` 을 구현하는 것이 정석이지만, 그러면 전달받은 Module 타입을 `instanceof` 로 비교해 등록하는 번거로운 분기가 붙는다.
  • 그래서 등록할 타입을 직접 지정할 수 있는 `onModule` 정의 방식이 주로 쓰인다고 정리한다. 등록 대상 모듈에는 `ScriptModule` 외에 `RestModule` 등도 있다.
  • 검증 방법: 같은 title 을 갖되 `weightSearchKeyword` 에 서로 다른 키워드가 매칭된 문서 두 개를 색인한다.
  • 검색어를 바꿔 가며 조회해 응답의 `sort` 반환값이 달라지는 것으로, 검색 키워드에 매칭되는 문서에만 정렬용 값이 넘어가는 것을 확인한다.
  • 3부 예고로 자동 완성 등에 많이 쓰이는 한글 자모 분해 분석기를 ES 에 적용하는 방법을 다룬다고 밝힌다.
왜 읽나검색 결과 순위를 비즈니스 규칙대로 흔들어야 하는 개발자에게 Elasticsearch Script Sort 를 직접 구현하는 경로를 보여준다.
티몬
티몬 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (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