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

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

이 Elasticsearch 샤드 크기 조정 가이드는 초기 샤드 수를 선택하고 실제 워크로드 메트릭으로 검증하는 실용적인 방법을 제공합니다. 목표는 완벽한 숫자가 아니라 데이터가 증가함에 따라 복구 가능하고, 검색 가능하며, 비용 효율적인 샤드 레이아웃을 유지하는 것입니다.

Elasticsearch 샤드 이해하기

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

기본 샤드 vs 복제본 샤드

기본 샤드: 실제 데이터를 보유합니다. 인덱싱 및 검색 작업을 담당합니다. 인덱스에 대한 기본 샤드 수를 정의하면 데이터가 클러스터 전체에 수평으로 분산되는 방식을 결정합니다.
복제본 샤드: 기본 샤드의 복사본입니다. 중복성(내결함성)을 제공하고 쿼리가 기본 및 복제본 모두에서 제공될 수 있도록 하여 검색 처리량을 증가시킵니다.

샤드 수의 영향

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

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

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

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

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

일반적인 목표 범위: 많은 프로덕션 클러스터는 기본 샤드를 10GB에서 50GB 범위로 목표로 합니다.
대형 샤드 주의: 더 큰 샤드는 일부 추가 전용 또는 낮은 쿼리 워크로드에서 작동할 수 있지만 복구 시간이 증가하고 재배치 비용이 더 많이 듭니다. 100GB 이상의 샤드에 의존하기 전에 테스트하십시오.

왜 제한이 필요한가? 노드가 실패하면 Elasticsearch는 해당 노드에 저장된 샤드를 재할당(재배치 또는 재복제)해야 합니다. 큰 샤드는 복구에 필요한 시간을 크게 증가시켜 복원력이 감소하는 기간을 늘립니다. 또한 Lucene은 중간 크기의 세그먼트를 관리할 때 더 나은 성능을 보입니다.

2. 문서 수 임계값

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

샤드당 보편적인 안전 문서 수는 없습니다. 수백만 개의 작은 로그 문서가 있는 샤드는 잘 작동할 수 있지만, 더 적은 수의 크고 분석이 많이 된 문서가 있는 샤드는 비용이 많이 들 수 있습니다. 문서 수에만 의존하지 말고 샤드 저장소 크기와 워크로드 동작을 모두 추적하십시오.

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

리소스 소비를 효과적으로 관리하려면 노드당 총 샤드 수를 제한하십시오.

이전 지침에서는 종종 GB 힙당 샤드 규칙을 사용했습니다. 이를 엄격한 제한이 아닌 대략적인 경고 신호로 취급하십시오. 최신 Elasticsearch는 이전 릴리스보다 샤드당 힙 오버헤드가 낮지만 너무 많은 샤드는 여전히 클러스터 상태 작업, 파일 핸들, 세그먼트 오버헤드 및 복구 복잡성을 증가시킵니다.

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

다음 단계를 사용하여 예상 총 데이터 크기를 기반으로 새 인덱스에 대한 적절한 기본 샤드 수를 계산하십시오.

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

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

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

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

지침(예: 40GB)에 따라 안전한 목표 크기를 선택합니다.

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

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

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

$$\text{기본 샤드 수} = \text{Ceiling} \left( \frac{\text{총 인덱스 크기}}{\text{목표 샤드 크기}} \right)$$

예시 계산 (2TB = 2048GB): $$\text{기본 샤드 수} = \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단계: 노드 간 분산

클러스터에 이러한 샤드를 효과적으로 호스팅할 수 있는 충분한 노드, 힙, 디스크 및 I/O 용량이 있는지 확인합니다. 복제본의 경우 Elasticsearch는 각 복제본을 기본 샤드와 다른 노드에 배치할 수 있어야 합니다.

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

Elasticsearch는 기존 인덱스에서 index.number_of_shards를 직접 변경할 수 없습니다. 분할, 축소 또는 재색인 워크플로를 사용할 수 있지만 각각 요구 사항과 운영 비용이 있습니다.

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

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

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

핫 단계: 데이터가 현재 활성 인덱스에 기록됩니다. ILM은 크기 또는 기간(예: 40GB에 도달하면 롤오버)에 따라 이 인덱스를 모니터링합니다.
롤오버: 임계값이 충족되면 Elasticsearch는 템플릿(계산된 기본 샤드 수 사용)을 기반으로 새 인덱스를 자동으로 생성하고 별칭이 새 인덱스를 가리키도록 전환합니다. 이전 인덱스는 다른 단계(웜/콜드)로 이동합니다.

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

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

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

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

재색인 경고: 재색인은 리소스 집약적인 작업입니다. 트래픽이 적은 시간에 예약해야 하며 인덱싱 및 복사의 동시 로드를 처리할 수 있는 충분한 클러스터 리소스가 필요합니다.

모범 사례 요약

영역	모범 사례 / 지침
개별 샤드 크기	기본 샤드를 10GB에서 50GB 사이로 유지합니다(최대 100GB).
문서 수	문서 수를 보조 신호로 모니터링하지만 쿼리 및 인덱싱 메트릭으로 검증합니다.
클러스터 오버헤드	힙 압력, 클러스터 상태 업데이트 및 복구가 정상 상태를 유지할 수 있도록 샤드 수를 충분히 낮게 유지합니다.
인덱스 관리	시계열 데이터의 경우 인덱스 수명 주기 관리(ILM) 및 롤오버를 사용하여 지속적인 최적 크기 조정을 보장합니다.
크기 조정	라이브 인덱스에서 기본 샤드 수를 변경하려고 시도하지 말고 재색인 API를 사용하여 올바르게 크기가 조정된 새 인덱스로 데이터를 마이그레이션합니다.

목표 샤드 크기로 시작하고 예상 데이터 볼륨에서 기본 샤드를 계산한 다음 부하 테스트 및 프로덕션 메트릭으로 검증합니다. 시계열 데이터의 경우 ILM 롤오버는 지속적인 수동 개입 없이 샤드 크기를 예측 가능하게 유지하는 가장 깔끔한 방법입니다.