검색 요구 사항을 위한 Elasticsearch 인덱스 & Query DSL 설계기

사내 실습으로 검색 기능 요구사항을 반영해 Elasticsearch의 인덱스 설정과 매핑을 정의하고, 검색을 위한 Query DSL(JSON 기반 쿼리 언어, Not OpenFeign QueryDSL)을 작성하면서 고민했던 점들을 정리한 글입니다.

 

개발 환경

 

• VirtualBox (Rocky Linux)
• Elasticsearch 7.10.2
• 하나의 클러스터에 노드 3개 구성

 

API 요청/응답 도구

• Kibana / Postman

1. 명사구가 일치하는 경우 검색이 더 잘되게 해주세요.

이를 위해 mulit_match 의 phrase 타입을 활용했다. multi_match는 type에 따라 쿼리 실행 방법이 달라진다.

 

multi_match 쿼리의 type별 동작

- best_fields (기본값)

여러 필드 중 하나에서 검색어가 가장 잘 매치되는 경우 해당 필드의 점수만 최종 _score로 사용된다.
예를 들어, title, summary, contents가 검색 대상일 때, 검색어가 title에서 가장 잘 매치되면 title 필드의 점수만 반영된다.

즉, "제목에 포함되어 있다면 가장 찾기 쉬운 문서"란 요구사항에 제목에 가중치를 두어 쉽게 구현이 가능하다.

{
  "query": {
    "multi_match": {
      "query": "정기회동",
      "type": "best_fields",
      "fields": ["title^5", "summary^2", "contents"]
    }
  }
}

 

참고, best_fields와 bool.should 쿼리와의 차이점

bool.should로 동일한 쿼리를 구성하면, 세 필드에서의 매칭 점수를 모두 더한 _score가 계산된다. multi_match의 best_fields는 가장 잘 매치된 단일 필드의 점수만 반영되는 반면, bool.should는 모든 필드 점수를 합산한다는 차이가 있다.

"query": {
  "bool": {
    "should": [
      { "match": { "title": "정기회동" }},
      { "match": { "summary": "정기회동" }},
      { "match": { "contents": "정기회동" }}
    ]
  }
}

 

- phrase 타입

multi_match에서 type: "phrase"를 사용하면 아래 내용처럼 match_phrase 쿼리가 실행된다. 이는 명사구가 순서대로 일치하는 경우에 적합하다.

The phrase and phrase_prefix types behave just like best_fields, but they use a match_phrase or match_phrase_prefix query instead of a match query.

 

첫 번째 multi_match는 정확한 명사구 일치에 가중치를 주고, 두 번째 multi_match 는 정확한 명사구 일치가 없을 경우 검색이 되기 위한 쿼리로 생각하며 만들었다.

