Elasticsearch 샤드 크기 조정 가이드: 성능 및 확장성 균형

Elasticsearch는 방대한 양의 데이터를 처리하는 데 탁월한 강력한 분산 검색 및 분석 엔진입니다. 그러나 최적의 성능과 안정성을 달성하는 것은 데이터 분산 구조, 특히 샤드 크기 조정에 크게 좌우됩니다. 샤드는 Elasticsearch 인덱스의 기본 구성 요소이며, 데이터가 클러스터 노드에 걸쳐 어떻게 분할, 복제 및 분산되는지를 결정합니다. 부적절한 샤드 크기 조정은 심각한 성능 병목 현상, 운영 오버헤드 증가 또는 반대로 리소스 활용 부족으로 이어질 수 있습니다.

이 가이드는 Elasticsearch 클러스터에서 최적의 샤드 크기를 결정하기 위한 실용적인 프레임워크를 제공합니다. 쿼리 성능, 색인 처리량, 클러스터 복원력 및 리소스 소비 간의 중요한 절충점을 탐색하여 특정 워크로드에 완벽한 균형을 맞출 수 있도록 돕겠습니다.

Elasticsearch 샤드 이해하기

크기 조정에 들어가기 전에, 샤드가 무엇이며 클러스터 아키텍처 내에서 어떻게 작동하는지 이해하는 것이 중요합니다. Elasticsearch의 인덱스는 하나 이상의 기본 샤드(primary shard)로 구성됩니다. 각 기본 샤드는 데이터를 호스팅할 수 있는 독립적인 Lucene 기반 인덱스입니다.

기본 샤드 vs. 복제 샤드

기본 샤드(Primary Shards): 실제 데이터를 저장합니다. 색인(indexing) 및 검색 작업을 담당합니다. 인덱스에 대한 기본 샤드 수를 정의할 때, 데이터가 클러스터 전체에 수평적으로 어떻게 분산될지 결정하게 됩니다.
복제 샤드(Replica Shards): 기본 샤드의 복사본입니다. 중복성(내결함성)을 제공하고, 쿼리가 기본 및 복제본 모두에서 처리될 수 있도록 하여 검색 처리량을 증가시킵니다.

샤드 수의 영향

총 샤드 수(기본 + 복제)는 클러스터 오버헤드에 직접적인 영향을 미칩니다. 모든 샤드는 상태 및 메타데이터 추적을 위해 메모리(힙 공간)와 CPU 리소스를 필요로 합니다. 너무 많은 작은 샤드는 마스터 노드에 과부하를 주고 클러스터 관리 오버헤드를 증가시켜, 개별 샤드가 작더라도 성능 저하로 이어질 수 있습니다.

주요 제약 조건 및 크기 조정 권장 사항

샤드 크기에 대한 단 하나의 "마법의 숫자"는 없습니다. 최적의 크기는 데이터 볼륨, 색인 속도 및 쿼리 패턴에 따라 크게 달라집니다. 그러나 Elasticsearch 문서 및 커뮤니티 모범 사례는 몇 가지 중요한 지침을 제공합니다.

1. 크기 임계값: 최적의 샤드 크기

가장 중요한 요소는 단일 샤드 내에 포함된 데이터의 크기입니다.

권장 최대 크기: 일반적인 합의와 모범 사례는 개별 기본 샤드를 10GB에서 50GB 사이로 유지할 것을 권장합니다.
절대 최대치: 기술적으로는 가능하지만, 샤드당 100GB를 초과하는 것은 복구 작업, 색인 성능 및 클러스터 안정성에 부담을 주기 때문에 강력히 권장되지 않습니다.

왜 제한이 있나요? 노드에 장애가 발생하면 Elasticsearch는 해당 노드에 저장된 샤드를 재할당(재배치 또는 재복제)해야 합니다. 대용량 샤드는 복구에 필요한 시간을 크게 늘려 복원력이 저하되는 기간을 증가시킵니다. 또한 Lucene은 중간 크기의 세그먼트를 관리할 때 더 잘 작동합니다.

2. 문서 수 임계값

크기가 가장 중요하지만, 특히 매우 작은 문서의 경우 문서 수도 관련이 있습니다.

권장 문서 범위: 샤드당 100,000개에서 5백만 개 사이의 문서를 포함하도록 목표를 설정하세요.

문서가 극도로 작은 경우(예: 수백 바이트), 문서 수 권장치에 도달하기 전에 크기 제한(50GB)에 도달할 수 있습니다. 반대로 문서가 매우 큰 경우(예: 수 메가바이트 JSON Blob), 크기 제한 내에 머물면서도 문서 수 제한에 빠르게 도달할 수 있습니다.

3. 클러스터 오버헤드 및 샤드 수

리소스 소비를 효과적으로 관리하기 위해 노드당 총 샤드 수를 제한하세요.

GB 힙당 샤드: 일반적인 지침은 데이터 노드에 할당된 1GB 힙 공간당 약 20개의 샤드(기본 + 복제본)를 사용하도록 총 샤드 수를 유지하는 것입니다.

계산 예시: 데이터 노드에 30GB의 힙이 할당된 경우:

$$30 \text{ GB} \times 20 \text{ shards/GB} = 600 \text{ total shards}$$

인덱스에 100개의 기본 샤드가 필요한 경우, 이 비율에 따라 전체 오버헤드를 관리할 수 있도록 클러스터에 충분한 노드가 있는지 확인해야 합니다.

