Elasticsearch 클러스터에서 인덱싱 성능을 개선하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2019년 8월 23일

수집 처리량을 극대화할 수 있도록 Amazon Elasticsearch Service(Amazon ES)에서 인덱싱 작업을 최적화하려고 합니다.

​해결 방법

다음 방법 중 하나 이상을 사용하여 Amazon ES의 클러스터에서 인덱싱 성능을 개선합니다.

수집하려는 인덱스의 샤드가 데이터 노드에 고르게 분산되어 있는지 확인합니다.

다음 공식을 사용하여 샤드가 고르게 분산되어 있는지 확인합니다.

인덱스의 샤드 수 = k*(데이터 노드 수). 여기서 k는 노드당 샤드 수

예를 들어 인덱스에 24개의 샤드가 있고 8개의 데이터 노드가 있는 경우 노드당 3개의 샤드가 있어야 합니다. 자세한 내용은 Amazon Elasticsearch Service 시작하기: 얼마나 많은 샤드가 필요합니까?를 참조하십시오.

refresh_interval 값을 60초 이상으로 늘림

Elasticsearch 인덱스를 새로 고치면 문서를 검색할 수 있습니다. 이 작업은 간단하지만 인덱스를 새로 고치려면 인덱싱 스레드에서 사용할 리소스가 필요합니다.

기본 새로 고침 간격은 1초입니다. 새로 고침 간격을 늘리면 데이터 노드가 API 호출 횟수를 줄입니다. 새로 고침 간격이 길수록 인덱싱이 빨라집니다. 새로 고침 간격을 늘리면 429 오류를 방지하는 데에도 도움이 됩니다.

복제본 수를 0으로 변경

한 시간 또는 두 시간의 큰 인덱싱 작업이 예상되는 경우 index.number_of_Replicas0으로 설정하는 것이 좋습니다. 각 복제본은 인덱싱 프로세스를 복제하므로 복제본을 비활성화하면 성능이 향상됩니다. 인덱싱이 끝나면 복제본을 다시 활성화합니다.

중요: 복제본이 비활성화되어 있는 동안 노드에 장애가 발생하면 데이터가 손실될 수 있습니다. 1시간 또는 2시간 동안 데이터 손실을 허용할 수 있는 경우에만 복제본을 비활성화하십시오.

최적의 대량 요청 크기를 찾기 위한 실험

5~15MiB의 대량 요청 크기로 시작합니다. 그런 다음 인덱싱 성능이 더 개선되지 않을 때까지 요청 크기를 천천히 늘립니다. 자세한 내용은 Elasticsearch 설명서에서 대량 요청 사용 및 크기 조정을 참조하십시오.

참고: 일부 인스턴스 유형은 대량 요청이 10MiB로 제한됩니다. 자세한 내용은 네트워크 제한을 참조하십시오.

SSD 인스턴스 스토어 볼륨이 있는 인스턴스 유형(예: I3) 사용

I3 인스턴스는 빠른 로컬 NVMe(Non-Volatile Memory Express)스토리지를 제공합니다. 이러한 인스턴스는 범용 SSD(gp2) Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용하는 인스턴스보다 훨씬 뛰어난 수집 성능을 제공합니다. 자세한 내용은 I3 인스턴스를 사용하여 Amazon Elasticsearch Service에서 페타바이트 규모의 클러스터 실행을 참조하십시오.

응답 크기를 줄임

Elasticsearch 응답의 크기를 줄이려면 filter_path 파라미터를 사용하여 필요 없는 필드를 제외합니다. 실패한 요청을 식별하거나 재시도하는 데 필요한 필드는 필터링하지 마십시오. 이러한 필드는 클라이언트에 따라 다릅니다.

다음 예제에서는 index-name, type-name took 필드가 응답에서 제외됩니다.

curl -X POST "es-endpoint/index-name/type-name/_bulk?pretty&filter_path=-took,-items.index._index,-items.index._type" -H 'Content-Type: application/json' -d'
{ "index" : { "_index" : "test2", "_id" : "1" } }
{ "user" : "testuser" }
{ "update" : {"_id" : "1", "_index" : "test2"} }
{ "doc" : {"user" : "example"} }

