최적의 샤드 크기 조정: 클러스터 성능 및 관리 균형

최적의 샤드 크기 조정: 클러스터 성능과 관리의 균형

강력한 분산 검색 및 분석 엔진인 엘라스틱서치는 노드 간에 데이터를 효율적으로 관리하고 분산하는 능력에 크게 의존합니다. 이러한 분산의 핵심 구성 요소는 바로 샤드 개념입니다. 샤드는 인덱스를 더 작고 관리하기 쉬운 조각으로 나눈 것이며, 샤드의 크기를 어떻게 정하고 분산하는지에 따라 클러스터의 성능, 확장성 및 관리 용이성에 지대한 영향을 미칩니다. 이 문서는 엘라스틱서치에서 최적의 샤드 크기를 결정하기 위한 중요한 고려 사항을 심층적으로 다루며, 순수 성능과 운영 오버헤드 사이에서 적절한 균형을 찾는 데 도움을 줄 것입니다.

샤드 크기 조정에 대한 이해는 모든 엘라스틱서치 배포에 있어 필수적입니다. 너무 많은 작은 샤드는 오버헤드를 증가시켜 노드 리소스와 쿼리 지연 시간에 영향을 줄 수 있습니다. 반대로 너무 적은 큰 샤드는 확장성을 저해하고 핫스팟을 생성하며 복구 작업을 길게 만들 수 있습니다. 이 가이드는 샤드 할당에 대해 정보에 입각한 결정을 내리는 데 필요한 지식과 실질적인 전략을 제공하여 보다 효율적이고 견고한 엘라스틱서치 클러스터를 구축하는 데 기여할 것입니다.

엘라스틱서치 샤드의 기본 원리

크기 조정 전략에 깊이 들어가기 전에, 기본 개념을 이해하는 것이 중요합니다.

인덱스: 문서들의 컬렉션입니다. 엘라스틱서치에서 인덱스는 여러 샤드로 나뉩니다.
샤드: 분산의 단위입니다. 각 샤드는 독립적인 루씬(Lucene) 인덱스입니다. 하나의 인덱스는 클러스터의 여러 노드에 분산된 여러 샤드를 포함할 수 있습니다.
프라이머리 샤드: 인덱스가 생성될 때, 고정된 수의 프라이머리 샤드가 할당됩니다. 이 샤드들은 데이터가 인덱싱되는 곳입니다. 일단 생성되면 프라이머리 샤드의 수는 변경할 수 없습니다. 하지만 레플리카 샤드는 더 추가할 수 있습니다.
레플리카 샤드: 프라이머리 샤드의 복사본입니다. 이는 이중화를 제공하고 읽기 처리량을 늘립니다. 프라이머리 샤드가 실패하면 레플리카가 프라이머리로 승격될 수 있습니다. 레플리카 샤드의 수는 언제든지 변경할 수 있습니다.

샤드가 성능에 미치는 영향

인덱싱 성능: 각 샤드는 인덱싱을 위해 리소스를 필요로 합니다. 샤드가 많아질수록 요청을 관리하는 코디네이팅 노드에 대한 오버헤드가 증가합니다. 그러나 샤드가 너무 커지면 단일 샤드에 대한 인덱싱이 병목 현상이 될 수 있습니다.
쿼리 성능: 검색 요청은 모든 관련 프라이머리 샤드에 분산됩니다. 샤드 수가 많으면 처리해야 하는 요청 수가 늘어나 잠재적으로 지연 시간이 증가할 수 있습니다. 반대로 샤드가 매우 크면 루씬이 해당 샤드 내의 더 많은 데이터를 처리해야 하므로 검색 시간이 길어질 수 있습니다.
클러스터 관리: 샤드 수가 많으면 클러스터 상태 관리를 담당하는 마스터 노드의 부하가 증가합니다. 또한 샤드 재배치, 스냅샷, 복구와 같은 작업의 오버헤드에도 영향을 미칩니다.
리소스 활용: 각 샤드는 메모리 및 디스크 I/O를 소비합니다. 너무 많은 샤드는 노드 리소스를 고갈시켜 성능 저하 또는 노드 불안정으로 이어질 수 있습니다.