실용적인 샤드 크기 조정 방법론

예상되는 총 데이터 크기를 기반으로 새 인덱스에 필요한 적절한 기본 샤드 수를 계산하려면 다음 단계를 따르세요.

1단계: 총 인덱스 크기 추정

이 인덱스가 운영 수명(예: 6개월 또는 1년) 동안 저장할 것으로 예상되는 총 데이터 양을 결정합니다.

예시: logs-2024 인덱스에 2 TB의 데이터를 저장할 것으로 예상합니다.

2단계: 목표 샤드 크기 정의

가이드라인(예: 40GB)에 따라 안전한 목표 크기를 선택합니다.

예시: 목표 샤드 크기 = 40 GB.

3단계: 필요한 기본 샤드 계산

예상 총 크기를 목표 샤드 크기로 나눕니다. 항상 가장 가까운 정수로 올림합니다.

$$\text{Primary Shards} = \text{Ceiling} \left( \frac{\text{Total Index Size}}{\text{Target Shard Size}} \right)$$

계산 예시 (2 TB = 2048 GB):
$$\text{Primary Shards} = \text{Ceiling} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{Ceiling}(51.2) = 52$$

이 시나리오에서는 52개의 기본 샤드로 인덱스를 생성해야 합니다.

4단계: 복제본 수 결정

복원력 및 검색 볼륨 요구 사항에 따라 복제본 수를 결정합니다.

복원력: 고가용성을 위해 number_of_replicas를 최소 1로 설정합니다.
검색 성능: 검색 트래픽이 많으면 2개 이상의 복제본을 사용합니다.
예시: 표준 내결함성을 위해 1개의 복제본을 선택합니다.

최종 인덱스 설정: 52개의 기본 샤드 및 1개의 복제본 (총 104개의 샤드).

5단계: 노드 간 분산

클러스터에 충분한 노드(및 충분한 힙 공간)가 있는지 확인하여 20 shards/GB 힙 규칙을 유지하면서 이러한 샤드를 효과적으로 호스팅하도록 합니다.

인덱스 수명 주기 관리 및 크기 조정

Elasticsearch는 기존의 비어 있지 않은 인덱스에서 기본 샤드 수를 변경하는 것을 지원하지 않습니다. 이는 초기 설계 시 기억해야 할 중요한 제약 사항입니다.

인덱스 수명 주기 관리(ILM)의 역할

시계열 데이터(로그, 메트릭)의 경우, 인덱스 수명 주기 관리(ILM) 및 롤오버(Rollover) 기능을 활용하는 것이 모범 사례입니다.

하나의 거대하고 관리하기 어려운 인덱스를 생성하는 대신, 템플릿을 가리키는 롤오버 별칭(rollover alias)을 생성합니다.

핫 페이즈(Hot Phase): 데이터가 현재 활성 인덱스에 기록됩니다. ILM은 크기 또는 연령(예: 40GB에 도달하면 롤오버)을 기반으로 이 인덱스를 모니터링합니다.
롤오버(Rollover): 임계값에 도달하면 Elasticsearch는 템플릿(계산된 기본 샤드 수 포함)을 기반으로 새로운 인덱스를 자동으로 생성하고, 별칭이 새 인덱스를 가리키도록 전환합니다. 이전 인덱스는 다른 단계(웜/콜드)로 이동합니다.

이 접근 방식은 데이터 수명 주기 전반에 걸쳐 일관된 크기와 최적의 성능을 가진 샤드를 유지할 수 있도록 합니다.

리샤딩이 필요한 경우(고급)

예상치 못한 데이터 패턴으로 인해 기존 인덱스가 50GB 권장치를 훨씬 초과하여 커지는 경우, Reindex API를 사용하여 샤드 분산을 수정해야 합니다:

수정된 (최적의) 샤드 구성을 가진 새로운 인덱스를 생성합니다.
Reindex API를 사용하여 크기가 잘못된 이전 인덱스의 모든 데이터를 새 인덱스로 복사합니다.
새 인덱스를 가리키도록 별칭을 업데이트합니다.
이전 인덱스를 삭제합니다.

재색인(Reindexing) 경고: 재색인은 리소스 집약적인 작업입니다. 트래픽이 적은 기간에 일정을 잡아야 하며, 동시에 색인 및 복사 부하를 처리하기에 충분한 클러스터 리소스가 필요합니다.

모범 사례 요약

영역	모범 사례 / 지침
개별 샤드 크기	기본 샤드를 10GB에서 50GB 사이로 유지합니다 (최대 100GB).
문서 수	샤드당 10만 개에서 5백만 개 문서(크기 다음으로 중요)를 목표로 합니다.
클러스터 오버헤드	데이터 노드 힙 1GB당 약 20개의 샤드로 총 샤드 수(기본 + 복제본)를 제한합니다.
인덱스 관리	시계열 데이터의 경우 인덱스 수명 주기 관리(ILM) 및 롤오버(Rollover)를 사용하여 지속적으로 최적의 크기를 유지합니다.
크기 조정	운영 중인 인덱스의 기본 샤드 수를 변경하려고 시도하지 마십시오. Reindex API를 사용하여 데이터를 올바른 크기의 새 인덱스로 마이그레이션합니다.

이러한 크기 지침을 준수하고 ILM을 활용하여 지속적으로 관리함으로써 Elasticsearch 클러스터가 성능, 확장성 및 운영 장애에 대한 복원력을 유지하도록 할 수 있습니다.