성장을 위한 Elasticsearch 클러스터 확장 전략 가이드

Elasticsearch 클러스터 확장은 검색 속도가 느려지거나, 인덱싱 큐가 막히거나, 디스크가 예상보다 빨리 가득 차기 시작할 때 시급해집니다. 데이터 볼륨과 쿼리 부하가 증가함에 따라 기존 노드에 리소스를 추가할지, 노드를 더 추가할지, 샤드 전략을 변경할지, 아니면 핫 인덱스를 재설계할지 알아야 합니다.

이 가이드는 수직 및 수평 확장, 노드 역할, 샤드 크기 조정, 그리고 추측 없이 클러스터를 성장시키기 위한 실용적인 단계를 다룹니다.

Elasticsearch 확장 기본 사항 이해

Elasticsearch 클러스터 확장은 주로 수직 확장(스케일 업)과 수평 확장(스케일 아웃)이라는 두 가지 전략을 포함합니다. 최적의 전략은 종종 워크로드 특성에 따라 두 가지를 신중하게 균형 있게 조정하는 것입니다.

수직 확장 (스케일 업)

수직 확장은 기존 노드의 리소스를 늘리는 것입니다. 이것은 가장 간단한 접근 방식이지만 물리적 한계에 빠르게 도달합니다.

수직 확장을 사용해야 하는 경우:

지연 시간이 주요 관심사이고 기존 데이터 세트에서 더 빠른 쿼리 응답이 필요할 때.
새 노드를 추가하고 리밸런싱하는 데 필요한 시간보다 더 빠른 완화가 필요한 단기적인 압박이 있을 때.

주요 리소스 업그레이드:

RAM (메모리): Elasticsearch는 JVM 힙과 대용량 OS 파일 시스템 캐시가 필요합니다. 일반적인 시작점은 JVM에 따라 약 26-32GB인 압축된 일반 객체 포인터 임계값 미만을 유지하면서 힙을 시스템 RAM의 약 50%로 설정하는 것입니다.
CPU: 복잡한 집계, 대량 인덱싱 및 높은 쿼리 동시성에 필요합니다.
스토리지 (디스크 I/O): 더 빠른 SSD 또는 NVMe 드라이브는 특히 I/O 집약적인 워크로드에서 인덱싱 처리량과 검색 속도를 크게 향상시킵니다.

수직 확장에 대한 경고: 매우 큰 JVM 힙은 압축된 일반 객체 포인터 이점을 잃을 수 있고 더 긴 가비지 컬렉션 일시 중지를 겪을 수 있습니다. 추가 RAM은 파일 시스템 캐시에 여전히 유용하지만 힙 크기를 늘리는 것은 장기적인 확장 계획이 아닙니다.

수평 확장 (스케일 아웃)

수평 확장은 클러스터에 더 많은 노드를 추가하는 것입니다. 이는 데이터와 쿼리 부하를 더 많은 머신에 분산시켜 거의 선형적인 확장성과 높은 가용성을 제공합니다.

수평 확장을 사용해야 하는 경우:

데이터 볼륨이 기존 노드의 용량을 초과할 때.
전체 인덱싱 처리량이나 쿼리 동시성을 개선해야 할 때.
장기적이고 지속 가능한 성장을 위한 주요 전략으로.

수평 확장은 새 데이터 노드를 추가하여 달성됩니다. 코디네이팅 노드도 추가할 수 있지만 일반적으로 데이터 노드 확장이 용량 증가를 주도합니다.

확장성을 위한 아키텍처 모범 사례

확장은 단순히 하드웨어를 추가하는 것 이상입니다. 잘 구조화된 인덱스와 노드 토폴로지가 필요합니다.

노드 역할 및 전문화

최신 Elasticsearch 배포는 특히 대규모 클러스터에서 노드에 전용 역할을 할당함으로써 큰 이점을 얻습니다. 이는 무거운 작업(예: 인덱싱)과 중요한 작업(예: 검색 조정) 간의 리소스 경합을 방지합니다.

노드 역할	주요 책임	모범 사례 고려 사항
마스터 노드	클러스터 상태 관리, 안정성.	3개 또는 5개의 전용 노드 세트. 데이터 또는 수집 요청을 처리하지 않아야 합니다.
데이터 노드	데이터 저장, 인덱싱, 검색.	데이터 볼륨과 부하에 따라 적극적으로 확장하세요.
수집 노드	인덱싱 전 문서 전처리 (수집 파이프라인 사용).	CPU 집약적인 전처리를 데이터 노드에서 오프로드하세요.
코디네이팅 노드	대규모 검색 요청 처리, 데이터 노드에서 결과 수집.	검색 요청이 복잡해지거나 조정 오버헤드로 데이터 노드에 과부하가 자주 걸릴 때 추가하세요.

샤드 할당 전략

샤드는 Elasticsearch에서 분산 및 병렬 처리의 기본 단위입니다. 잘못된 샤드 할당은 확장 문제의 가장 큰 원인입니다.

1. 기본 샤드 수 최적화

올바른 기본 샤드 수(index.number_of_shards)를 선택하는 것은 중요하며 인덱스 생성 후 쉽게 변경할 수 없습니다(인덱스 별칭 또는 재인덱싱을 사용하지 않는 한).

