ElasticSearch Cluster 구성 고려사항

IT Knowledge/ElasticSearch

Seok. 2024. 5. 28. 22:11

시스템 규모가 커지면, 노드들의 성격에 따라 전용 노드를 구성하고 그에 맞는 하드웨어와 운영방식이 필요하다.

또한 가용성을 높이기 위해 HA 방안도 고민해야 하는데, 마스터 후보 전용 노드는 가능하면 홀수(1,3,5)배열로 구성하며, 나머지 노드들은 하드비트를 통해 주기적으로 상태 검사를 수행해는 것이 중요하다.

엘라스틱서치를 실제 서비스로 운영하기 위해서 가장 신경써야 할 부분은 서비스의 안정성과 지속성일 것이다.

아무리 빠른 성능이라도 요청량을 수용하지 못하거나 검색을 제대로 처리하지 못한다면 운영에서는 사용할 수 없을것이다.

노드 구성 계획

마스터 노드 : 최소 3개

데이터 노드 : 최소 2대 ~ @

이외에 인덱싱 부하량에 따라 : 인제스트 노드 추가

검색 부하량에 따라 : 코디네이팅 노드 추가

하드웨어 선정

ElasticSearch가 분산/병렬 처리에 특화된 만큼 단일 노드의 HW Spec이 굉장히 좋을 필요는 없다.

메모리

일반적으로 가장 먼저 고갈되어 문제가 되는 리소스가 메모리 이다.

검색 성능, 샤드유지, 검색과 집계, 인덱싱, 코디네이팅 등 모든 영역에서 많은 메모리를 사용한다.

가장 이상적인 메모리는 64GB정도로 단일 노드에대해 충분한 힙 크기가를 활용할 수 있는 수준

CPU

분산 병렬 처리에 최적화 되어 있다보니, 단일 코어의 성능이 높은것보다, 코어수가 많은 CPU를 권장한다.

무거운 집계나 인덱싱을 수행하는 경우 CPU 성능이 병목이 될 수도 있다.

Disk

SSD가 권장이지만, 안되는 경우 가급적 RPM이 빠른 제품을 선택하자.

또한 네트워크 저장소는 피하도록 하자. 엘라스틱 서치는 많은 요소를 Heap 메모리에 로드해 빠른 검색과 집계가 가능하도록 하지만, 세그먼트를 읽고 쓰기 위해 디스크IO를 상당히 많이 사용한다.

물리의 경우 RAID도 RAID 0를 이용해 디스크 성능 향상을 도모하는 편이 좋다. 어차피 엘라스틱서치는 분산 검색 엔진으로 의도치 않은 데이터 손실에 대비한 소프트웨어적인 수단들이 마련되어 있기 때문이다.

하드웨어 통일

하드웨어의 스펙은 통일된편이 좋다. 이유는?

엘라스틱서치는 분산 검색 엔진인 만큼 조회 대상 샤드가 위치한 모든 노드에서 처리한 후 코디네이팅 노드에서 결과를 취합해 반환하므로, 검색의 총 시간은 가장 느린 노드가 코디네이팅 코드로 결과를 전달한 시간 + @가 된다.

따라서, 특정 하드웨어만 빠르다고 전체 검색 시간이 빠른 응답을 기대하긴 어렵다.

소규모 클러스터 구성

노드 5개를 이용한 소규모 구성이며, 마스터노드는 반드시 필요하기 때문에 3개의 노드를 마스터 호부 노드로 설정했다.

대규모 클러스터

대규모에는 각 전용 노드를 잘 활용하는 것이 중요하며,

데이터 읽기가 많은 시스템인지, 데이터 쓰기가 많은 시스템인지, 데이터가 얼마나 많이 필요한지 등의 다양한 요소에 따라서 구성이 바뀔 수 있다.

한가지 명심할 점은, 마스터 후보 전용 노드와 데이터 전용 노드를 나누는 것이 중요하다.

왜냐하면, 마스터 노드가 불안정하면, 클러스터 전체의 불안정으로 이어지므로 되도록 역할을 분리하고, 온전히 클러스터 관리에 집중시키는 것이 좋다.

책 : 엘라스틱서치 실무 가이드 (위키북스)

책 : 엘라스틱 스택 개발부터 운영까지(책만)