{
  "query": {
    "bool": {
      "should": [
        {
          "multi_match": {
            "query": "국민의힘 청년최고위원 김재원",
            "type": "phrase", 
            "fields": ["title^10", "writer^10", "contents^2"]
          }
        },
        {
          "multi_match": {
            "query": "국민의힘 청년최고위원 김재원",
            "fields": ["title^5", "writer^5", "contents"]
          }
        }
      ]
    }
  },

 

2. unique filter 사용 시 주의점

뉴스 작성자를 기준으로 뉴스를 검색하고 싶다. 작성자 필드에는 "정아란 기자, 박하얀 기자" 또는 "정아란 기자"처럼 값이 들어온다.

처음에는 nori_tokenizer를 생각했지만 nori_tokenizer는 "정아란 기자"를 "정아" + "란"으로 토큰화하기 때문에, 공백 기준으로 텀을 나누고 일부 특수문자를 제거하는 standard tokenizer를 사용해 "정아란", "기자", "박하얀", "기자"와 같은 텀을 생성하도록 했다.

 

이 과정에서 "기자"가 중복되기 때문에 unique filter를 적용하면 "기자" 텀이 하나만 남는다. 처음엔 이 방식이 더 효율적이라고 생각했다.

하지만 문제는 unique filter가 term의 위치 정보(position)를 유지하지 않는다는 점이다. 그래서 "정아란 기자" 또는 "박하얀 기자"와 같이 명사구 전체를 대상으로 match_phrase 검색을 할 경우, 명사구가 일치하는 검색 결과가 나오지 않게 된다.

 

따라서 unique filter는 match_phrase 검색이 필요 없는 필드에 적용하는 것이 적절하다고 판단이 되며, unique filter 는 사용하지 않게 되었다.

 

3. 제목 필드에 검색어가 포함된 경우 가중치 부여

제목(title)에 검색어가 포함되었을 때 더 높은 점수를 주기 위해, 두 가지 방법을 생각했다.

 

1. Mappings에서 boost 설정하기

"mappings": {
  "properties": {
    "title": {
      "type": "text",
      "boost": 10
    }
  }
}

 

2. Query DSL 에서 필드별 가중치 부여하기

# 단일 필드 검색 시
"match": {
    "title": { 
        "query": "...", 
        "boost": 10 
    }
}

# 여러 필드를 동시에 검색할 떄
"multi_match": {
    "query": "국민의힘 청년최고위원",
    "type": "phrase", 
    "fields": ["title^10", "writer^10", "contents^2"]
}

 

나는 Query DSL에서 가중치를 부여하는 방식을 선택했다.
그 이유는 mappings이나 settings는 한 번 정의되면 재색인(reindex) 없이는 수정할 수 없기 때문이다. (필드 추가는 제외)

 

reindex는 기존 인덱스의 문서를 새 인덱스로 다시 색인하는 작업이다.
따라서 title 필드의 가중치를 10에서 20으로 바꾸려는 새로운 요구사항이 생겼을 때, 기존 mappings에 boost 값을 설정해뒀다면 유연하게 대응할 수 없기 때문이다.

 

4. 검색 필드인 '제목'을 기준으로 정렬해 주세요.

제목은 검색 대상이자 정렬 기준이 되어야 했기 때문에, multi-fields를 사용해 해결했다.

 

먼저, 검색 대상인 제목을 색인하기 위해서 제목 필드를 mappings 에 애널라이저와 text 타입을 정의하게 된다.

 "mappings": {
    "properties": {
      ...
      "title": {  
        "type": "text",
        "analyzer": "korean_basic_analyzer" // custom 애널라이저
      }
}

 

하지만 text 타입은 정렬이 불가능하다.
그 이유는 색인 시 애널라이저를 통해 텍스트가 토큰화되고, 결과적으로 역색인 구조로 저장되기 때문이다.
예를 들어 "라면"이 포함된 문서가 1, 2, 3번일 경우, 세 문서 모두 "라면"이라는 텀을 갖고 있어 어떤 기준으로 정렬할지 알 수 없다. 이 경우 Elasticsearch는 _score 기준으로만 정렬하게 된다.

 

이를 해결하기 위해 title 필드를 멀티 필드로 설정해 keyword 타입을 추가했다. keyword는 토큰화를 하지 않기 때문에 정렬 기준으로 사용할 수 있다. keyword 타입의 필드는 애널라이저 대신 노멀라이저를 사용하며, 노멀라이저는 토크나이저가 없기 때문이다.

 

이렇게 title 을 title.text 와 title.keyword 로 multi_fields를 둔다면 이 두 필드는 완전히 별개로 동작하게 된다. 

 "mappings": {
    "properties": {
      ...
      "title": {  
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        },
        "analyzer": "korean_basic_analyzer" // custom 애널라이저
      }
}

 

그리고, Query DSL 작성 시, sort에 title.keyword 필드를 추가하면 된다.

 "sort": [
    { "title.keyword": "asc" }
  ]

 

그러나, 이렇게 필드가 검색 대상이면서, keyword 를 활용해 정렬하면 score 기반이 무시되어 문서 검색 정확도가 떨어지게 된다.

그래서, 정렬이 필요하다면 검색 대상으로 정렬하기 보다는 토큰화 되지 않는 필드를 기준으로 정렬하는 요구사항으로 변경하면 좋을 듯 하다.

 

추가로 공식문서에서 멀티 필드는 같은 필드를 여러 애널라이저를 활용해 검색 정확도를 높이는데도 사용된다고 한다.

* Multi-fields with multiple analyzers 

 

5. 검색 대상이 아닌 필드는 애널라이저 대신 노멀라이저 사용

애널라이저는 0~3개의 Character Filter, 1개의 Tokenizer, 0~n개의 Token Filter 로 구성된다.

하지만, 노멀라이저는 Tokenizer를 적용할 수 없다. 다시 말해 검색 대상이 아닌 필드는 노멀라이저를 사용할 수 있다.

 

예를 들어, 노멀라이저는 "우리의 목표는 행복하기 입니다." 를 저장할 때, "우리" "목표" "행복" 이렇게 토큰화하지 않고, " 우리의 목표는 행복하기 입니다. " 이 문장 자체로 저장을 한다. 그래서, 정확히 일치하는 term쿼리에서 사용할 수 있고, keyword 타입 사용 시, 노멀라이저를 활용하게 된다.

 

6. 인덱스 설정 시, dynamic: false 사용 안하기

Elasticsearch는 문서를 색인할 때, 인덱스에 정의되지 않은 필드가 있으면 자동으로 필드의 타입을 추론해서 필드를 추가한다.

하지만, Elasticsearch 도 필드의 타입을 지정하는 것이 좋다. 자료형이 적은(자료형에 알맞는) 타입을 사용하면 검색/색인 시 성능이 좋아진다.(16비트로 표현할 수 있는 값이면 integer 보다는 short 로 지정하는 것이 좋다는 의미)

다만, 저장할 때는 실제 값에 맞춰 최적화 되어 디스크 사용량에서의 이득은 없다고 한다.(출처. 엘라스틱 바이블)

아무튼, mappings 설정에 dynamic: false를 지정하면 타입이 정의되지 않은 필드는 타입을 추론하지 않고 색인되지 않게 할 수 있다. 

하지만, dynamic: false 는 새로운 필드를 추가하는 것 또한 불가능하게 만든다. 즉, "나중에 특정 필드를 추가하고 싶어요" 란 요구사항에 대응하기 어렵게 된다.

 

따라서 불필요한 필드 생성을 방지하기 위해 dynamic: false를 사용하는 대신, 문서 전처리 과정에서 필요없는 필드를 정제해주는 것이 더 나은 방식이라고 생각한다.

 

7. 기타

- 날짜 필드는 format 옵션을 명시해서 처리

- 집계(aggregation)를 위해 aggs 사용

- text 타입은 집계가 불가능하므로, 집계를 위해 multi-fields로 keyword 타입을 병행 사용

- 검색 결과 강조를 위해 highlight 사용

 

 

마치며

이번 작업을 하며 부족했던 점도 있었다.
예를 들어, 클러스터 1개에 노드 3개를 구성했을 때, 인덱스를 몇 개의 샤드로 분산시킬지 기준을 명확히 세우지 못했다.

• number_of_shards : 해당 인덱스를 몇 개의 샤드로 쪼갤건지 설정 값이다.
  
  • 샤드 수가 너무 많으면 문서 색인 성능이 감소하고, 샤드 수가 너무 작으면 한 샤드의 크기가 커서 장애로 인한 샤드 복구 시 오래 걸림 / 클러스터 안정성이 떨어진다.
• numbers_of_replicas : 주 샤드 하나당 복제본 샤드 몇 개 만들지를 설정한다.

이 두 설정은 클러스터 운영 시 정말 필요한 설정이기 때문에 꼭 추후에 학습하고자 한다.

 

이러한 실습을 진행하면서 공식문서나 책에 모르는 지식이 많다보니 자세히 알고 싶은 마음에 필요한 부분 외에도 자꾸 읽게 되었다. 그러나, 이해하며 읽더라도 머리속에서 빠르게 휘발되는 것또한 경험했다.

그래서 점점 느끼는 건, 새로운 기술을 배울 때에는 필요한 것을 위주로 삽질을 해야 머리에 오래 남는것을 느꼈다. 새로운 기술을 배울 때에는 필요한 부분부터 차근차근 배우고, 절대적인 시간도 필요하다는 것을 생각하며 조바심 내지 않는 것도 중요한 것 같다.