ElasticSearch 클러스터 튜닝 가이드

아래는 ES 클러스터를 구축하면서 커스터마이징을 권장하는 내용을 정리하였다. 

 

elasticsearch.yml에서

세그먼트 저장 경로 설정

path.data: /var/lib/elasticsearch/data1

 

스왑 메모리 사용 여부 설정

bootstrap.memory_lock: true

- 시스템의 스왑 메모리 영역을 사용하지 않도록 하는 설정이다. ES는 스왑 메모리 영역을 최대한 사용하지 않도록 권고하고 있다. 이 설정을 통해 스왑 영역을 사용하지 않으면 성능은 보장할수 있지만 시스템의 메모리가 부족한 경우에는 OOM 발생. 이 설정을 사용하기 위해서는 elasticsearch.yml 뿐만아니라 OS의 /etc/security/limit.conf도 수정해야 한다. 

# vi /etc/security/limits.conf
-----------------------------------------
elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited

 

systemd로 프로세스를 시작한다면 아래 내용 또한 추가

# mkdir /etc/systemd/system/elasticsearch.service.d
# vi /etc/systemd/system/elasticsearch.service.d/override.conf
-----------------------------------------------------------------
[Service]
LimitMEMLOCK=infinity


# systemctl daemon-reload

 

클러스터를 유지하기 위한 최소한의 Master 갯수

discovery.zen.ping.unicast.hosts: ["192.168.122.16","192.168.122.17",...]

discovery.zen.minimum_master_nodes: X

- 클러스터를 유지하기위한 최소한의 마스터 갯수를 뜻한다. 또한 split brain 현상을 방지하는데 반드시 필요한 설정이다. 따라서 minimum master node값을 과반수 이상으로 설정하면 네트워크 단절이 발생해도 한쪽은 충족하지 못하여 두개의 클러스터가 생기는 것을 방지할 수 있다. 

 

인덱스 일괄 삭제 방지

action.destructive_requires_name; true

- 클러스터에 저장되어 있는 인덱스를 _all이나 wildcard 표현식으로 삭제할 수 없도록 막는 설정. 인덱스를 삭제할때 사용자의 실수에 의해 전체 인덱스나 많은 인덱스가 한번에 삭제되지 못하게 하는 대표적인 방법

 

코디네이터 노드 분리

코디네티어 노드는 사용자의 요청을 받아 이를 실제로 처리할 데이터 노드에 전달하고, 각 데이터 노드로부터 받은 검색 결과도 하나로 취합해서 사용자에게 돌려준다. 그럼 코디네이트 역할은 왜 필요할까? 코디네이트 노드를 별도로 분리하는 가장 큰 이유는 사용자의 데이터 노드 중 한대가 코디네이트 노드의 역할과 데이터 노드의 역할을 동시에 함으로써 해당 노드의 사용량이 높아지는 것을 방지하기 위함이다. 

 

jvm.options 설정파일

JVM 힙메모리 영역만 튜닝해주면 된다. ES공식문서에는 가능한한 32GB를 넘지 않도록 설정할것, 전체 메모리의 절반정도를 힙 메모리로 설정할 것을 권고하고 있다.

-Xms?g

-Xmx?g

 

데이터 노드 증설이 용이한 클러스터 구성

아래 그림과 같은 형태의 구성이 좋은 이유는 클러스터의 색인략이 많아져서 저장해야할 데이터가 늘어난다거나 색인 검색 성능을 더 높이기 위해 노드의 증설이 필요할 경우 데이터 노드만 증설해주면 되기 때문이다. discovery.zen.minimum_master_nodes 설정이 과반수 이상이 되도록 항상 신경 써야하지만 데이터 노드만 증설하면 해당 설정에 신경을 쓸 필요가 없기 때문에 클러스터의 정합성 유지가 훨씬 간편하다.

그리고 3대 이상의 데이터노드로 구성하면 노드가 한대에서 장애가 발생했을 경우 해당 노드에 포함된 샤드들은 unassigned 상태에 빠지지만 레플리카 샤드가 프라이머리 샤드로 승격되면서 서비스는 지속된다. 또한 기본으로 설정된 60초를 기다린 후에도 장애가 발생한 노드가 클러스터로 복구되지 않으면 unassigned 상태로 빠진 샤드들은 클러스터 내 다른 데이터 노드로 복제한다. 이후 장애가 발생한 노드가 다시 정상적으로 클러스터에 합류하면 클러스터 내 샤드는 다시 적절하게 해당 노드에 샤드를 분배해준다. 이처럼 잘 구축된 ES클러스터는 노드 장애에 큰 영향을 받지 않고 노드의 확장을 쉽게 진행할 수 있어서 데이터 저장공간이나 성능 부족에 대한 조치가 수월하다.