샤드 크기 조정의 주요 고려 사항

"이상적인" 샤드 크기는 고정된 숫자가 아닙니다. 이는 특정 워크로드, 데이터 특성 및 하드웨어에 따라 달라집니다. 그러나 몇 가지 요소가 결정에 지침이 되어야 합니다.

1. 데이터 볼륨 및 증가율

현재 데이터 크기: 현재 인덱스에 얼마나 많은 데이터가 있습니까?
증가율: 데이터가 얼마나 빠르게 증가하고 있습니까? 이는 미래 샤드 크기를 예측하는 데 도움이 됩니다.
데이터 보존 정책: 오래된 데이터를 삭제할 예정입니까? 이는 활성 데이터의 실제 크기에 영향을 미칩니다.

2. 인덱싱 부하

인덱싱 비율: 초당 몇 개의 문서를 인덱싱합니까?
문서 크기: 개별 문서의 평균 크기는 어느 정도입니까?
인덱싱 처리량: 현재 샤드 구성으로 노드가 인덱싱 부하를 처리할 수 있습니까?

3. 쿼리 패턴

쿼리 복잡성: 쿼리가 단순한 키워드 검색입니까, 아니면 복잡한 집계입니까?
쿼리 빈도: 데이터에 대해 쿼리가 얼마나 자주 실행됩니까?
쿼리 지연 시간 요구 사항: 허용 가능한 응답 시간은 얼마입니까?

4. 클러스터 토폴로지 및 리소스

노드 수: 클러스터에 몇 개의 노드가 있습니까?
노드 하드웨어: CPU, RAM 및 디스크 (엘라스틱서치에는 SSD를 강력히 권장합니다).
노드당 샤드 제한: 엘라스틱서치에는 성능 문제를 방지하기 위해 노드가 보유할 수 있는 최대 샤드 수에 대한 기본 제한이 있습니다. 이는 cluster.routing.allocation.total_shards_per_node (기본값은 1000)에 의해 제어됩니다. 실제 샤드 수가 이 제한보다 훨씬 낮게 유지하는 것이 좋습니다.

샤드 할당을 위한 모범 사례

1. 목표 샤드 크기 설정

마법의 숫자는 없지만, 일반적으로 권장되는 목표 샤드 크기는 10GB에서 50GB 사이입니다. 이 범위는 종종 좋은 균형을 나타냅니다.

너무 작음 (< 10GB): 과도한 오버헤드를 유발할 수 있습니다. 각 샤드는 메모리 공간을 차지하고 마스터 노드의 부하에 기여합니다. 수천 개의 작은 샤드를 관리하는 것은 상당한 운영 부담이 됩니다.
너무 큼 (> 50GB): 성능 문제를 일으킬 수 있습니다. 세그먼트 병합, 복구 및 리밸런싱 작업에 더 오랜 시간이 걸립니다. 대형 샤드가 실패하면 복구하는 데 상당한 시간이 걸릴 수 있습니다.

2. 시간 기반 인덱스 고려

시계열 데이터(로그, 메트릭, 이벤트)의 경우, 시간 기반 인덱스를 사용하는 것이 표준적이고 매우 효과적인 방법입니다. 이는 특정 기간(예: 일별, 주별, 월별)에 대한 새 인덱스를 생성하는 것을 포함합니다.

예: 하나의 거대한 인덱스 대신 logs-2023.10.26, logs-2023.10.27 등이 있을 수 있습니다.
이점: 인덱스 라이프사이클 관리(ILM)를 통한 쉬운 데이터 관리(오래된 인덱스 삭제), 쿼리가 종종 최신 데이터를 대상으로 하므로 더 나은 성능, 제어된 샤드 크기.

