느린 Elasticsearch 쿼리 문제 해결: 식별 및 해결 단계

Elasticsearch는 강력한 분산 검색 및 분석 엔진이지만, 모든 복잡한 시스템과 마찬가지로 시간이 지남에 따라 성능이 저하되어 느린 쿼리와 사용자 불만으로 이어질 수 있습니다. 비효율적인 검색 지연 시간은 최적화되지 않은 쿼리 설계 및 인덱싱 전략부터 기본 클러스터 리소스 제한에 이르기까지 다양한 요인에서 비롯될 수 있습니다. 근본 원인을 식별하고 효과적인 해결책을 구현하는 방법을 이해하는 것은 응답성이 뛰어나고 고성능을 유지하는 Elasticsearch 클러스터에 매우 중요합니다.

이 종합 가이드는 느린 Elasticsearch 쿼리를 진단하는 과정을 안내합니다. 초기 확인 사항부터 시작하여 Elasticsearch의 강력한 Profile API를 사용하여 쿼리 실행 계획을 분석하는 심층적인 내용까지 다룰 것입니다. 마지막으로 성능 병목 현상의 일반적인 원인을 살펴보고 쿼리를 최적화하고 전반적인 검색 지연 시간을 개선하기 위한 실용적이고 실행 가능한 단계를 제공할 것입니다. 이 글을 마치면 Elasticsearch 클러스터가 번개처럼 빠른 검색 결과를 제공하도록 보장하는 강력한 도구를 갖게 될 것입니다.

Elasticsearch 쿼리 지연 시간 이해하기

문제 해결에 뛰어들기 전에 Elasticsearch에서 쿼리 성능에 영향을 미치는 주요 요소를 파악하는 것이 중요합니다.

데이터 볼륨 및 복잡성: 데이터의 양, 필드의 수, 문서의 복잡성이 검색 시간에 직접적인 영향을 미칠 수 있습니다.
쿼리 복잡성: 간단한 term 쿼리는 빠르지만, 많은 절, 집계 또는 script 쿼리가 포함된 복잡한 bool 쿼리는 리소스 집약적일 수 있습니다.
매핑 및 인덱싱 전략: 데이터가 인덱싱되는 방식(예: text 대 keyword 필드, fielddata 사용)은 쿼리 효율성에 큰 영향을 미칩니다.
클러스터 상태 및 리소스: 클러스터 노드의 CPU, 메모리, 디스크 I/O 및 네트워크 지연 시간은 매우 중요합니다. 상태가 좋지 않은 클러스터나 리소스가 제한된 노드는 필연적으로 느린 성능으로 이어집니다.
샤딩 및 복제: 샤드의 수와 크기, 그리고 노드 간 분산 방식은 병렬 처리 및 데이터 검색에 영향을 미칩니다.

느린 쿼리를 위한 초기 확인 사항

고급 프로파일링 도구를 사용하기 전에 항상 다음 기본 확인 사항부터 시작하십시오.

1. 클러스터 상태 모니터링

_cluster/health API를 사용하여 Elasticsearch 클러스터의 전반적인 상태를 확인하십시오. red 상태는 기본 샤드가 누락되었음을 나타내고, yellow는 일부 복제본 샤드가 할당되지 않았음을 의미합니다. 둘 다 쿼리 성능에 심각한 영향을 미칠 수 있습니다.

GET /_cluster/health

status: green을 찾으십시오.

2. 노드 리소스 확인

개별 노드의 리소스 사용량을 조사합니다. 높은 CPU 사용량, 낮은 사용 가능한 메모리(특히 힙), 또는 포화된 디스크 I/O는 병목 현상의 강력한 지표입니다.

GET /_cat/nodes?v
GET /_cat/thread_pool?v

cpu, load_1m, heap.percent, 및 disk.used_percent에 주의하십시오. 높은 search 스레드 풀 큐 크기도 과부하를 나타냅니다.

3. 느린 로그 분석

Elasticsearch는 정의된 임계값을 초과하는 쿼리를 기록할 수 있습니다. 이는 개별 요청을 깊이 파고들지 않고도 특정 느리게 실행되는 쿼리를 식별하는 훌륭한 첫 단계입니다.