자세한 내용은 응답 크기 줄이기를 참조하십시오.

index.translog.flush_threshold_size 값을 늘림

기본적으로 index.translog.flush_threshold_size는는 512MB로 설정됩니다. 즉, translog가 512MB에 도달하면 플러시됩니다. 인덱싱 로드가 많을수록 translog가 더 자주 플러시됩니다. index.translog.flush_threshold_size를 늘리면 노드가 리소스를 많이 소모하는 이 작업을 실행하는 빈도가 적어집니다. 이렇게 하면 일반적으로 인덱싱 성능이 향상됩니다. 크기를 늘리는 또 다른 이점은 클러스터가 여러 개의 작은 세그먼트 대신 몇 개의 큰 세그먼트를 생성한다는 것입니다. 큰 세그먼트는 병합 빈도가 낮습니다. 즉, 병합하는 대신 인덱싱에 더 많은 스레드가 사용됩니다.

index.translog.flush_threshold_size를 늘리는 방법의 단점은 translog 플러시에 시간이 더 오래 걸리다는 것입니다. 샤드가 실패할 경우 translog가 더 크기 때문에 복구 시간이 더 오래 걸립니다.

index.translog.flush_threshold_size를 늘리기 전에 다음 API 작업을 호출하여 현재 플러시 작업 통계를 가져옵니다. 예제에서 다음 값을 대체합니다.

  • es-endpoint: Elasticsearch 클러스터 엔드포인트
  • index-name: 인덱스의 이름
$ curl 'es-endpoint/index-name/_stats/flush?pretty'

출력에서 플러시 수와 총 시간을 기록해 둡니다. 다음 예에서는 124개의 플러시가 있었고 17,690밀리초가 걸렸습니다.

"flush" { "total" : 124, "total_time_in_millis" : 17690 }

플러시 임계값 크기를 늘리려면 다음 API 작업을 호출합니다. 이 예제에서는 플러시 임계값 크기가 1,024 MB로 설정되어 있으며, 이는 32GB 이상의 메모리가 있는 인스턴스에 적합합니다. 사용 사례에 가장 적합한 임계값 크기를 선택합니다.

$ curl -XPUT 'es-endpoint/index-name/_settings?pretty' -d '{"index":{"translog.flush_threshold_size" : "1024MB"}}'

_stats API 작업을 다시 실행하여 플러시 작업이 어떻게 변경되었는지 확인합니다.

$ curl 'es-endpoint/index-name/_stats/flush?pretty' 

참고: 현재 인덱스에 대해서만 index.translog.flush_threshold_size를 늘리는 것으로 시작하는 것이 좋습니다. 원하는 결과가 얻어지는지 확인한 후 인덱스 템플릿에 변경 사항을 적용하십시오.

_all 필드 비활성화

_all 필드는 다른 모든 필드의 값을 하나의 문자열로 연결합니다. 이 필드는 다른 필드보다 더 많은 CPU 및 디스크 공간을 필요로 합니다. 대부분의 사용 사례에는 _all 필드가 필요하지 않습니다. copy_to 파라미터를 사용하여 여러 필드를 연결할 수 있습니다.

Elasticsearch 버전 6.0 이상에서는 _all 필드가 기본적으로 비활성화되어 있습니다. 이전 버전에서 _all 필드를 비활성화하려면 enabledfalse로 설정합니다. 예:

curl -XPUT  <es-endpoint>/<index-name>?pretty -d '{"mappings" : {"type-name" : {"_all": {"enabled": false}}}}' -H 'Content-Type: application/json'

_all 필드를 비활성화하는 것에 더해, _source 필드를 정리할 수도 있습니다. 이는 고급 사용자에게만 권장됩니다. 자세한 내용은 Elasticsearch 설명서에서 _source 필드를 참조하십시오.


이 문서가 도움이 되었습니까?

AWS에서 개선해야 할 부분이 있습니까?


도움이 필요하십니까?