3. 인덱스 라이프사이클 관리 (ILM) 구현

ILM 정책을 사용하면 기간, 크기 또는 문서 수에 따라 인덱스 관리를 자동화할 수 있습니다. 인덱스에 대한 단계(핫, 웜, 콜드, 삭제)를 정의하고 각 단계에 대한 작업(레플리카 수 변경, 인덱스 축소 또는 삭제 포함)을 지정할 수 있습니다.

핫 단계: 인덱스가 활발하게 쓰여지고 쿼리됩니다. 성능을 최대화합니다.
웜 단계: 인덱스에 더 이상 쓰여지지 않지만 여전히 쿼리됩니다. 성능이 낮은 하드웨어로 이동하거나, 레플리카 수를 줄이거나 축소할 수 있습니다.
콜드 단계: 드물게 쿼리됩니다. 데이터를 더 저렴한 스토리지로 이동하거나, 레플리카 수를 더 줄이거나 동결할 수 있습니다.
삭제 단계: 더 이상 필요하지 않은 데이터는 삭제됩니다.

4. 과도한 샤딩 방지

과도한 샤딩(over-sharding)은 클러스터 크기 및 데이터 볼륨에 비해 너무 많은 샤드를 가질 때 발생합니다. 이는 성능 저하 및 관리 문제로 이어지는 일반적인 함정입니다.

증상: 마스터 노드의 높은 CPU 사용량, 느린 클러스터 상태 업데이트, 긴 복구 시간, 전반적인 느려짐.
완화: 처음부터 프라이머리 샤드 수를 계획하십시오. 시간 기반 인덱스의 경우, 인덱스당 합리적인 수의 프라이머리 샤드(예: 1 또는 3)로 시작하십시오. 레플리카는 나중에 항상 추가할 수 있습니다.

5. 과도한 인덱싱 피하기

마찬가지로, 불필요하게 과도한 수의 인덱스를 생성하지 마십시오. 각 인덱스는 오버헤드를 추가합니다. 자연스러운 파티셔닝 메커니즘이 없는 비시계열 데이터의 경우, 적절한 샤드 수를 가진 단일 인덱스로 충분한지 고려하십시오.

6. `number_of_shards` 설정 고려

인덱스를 생성할 때 number_of_shards 매개변수는 프라이머리 샤드의 수를 정의합니다. 이 설정은 인덱스 생성 후 변경할 수 없습니다.

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // 예: 3개의 프라이머리 샤드
      "number_of_replicas": 1   // 예: 1개의 레플리카 샤드
    }
  }
}

팁: 더 작은 인덱스나 인덱싱/쿼리 부하가 매우 낮은 인덱스의 경우, 단일 프라이머리 샤드로 충분할 수 있습니다. 더 크고 활성적인 인덱스의 경우, 3개 또는 5개의 프라이머리 샤드가 더 나은 분산 및 복원력 옵션을 제공할 수 있습니다. 특히 나중에 인덱스를 분할할 계획이라면 더욱 그렇습니다(분할은 복잡하지만).

7. 리밸런싱 및 재배치

엘라스틱서치는 노드 간의 균등한 분산을 보장하기 위해 자동으로 샤드를 리밸런싱합니다. 그러나 샤드가 너무 크면 이러한 작업은 리소스 집약적이고 느릴 수 있습니다. 작고 더 많은 샤드는 때때로 더 빠르게 리밸런싱될 수 있지만, 이는 더 많은 샤드를 관리하는 오버헤드에 의해 상쇄됩니다.

8. 쿼리 성능 튜닝

쿼리 성능이 저하되는 경우 샤드 전략을 평가하십시오. 다음을 고려하십시오:

샤드 수: 샤드 수가 너무 많으면 조정 오버헤드가 증가할 수 있습니다.
샤드 크기: 샤드가 매우 크면 세그먼트 병합 및 샤드 내 검색 속도가 느려질 수 있습니다.
인덱스 설계: 적절한 매핑과 분석기를 사용하고 있습니까?

