[ElasticSearch] 검색 성능 최적화

 

 

ElasticSearch 노드 수를 늘리면 어떻게 되는가?

노드 수를 늘리면 시스템의 총 자원이 증가하여 더 많은 작업을 동시에 처리할 수 있게 됩니다. 이는 CPU 사용률과 디스크 I/O 활동의 증가로 나타나며, 평균 kB_read/s와 kB_wrtn/s가 상승하는 결과를 가져옵니다. 이러한 변화는 시스템이 더 높은 처리량을 달성하고 있음을 의미하지만, 동시에 리소스 사용의 효율성을 유지하기 위해 적절한 클러스터 구성과 관리가 필요합니다.

 

---

Index Sorting

Index Sorting은 Elasticsearch에서 인덱스를 생성할 때 샤드 내부의 세그먼트(segment)가 특정 필드나 필드들의 기준으로 정렬되도록 설정하는 기능입니다.

일반적인 검색 정렬 방식:

 

• 검색 과정: 일반적으로 검색 시에는 쿼리에 매치되는 모든 도큐먼트를 탐색하고, 그 후에 원하는 기준으로 정렬하여 상위 N개의 도큐먼트를 반환합니다.
• 성능 이슈: 이 방식은 매치되는 모든 도큐먼트를 방문해야 하므로, 데이터 양이 많아질수록 성능 저하가 발생할 수 있습니다.

Index Sorting을 사용하는 경우:

• 인덱스 생성 시 정렬: Index Sorting을 사용하여 인덱스를 생성할 때 특정 필드(예: rdate)로 미리 정렬해 두면, 검색 시 이점을 얻을 수 있습니다.
• 검색 최적화: 검색 시 **검색 정렬(search sort)**와 **인덱스 정렬(index sort)**가 동일하면, Elasticsearch는 각 세그먼트에서 상위 N개의 도큐먼트만 비교하면 된다는 것을 인지합니다.
• 불필요한 작업 감소: 따라서 쿼리와 일치하는 나머지 도큐먼트들은 총 도큐먼트 수를 계산하거나 집계 결과를 내기 위해서만 수집되고, 정렬 비교에서는 제외됩니다.

---

Early Termination (조기 종료):

• track_total_hits 옵션: 만약 총 도큐먼트 수(total number)가 필요 없고 상위 N개의 검색 결과만 필요하다면, track_total_hits를 false로 설정할 수 있습니다.
• 조기 종료: 이 설정을 통해 Elasticsearch는 N개의 도큐먼트를 방문한 후 쿼리를 중단하며, 이를 **조기 종료(early termination)**라고 합니다.
• 이점: 조기 종료를 사용하면 불필요한 도큐먼트 탐색을 줄여 검색 성능을 향상시킬 수 있습니다.

---

실험 결과 해석:

• rdate로 정렬: 실험에서는 Index Sorting을 사용하여 인덱스 생성 시 rdate 필드를 정렬 기준으로 정의하였습니다.
• 성능 향상 확인: 이를 통해 검색 시 rdate로 정렬된 상위 N개의 도큐먼트를 보다 효율적으로 가져올 수 있었으며, 조기 종료를 통해 쿼리 처리 시간을 단축할 수 있었습니다.
• 자원 활용 최적화: 불필요한 도큐먼트 탐색이 줄어들어 CPU 사용률 및 I/O 작업량이 감소하는 효과도 기대할 수 있습니다.

---

 

* sort 유무는 쿼리 시점에서 정렬을 요구하는지를 의미함.

 

Index Sorting의 장점

1. 검색 성능 향상:
   • rdate 필드로 미리 정렬해둔 덕분에, 검색 쿼리 시 별도로 정렬 과정을 거치지 않고 이미 정렬된 데이터에서 필요한 결과를 빠르게 가져올 수 있습니다.
   • 실험 결과: 200,000개의 데이터를 조회할 때 검색 속도가 약 1.7초 향상되었습니다.
2. 디스크 공간 절약:
   • 인덱스에서 반복되는 값을 효율적으로 압축해 저장하므로, 디스크 사용량이 줄어듭니다.
   • 실험 결과: 인덱스 크기가 5.2GB에서 5GB로 감소하여, 저장 공간이 약간 절약되었습니다.

Index Sorting의 단점