느린 로그를 활성화하려면 각 데이터 노드의 config/elasticsearch.yml을 수정하거나(또는 동적 클러스터 설정을 사용) 다음을 수행하십시오.

index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.fetch.warn: 1s

그런 다음 Elasticsearch 로그에서 [WARN][index.search.slowlog]와 같은 항목을 모니터링합니다.

심층 분석: Profile API를 사용하여 병목 현상 식별

초기 확인 사항으로 문제가 해결되지 않거나 특정 쿼리가 느린 이유를 이해해야 할 때 Elasticsearch Profile API는 가장 강력한 도구입니다. 이는 쿼리가 저수준에서 어떻게 실행되는지에 대한 자세한 분석을 제공하며, 각 구성 요소에서 소비된 시간도 포함합니다.

Profile API란 무엇인가요?

Profile API는 검색 요청에 대한 전체 실행 계획을 반환하며, 각 쿼리 구성 요소(예: TermQuery, BooleanQuery, WildcardQuery) 및 수집 단계에 소요된 시간을 자세히 설명합니다. 이를 통해 쿼리의 어느 부분이 가장 많은 시간을 소비하는지 정확히 식별할 수 있습니다.

Profile API 사용 방법

기존 검색 요청 본문에 단순히 "profile": true를 추가하기만 하면 됩니다.

GET /your_index/_search?profile=true
{
  "query": {
    "bool": {
      "must": [
        { "match": { "title": "elasticsearch" } }
      ],
      "filter": [
        { "range": { "date": { "gte": "now-1y/y" } } }
      ]
    }
  },
  "size": 0, 
  "aggs": {
    "daily_sales": {
      "date_histogram": {
        "field": "timestamp",
        "fixed_interval": "1d"
      }
    }
  }
}

참고: Profile API는 오버헤드를 추가하므로 모든 요청에 프로덕션에서 사용하는 것이 아니라 특정 쿼리 디버깅에 사용하십시오.

Profile API 출력 해석

출력은 장황하지만 구조화되어 있습니다. profile 섹션 내에서 찾아야 할 주요 필드는 다음과 같습니다.

type: 실행 중인 Lucene 쿼리 또는 수집기의 유형(예: BooleanQuery, TermQuery, WildcardQuery, MinScoreCollector).
description: 구성 요소에 대한 사람이 읽을 수 있는 설명으로, 종종 작동 중인 필드와 값을 포함합니다.
time_in_nanos: 이 구성 요소와 그 하위 요소에 소요된 총 시간(나노초).
breakdown: 여러 단계(예: rewrite, build_scorer, next_doc, advance, score)에서 소요된 시간의 자세한 분석.

해석 예시: time_in_nanos가 높고 rewrite에서 상당한 부분이 소비되는 WildcardQuery 또는 RegexpQuery를 보는 경우, 쿼리 재작성(와일드카드 패턴 확장)이 매우 비싸며, 특히 높은 카디널리티 필드나 대용량 인덱스에서 그렇다는 것을 나타냅니다.

...
"profile": {
  "shards": [
    {
      "id": "_na_",
      "searches": [
        {
          "query": [
            {
              "type": "BooleanQuery",
              "description": "title:elasticsearch +date:[1577836800000 TO 1609459200000}",
              "time_in_nanos": 12345678,
              "breakdown": { ... },
              "children": [
                {
                  "type": "TermQuery",
                  "description": "title:elasticsearch",
                  "time_in_nanos": 123456,
                  "breakdown": { ... }
                },
                {
                  "type": "PointRangeQuery",
                  "description": "date:[1577836800000 TO 1609459200000}",
                  "time_in_nanos": 789012,
                  "breakdown": { ... }
                }
              ]
            }
          ],
          "aggregations": [
            {
              "type": "DateHistogramAggregator",
              "description": "date_histogram(field=timestamp,interval=1d)",
              "time_in_nanos": 9876543,
              "breakdown": { ... }
            }
          ]
        }
      ]
    }
  ]
}
...