최적의 샤드 수 계산

단일 공식은 없지만, 일반적인 접근 방식은 다음과 같습니다:

인덱스 라이프사이클 동안의 총 데이터 볼륨을 추정합니다.
목표 샤드 크기를 결정합니다 (예: 30GB).
필요한 프라이머리 샤드 수를 계산합니다: 총 데이터 볼륨 / 목표 샤드 크기.
가장 가까운 정수로 올림 합니다. 이것이 인덱스의 number_of_shards가 됩니다.
- 예: 90GB의 데이터를 예상하고 30GB 샤드를 목표로 한다면, 90GB / 30GB = 3개의 프라이머리 샤드가 필요합니다.
복원력 및 분산을 고려합니다: 중요 인덱스의 경우, 초기 데이터 볼륨이 엄격하게 필요하지 않더라도 더 나은 분산 및 복구 옵션을 위해 3개 또는 5개의 프라이머리 샤드를 사용하는 것을 고려하십시오. 이에 대한 절충안은 오버헤드 증가입니다.
보수적으로 시작합니다: 레플리카를 추가하는 것이 프라이머리 샤드 수를 변경하는 것(일반적으로 재인덱싱 또는 복잡한 해결 방법 필요)보다 일반적으로 쉽습니다. 확실하지 않은 경우, 더 적은 프라이머리 샤드로 시작하고 성능을 모니터링하십시오.

예시 시나리오: 로그 분석

애플리케이션 로그를 인덱싱한다고 가정해 봅시다:

데이터 볼륨: 월별 1TB의 로그를 예상합니다.
데이터 보존: 30일 동안 로그를 유지합니다.
목표 샤드 크기: 20GB를 목표로 합니다.
일별 인덱스: 일별 인덱스(logstash-YYYY.MM.DD)를 생성합니다. 각 일별 인덱스는 약 1TB / 30일 ≈ 33GB의 데이터를 포함합니다.
인덱스당 프라이머리 샤드: 20GB 목표와 33GB 일일 볼륨을 감안할 때, 인덱스당 2개의 프라이머리 샤드(33GB / 20GB ≈ 1.65, 올림하여 2)를 선택할 수 있습니다. 이는 개별 샤드가 목표 크기 내에 유지되도록 보장합니다.
레플리카: 고가용성을 위해 1개의 레플리카를 결정합니다.
총 샤드: 30일 보존 기간 동안, 30개의 인덱스가 있으며 각 인덱스는 2개의 프라이머리 샤드와 2개의 레플리카 샤드를 가지므로, 특정 시점에 총 60개의 프라이머리 샤드와 60개의 레플리카 샤드가 활성화됩니다.

이 접근 방식은 개별 샤드를 관리하기 쉽게 유지하고 오래된 인덱스를 삭제하는 것만으로 효율적인 데이터 삭제를 가능하게 합니다.

결론

엘라스틱서치에서 최적의 샤드 크기 조정은 끊임없는 균형 잡기입니다. 샤드 수, 샤드 크기, 인덱싱 부하, 쿼리 패턴 및 클러스터 리소스 간의 상호 작용을 이해함으로써 정보에 입각한 결정을 내릴 수 있습니다. 시계열 데이터에는 시간 기반 인덱스를 우선시하고, 자동화된 관리를 위해 ILM을 활용하며, 항상 샤드 관리의 운영 오버헤드를 염두에 두십시오. 과도한 샤딩을 피하면서 10GB에서 50GB 사이의 샤드 크기를 목표로 하는 것이 견고한 출발점입니다. 정기적인 모니터링 및 성능 튜닝은 데이터가 증가함에 따라 엘라스틱서치 클러스터가 효율적이고 확장 가능하며 복원력을 유지하도록 보장할 것입니다.