1. 인덱싱 성능 저하:
   • 인덱싱 과정에서 데이터가 rdate 기준으로 정렬되기 때문에 추가적인 처리 시간이 필요합니다.
   • 실험 결과: 인덱싱 시간이 49분 35초에서 50분 20초로 늘어났습니다.
   • 이는 데이터 정렬과 압축 과정이 추가됨에 따라 발생한 오버헤드로 볼 수 있습니다.

요약

Index Sorting을 사용하여 검색 성능과 디스크 공간을 개선할 수 있지만, 인덱싱 성능이 저하될 수 있습니다

 

---

Resource 측정

1. 인덱싱

 

• 정렬 작업의 부하: Index Sorting을 사용하는 경우, 인덱스 생성 시점에 rdate를 기준으로 정렬 작업이 수행됩니다. 정렬 작업은 리소스를 많이 사용하는 과정이므로, 인덱싱 시 평균 wrtn/s(write per second)가 더 높게 나타납니다.
• 디스크 쓰기 증가: 정렬된 상태로 인덱싱을 수행하다 보니, 기본 인덱싱(default)보다 더 많은 디스크 쓰기 작업이 발생하게 됩니다. 이를 통해 확인된 결과:
  • Default 인덱싱: 총 84GB(84,462,650kB)
  • Index Sorting 적용 인덱싱: 총 106GB(106,586,150kB)
  결과적으로 Index Sorting을 적용하면 write 작업량이 더 많아지고, 인덱싱 비용이 증가하게 됩니다.

2. 검색

• 메모리 사용량: 데이터 조회 시 메모리 사용량은 sort 유무와 상관없이 default는 9.4GB, index sorting은 10.4GB로, index sorting을 사용한 경우 메모리를 더 많이 사용합니다. 이는 정렬된 데이터를 효율적으로 관리하기 위한 추가 리소스가 필요하기 때문일 수 있습니다.
• 쿼리 시 sort 사용 시 성능 변화:
  • Index Sorting이 적용된 인덱스에 쿼리에서 sort 옵션을 사용하면, 이미 정렬된 상태에서 상위 N개의 결과를 빠르게 조회할 수 있습니다.
  • 평균 CPU 사용률: 정렬이 이미 되어 있기 때문에 추가적인 정렬 작업이 필요하지 않아 평균 CPU 사용률이 더 낮아집니다.
  • 평균 kB_read/s: 정렬된 데이터를 빠르게 읽어올 수 있어, kB_read/s가 더 높게 나타납니다.
• 쿼리 시 sort를 사용하지 않을 경우:
  • sort 옵션을 사용하지 않는 쿼리에서는 Index Sorting의 장점이 크게 작용하지 않기 때문에, CPU 사용률 그래프가 기본 인덱싱과 유사한 형태로 나타납니다.
  • 즉, 정렬이 필요 없는 단순 조회에서는 Index Sorting이 적용된 인덱스와 기본 인덱스 간의 성능 차이가 크지 않습니다.

---

요약

• 인덱싱: Index Sorting을 사용하면 정렬 작업으로 인해 더 많은 디스크 쓰기와 자원 사용량이 발생하지만, 정렬된 데이터를 효율적으로 조회하기 위해 필요한 단계입니다.
• 검색: 정렬된 상태로 인덱싱된 데이터는 쿼리 시 sort 옵션 사용 시 성능 향상 효과를 볼 수 있으며, CPU 사용률은 줄고 kB_read/s는 증가합니다. 하지만, sort 옵션을 사용하지 않는 경우에는 기본 인덱싱과 성능 차이가 거의 없습니다.

---

Numeric Types

해당 실험에서는 rdate 필드를 문자열이 아닌 숫자 타입으로 사용하여 인덱싱 및 검색 성능을 비교한 것입니다. 이를 위해 rdate 필드를 두 개의 숫자 타입 필드로 분리하여 실험을 진행했습니다:

1. 숫자 타입 설정:
   • rdate 필드를 두 개의 숫자 타입(long 또는 double)으로 나누어 정렬하였습니다.
     • long은 정수형 타입 / double은 소수점을 포함하는 실수형 타입
   • Elasticsearch에서는 원래 문자열로 처리되는 날짜 데이터를 숫자 타입으로 변환하여 인덱싱 성능과 검색 성능에 미치는 영향을 확인했습니다.