이 단순화된 예시에서 DateHistogramAggregator가 불균형적으로 높은 time_in_nanos를 표시하는 경우, 집계가 병목 현상입니다.

느린 쿼리의 일반적인 원인 및 해결 전략

Profile API 결과 및 일반적인 클러스터 상태를 기반으로 일반적인 문제와 해결책은 다음과 같습니다.

1. 비효율적인 쿼리 설계

문제: 특정 쿼리 유형은 특히 대규모 데이터 세트에서 본질적으로 리소스 집약적입니다.

wildcard, prefix, regexp 쿼리: 이들은 많은 용어를 반복해야 하므로 매우 느릴 수 있습니다.
script 쿼리: 필터링이나 채점을 위해 모든 문서에서 스크립트를 실행하는 것은 매우 비용이 많이 듭니다.
깊은 페이징: 수만에서 수십만 개의 from 값을 사용하는 from 및 size.
너무 많은 should 절: 수백 또는 수천 개의 should 절이 있는 부울 쿼리는 매우 느려질 수 있습니다.

해결 단계:

text 필드에 wildcard / prefix / regexp 사용 피하기:
- 입력 시 검색에는 인덱싱 시점에 completion suggesters 또는 n-grams를 사용하십시오.
- 정확한 접두사에는 keyword 필드 또는 match_phrase_prefix를 사용하십시오.
script 쿼리 최소화: 로직을 수집 시점(예: 전용 필드 추가)으로 이동하거나 표준 쿼리/집계를 통해 처리할 수 있는지 재평가하십시오.
페이징 최적화: 깊은 페이징의 경우 from/size 대신 search_after 또는 scroll API를 사용하십시오.
should 쿼리 리팩토링: 유사한 절을 결합하거나 적절한 경우 클라이언트 측 필터링을 고려하십시오.

2. 누락되었거나 비효율적인 매핑

문제: 잘못된 필드 매핑은 Elasticsearch가 비용이 많이 드는 작업을 수행하도록 강제할 수 있습니다.

정확한 일치/정렬/집계에 사용되는 Text 필드: text 필드는 분석 및 토큰화되므로 정확한 일치가 비효율적입니다. 이를 정렬하거나 집계하려면 힙을 많이 사용하는 fielddata가 필요합니다.
과잉 인덱싱: 검색되거나 분석되지 않는 필드를 불필요하게 인덱싱하는 경우.

해결 단계:

정확한 일치, 정렬 및 집계를 위해 keyword 사용: 정확한 일치, 필터링, 정렬 또는 집계가 필요한 필드에는 keyword 필드 유형을 사용하십시오.
multi-fields 활용: 동일한 데이터를 다른 방식으로 인덱싱(예: 전문 검색을 위한 title.text 및 정확한 일치 및 집계를 위한 title.keyword).
사용하지 않는 필드에 대해 _source 또는 index 비활성화: 필드가 표시용으로만 사용되고 검색되지 않는 경우 index를 비활성화하는 것을 고려하십시오. 표시되거나 검색되지 않는 경우 _source 비활성화를 고려하십시오(주의해서 사용).

3. 샤딩 문제

문제: 부적절한 수 또는 크기의 샤드는 고르지 않은 부하 분산 또는 과도한 오버헤드로 이어질 수 있습니다.

너무 많은 작은 샤드: 각 샤드에는 오버헤드가 있습니다. 너무 많은 작은 샤드는 마스터 노드에 부하를 주고, 힙 사용량을 늘리고, 검색 요청 수를 늘려 검색 속도를 늦출 수 있습니다.
너무 적은 큰 샤드: 검색 중 병렬 처리를 제한하고 노드에 "핫스팟"을 생성할 수 있습니다.

해결 단계:

최적의 샤드 크기: 샤드 크기를 10GB에서 50GB 사이로 유지하는 것을 목표로 합니다. 시간 기반 인덱스(예: logs-YYYY.MM.DD)와 롤오버 인덱스를 사용하여 샤드 성장을 관리하십시오.
Reindex 및 shrink/split: _reindex, _split 또는 _shrink API를 사용하여 기존 인덱스의 샤드를 통합하거나 크기를 조정하십시오.
샤드 분포 모니터링: 샤드가 데이터 노드에 고르게 분산되어 있는지 확인하십시오.