샤드가 너무 적음: 검색 중 병렬 처리를 제한하고 효과적인 수평 확장을 방해합니다.
샤드가 너무 많음: 클러스터 상태 오버헤드를 추가하고 메모리 사용량을 증가시키며 조정 비용이 유용한 작업을 지배하는 "작은 샤드" 문제를 만듭니다.

모범 사례: 많은 시계열 및 로깅 워크로드의 경우 수십 기가바이트(종종 약 10GB~50GB)의 샤드 크기를 목표로 하세요. 이것을 시작 범위로 간주하고 자체 인덱싱 속도, 보존 기간 및 쿼리 패턴으로 테스트하세요.

2. 고가용성 및 읽기 처리량을 위한 복제본 샤드

복제본 샤드(index.number_of_replicas)는 중복성을 제공하고 읽기 용량을 증가시킵니다.

number_of_replicas: 1로 설정하면 모든 기본 샤드에 하나의 복사본이 있어 고가용성(HA)을 보장합니다.
복제본을 늘리면 검색이 기본 또는 복제본 복사본에서 제공될 수 있으므로 읽기 용량이 향상될 수 있지만 스토리지 사용량과 인덱싱 작업도 증가합니다.

HA 설정 예시: 10개의 기본 샤드가 있고 number_of_replicas: 1로 설정하면 클러스터는 노드에 분산된 최소 20개의 총 샤드 복사본(10개 기본 + 10개 복제본)이 필요합니다.

PUT /my_growing_index
{
  "settings": {
    "index.number_of_shards": 20,
    "index.number_of_replicas": 1 
  }
}

인식 기능으로 핫스팟 방지

새 노드를 추가할 때 샤드가 장애 도메인 전체에 분산되어 있는지 확인하세요. Elasticsearch는 자동으로 리밸런싱하지만 영역 또는 랙 인식은 노드 속성과 할당 인식 설정을 구성한 경우에만 작동합니다.

클러스터 할당 설명자 API를 사용하여 샤드가 새 노드로 이동하지 않거나 노드에 과부하가 걸리는 이유를 진단하세요.

실용적인 확장 단계: 성장 처리

클러스터 성능이 저하되면(높은 JVM 힙 압력, 느린 쿼리, 느린 인덱싱) 다음 단계를 순서대로 따르세요.

1단계: 모니터링 및 진단

변경하기 전에 병목 현상을 진단하세요. 일반적인 지표:

높은 CPU/낮은 여유 메모리: 컴퓨팅 또는 메모리 부족을 나타냄(잠재적 수직 확장 필요).
과도한 디스크 큐 길이: I/O 병목 현상을 나타냄(더 빠른 디스크 또는 노드 추가 필요).
검색 지연 시간 급증: 종종 불충분한 캐싱 또는 너무 적은 샤드/복제본으로 인해 발생(더 많은 메모리 또는 수평 확장 필요).

2단계: 즉각적인 리소스 필요 사항 해결 (수직 조정)

메모리 압력이 높으면 안전 한도 내에서 JVM 힙 크기를 늘리고(최대 32GB) OS 파일 시스템 캐시에 충분한 RAM이 있는지 확인하세요.

3단계: 스케일 아웃 (수평 확장)

노드를 추가하는 경우 다음 절차를 따르세요.

동일하거나 우수한 하드웨어로 새 데이터 노드를 프로비저닝합니다.
올바른 역할로 구성합니다. 용량 증가의 경우 배포에 따라 일반적으로 data_hot, data_content 또는 data와 같은 데이터 역할을 의미합니다.
discovery.seed_hosts를 사용하여 기존 클러스터를 가리킵니다.
새 노드가 조인되면 Elasticsearch는 자동으로 기존 샤드를 리밸런싱하여 새 용량을 활용합니다.

4단계: 미래 대비 인덱스 (재인덱싱)

기존 인덱스의 샤드 수가 최적이 아닌 경우 새 노드를 완전히 활용할 수 없습니다. 다시 빌드해야 합니다.

새 인덱스 템플릿을 만들거나 원하는 샤드 및 복제본 수로 인덱스 생성 API를 사용합니다.
재인덱싱 API를 사용하여 이전의 크기가 잘못된 인덱스에서 새 인덱스로 데이터를 마이그레이션합니다.
마이그레이션이 완료되면 별칭을 사용하여 트래픽을 전환합니다.

재인덱싱 명령 예시:

POST _reindex
{
  "source": {
    "index": "old_index_bad_shards"
  },
  "dest": {
    "index": "new_index_optimized_shards"
  }
}

모범 사례 체크리스트

Elasticsearch 확장은 먼저 모니터링하고, 한 번에 하나의 변수만 변경하고, 샤드 레이아웃을 성장 패턴에 맞게 유지할 때 가장 잘 작동합니다.

핵심 사항:

수평 확장 우선: 지속적인 성장과 복원력을 위한 최상의 경로를 제공합니다.
전용 마스터 노드: 마스터 역할을 분리하여 클러스터 관리를 안정적으로 유지합니다.
샤드 크기는 영구적: 인덱스 생성 시 기본 샤드 크기를 10GB-50GB로 목표로 하세요.
JVM 힙 모니터링: JVM의 압축 포인터 임계값 미만으로 힙을 유지하고 OS 캐시에 충분한 RAM을 남겨두세요.
재인덱싱 사용: 스케일 아웃 시 기본 샤드 수 변경이 필요한 경우 중요한 인덱스를 다시 빌드하세요.