2. 실험 결과:
   • long 타입으로 인덱싱할 경우, keyword 타입에 비해 인덱스 크기가 더 줄어들었으며, 인덱싱 시간이 약 1분 40초 단축되었습니다.
   • 검색 성능 측면에서도 long과 double 타입을 사용했을 때 keyword 타입보다 검색 속도가 약 2배 향상되었습니다. 특히, long 타입이 인덱싱 효율과 검색 성능에서 모두 좋은 결과를 보였습니다.
3. 리소스 사용량:
   • 데이터 200,000개 조회 시, 메모리 사용량은 세 가지 타입 모두 10.4GB로 비슷했으며, 평균 CPU 사용률은 keyword 타입이 가장 높고 long 타입이 그 뒤를 따랐습니다.
   • 평균 kB_read/s는 double 타입에서 가장 높게 나타났습니다.

이 실험을 통해 rdate를 숫자 타입으로 설정할 경우 인덱싱 시간과 검색 성능 모두에서 성능 개선이 가능함을 확인할 수 있습니

---

 

Elasticsearch Heap Size

Elasticsearch Heap Size는 Elasticsearch의 JVM 힙 메모리 크기를 설정하는 요소로, 힙 사이즈에 따라 검색 및 인덱싱 성능이 크게 영향을 받을 수 있습니다. 이 실험에서는 Elasticsearch 노드의 힙 사이즈를 다르게 설정하여 성능 차이를 비교했습니다. 힙 사이즈 설정의 주요 특징과 실험 결과를 설명드리겠습니다.

실험 설정

• 노드 구성: Elasticsearch 노드 3개와 5개로 나누어 각각 실험을 진행했습니다.
• 힙 사이즈 변경: Elasticsearch의 힙 사이즈를 기본값 1GB에서 시작해 4GB, 8GB, 16GB, 32GB까지 설정했습니다.
• 실험 변수: 각 힙 사이즈 설정에 따라 인덱싱 속도, 검색 속도, CPU 사용률, 메모리 사용량, kB 읽기/쓰기 속도를 비교하였습니다 개선**:
  • 힙 사이즈가 4GB 이상일 때, 기본 설정보다 검색 성능이 개선되었습니다. 특히 8GB에서 검색 성능이 가장 좋았으며, 그 이상으로 힙 사이즈를 증가시켜도 성능 향상 폭은 제한적이었습니다.
  • Elasticsearch는 힙 메모리가 충분할수록 효율적인 캐싱을 통해 검색 속도를 높일 수 있습니다.

1. CPU 사용률:
   • 힙 사이즈가 증가함에 따라 CPU 사용률이 낮아지는 경향을 보였습니다. 이는 캐시 적중률이 높아져 CPU가 추가적인 계산 작업을 덜 수행하게 되기 때문입니다.
   • 특히, 4GB 이상의 힙 사이즈에서 평균 CPU 사용률이 기본값보다 크게 낮아졌습니다 .
2. 메모리 사용량:
   • 힙 더 많은 데이터를 메모리에 저장할 수 있게 됩니다. 이로 인해 kB_read/s는 높아지고 kB_wrtn/s는 낮아지는 경향을 보였습니다.
   • 이는 Elasticsearch가 더 큰 힙 사이즈를 활용해 디스크 I/O를 줄이고 메모리 내에서 더 많은 데이터를 처리할 수 있기 때문입니다 .
3. 적정 힙 사이즈:
   • 힙 사이즈를 **8GB로 설정했을 때 성능이 가장 었습니다. 오히려 32GB로 설정했을 때는 미세하게 성능이 감소하는 현상이 나타났습니다.
   • 일반적으로 힙 사이즈가 너무 크면, 가비지 컬렉션(GC) 작업이 오히려 시스템 성능에 부담을 줄 수 있습니다. 따라서, 필요 이상으로 힙 메모리를 크게 설정하지 않는 것이 좋습니다 .

요약

• Elasticsearch 힙 사이즈는 검색 및 인덱싱 성능에 중요한 영향을 미칩니다. 이 실험에서는 **8GB가 가한 힙 메모리 설정은 CPU 사용률을 낮추고, 디스크 I/O를 줄여 검색 성능을 최적화할 수 있습니다.
• 힙 사이즈가 너무 큰 경우 가비지 컬렉션으로 인한 성능 저하가 발생할 수 있으므로, 필요에 따라 최적의 힙 사이즈를 설정하는 것이 중요합니다.