4. 힙 및 JVM 설정

문제: 불충분한 JVM 힙 메모리 또는 최적이 아닌 가비지 수집(GC)으로 인해 빈번한 일시 중지 및 성능 저하가 발생할 수 있습니다.

해결 단계:

충분한 힙 할당: jvm.options에서 Xms 및 Xmx를 노드 물리적 RAM의 절반으로 설정하되, 포인터 압축으로 인해 32GB를 초과하지 않도록 하십시오.
JVM 가비지 컬렉션 모니터링: GET _nodes/stats/jvm?pretty 또는 전용 모니터링 도구를 사용하여 GC 시간을 확인하십시오. 빈번하거나 긴 GC 일시 중지는 힙 압력을 나타냅니다.

5. 디스크 I/O 및 네트워크 지연 시간

문제: 느린 스토리지 또는 네트워크 병목 현상이 쿼리 지연 시간의 근본 원인일 수 있습니다.

해결 단계:

빠른 스토리지 사용: Elasticsearch 데이터 노드에는 SSD가 강력히 권장됩니다. 고성능 사용 사례의 경우 NVMe SSD가 훨씬 더 좋습니다.
적절한 네트워크 대역폭 보장: 대규모 클러스터 또는 집약적으로 인덱싱/쿼리되는 환경의 경우 네트워크 처리량이 중요합니다.

6. Fielddata 사용

문제: 정렬 또는 집계를 위해 text 필드에서 fielddata를 사용하면 엄청난 양의 힙을 소비하고 OutOfMemoryError 예외가 발생할 수 있습니다.

해결 단계:

text 필드에 fielddata: true 사용 피하기: 이 설정은 이유가 있어 text 필드에 대해 기본적으로 비활성화되어 있습니다. 대신 정렬/집계를 위해 keyword 하위 필드를 생성하는 multi-fields를 사용하십시오.

쿼리 최적화를 위한 모범 사례

느린 쿼리를 선제적으로 방지하려면 다음을 수행하십시오.

query 컨텍스트보다 filter 컨텍스트 선호: 문서 점수를 매길 필요가 없는 경우(예: range, term, exists 쿼리의 경우) bool 쿼리의 filter 절에 배치하십시오. 필터는 캐시되며 점수에 기여하지 않으므로 훨씬 빠릅니다.
필터링을 위한 constant_score 쿼리 사용: 캐싱 이점을 위해 필터링 컨텍스트에서 실행하려는 query(필터가 아닌)가 있을 때 유용합니다.
자주 사용되는 필터 캐싱: Elasticsearch는 필터를 자동으로 캐시하지만, 이 동작을 이해하면 캐싱의 이점을 얻을 수 있는 쿼리를 설계하는 데 도움이 됩니다.
indices.query.bool.max_clause_count 조정: 많은 should 절로 기본 제한(1024)에 도달하는 경우 쿼리 재설계를 고려하거나 이 설정을 늘리십시오(주의해서).
정기적인 모니터링: 클러스터 상태, 노드 리소스, 느린 로그 및 쿼리 성능을 지속적으로 모니터링하여 문제를 조기에 감지하십시오.
테스트, 테스트, 테스트: 프로덕션에 배포하기 전에 항상 실제 데이터 볼륨 및 워크로드를 사용하여 스테이징 환경에서 쿼리 성능을 테스트하십시오.

결론

느린 Elasticsearch 쿼리를 해결하는 것은 초기 진단 확인과 Profile API와 같은 도구를 사용한 심층 분석을 결합하는 반복적인 프로세스입니다. 클러스터 상태를 이해하고, 쿼리 디자인을 최적화하고, 매핑을 세부 조정하고, 기본 리소스 병목 현상을 해결함으로써 검색 지연 시간을 크게 개선하고 Elasticsearch 클러스터의 성능과 안정성을 유지할 수 있습니다. 정기적으로 모니터링하고, 데이터를 기반으로 전략을 조정하며, 항상 효율적인 데이터 구조와 쿼리 패턴을 위해 노력하십시오.