카테고리 없음

[LV 4] 클러스터 및 샤드 최적화

JABHACK 2025. 2. 2. 14:07

클러스터 및 샤드 최적화

📌 Elasticsearch는 분산형 검색 엔진으로, 데이터를 여러 **노드(Node)**와 **샤드(Shard)**에 분산하여 저장합니다.
효율적인 클러스터 운영을 위해 클러스터 상태 모니터링, 샤드 개수 최적화, 장애 복구, Split Brain 방지 등의 전략이 필요합니다.

클러스터 상태 확인

클러스터의 현재 상태를 점검하는 것은 성능 최적화 및 문제 해결의 첫 단계입니다.

✅ (1) 클러스터 노드 상태 확인 (_cat/nodes)

GET _cat/nodes?v
IP 노드명 역할 상태 CPU(%) 메모리 사용률
192.168.1.10 node-1 master 정상 42% 70%
192.168.1.11 node-2 data 정상 35% 65%
192.168.1.12 node-3 data 정상 50% 75%

✅ 각 노드의 역할(Master, Data, Ingest), CPU 사용률, 메모리 상태 확인 가능.

✅ (2) 클러스터 상태 확인 (_cluster/health)

GET _cluster/health

🔹 응답 예시

{
  "cluster_name": "my-cluster",
  "status": "yellow",
  "number_of_nodes": 3,
  "number_of_data_nodes": 2,
  "active_primary_shards": 5,
  "active_shards": 10,
  "unassigned_shards": 1
}

✅ "status":

  • "green" → 모든 샤드가 정상적으로 할당됨.
  • "yellow" → 일부 복제본(Replica)이 할당되지 않음.
  • "red" → 일부 프라이머리 샤드(Primary Shard) 할당 불가(데이터 손실 가능).

✅ (3) 샤드 상태 확인 (_cat/shards)

GET _cat/shards?v

인덱스 샤드 번호 상태 노드명 역할

logs-2024 0 STARTED node-2 primary
logs-2024 1 UNASSIGNED - replica

✅ "UNASSIGNED"가 있는 경우 일부 샤드가 정상적으로 복구되지 않은 상태 → allocation explain API 활용.

샤드 개수 설정 (number_of_shards, number_of_replicas)

Elasticsearch의 인덱스는 기본적으로 **프라이머리 샤드(Primary Shard)와 복제본 샤드(Replica Shard)**로 구성됩니다.

✅ (1) 샤드 개수 설정

PUT /logs-2024
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}

✅ 프라이머리 샤드 3개, 복제본 1개 설정 → 총 6개 샤드(3 * (1+1) = 6).

✅ (2) 기존 인덱스의 복제본 개수 변경

PUT /logs-2024/_settings
{
  "number_of_replicas": 2
}

✅ 실행하면 모든 프라이머리 샤드에 대해 복제본 2개가 생성됨.
(주의: number_of_shards는 인덱스 생성 후 변경 불가능, number_of_replicas는 변경 가능)

✅ (3) 샤드 개수 설정 Best Practice

환경 샤드 개수
작은 인덱스 (100MB 이하) 1개 샤드 (샤드가 많으면 오버헤드 증가)
중간 규모 인덱스 (수십 GB) 3~5개 샤드
대규모 인덱스 (수백 GB~TB) 노드 수 × 2 개수의 샤드

✅ 너무 많은 샤드는 클러스터 성능을 저하시킬 수 있음.
✅ 샤드 크기가 너무 작으면 오버헤드 발생, 너무 크면 검색 성능 저하.
✅ 권장 샤드 크기: 10GB ~ 50GB.

3. 노드 장애 발생 시 복구 (_cluster/allocation/explain)

노드 장애가 발생하면 일부 샤드가 할당되지 않음(UNASSIGNED) 상태가 될 수 있습니다.
이때 allocation explain API를 사용하여 왜 샤드가 할당되지 않는지 확인 가능.

✅ (1) 샤드 할당 문제 분석

GET _cluster/allocation/explain

🔹 응답 예시

{
  "index": "logs-2024",
  "shard": 1,
  "primary": false,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "NODE_LEFT",
    "last_allocation_status": "no_attempt"
  }
}

✅ "reason": "NODE_LEFT" → 특정 노드가 클러스터에서 이탈하여 샤드 할당 불가.

✅ (2) 할당되지 않은 샤드 수동 복구

POST _cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "logs-2024",
        "shard": 1,
        "node": "node-2",
        "accept_data_loss": true
      }
    }
  ]
}

✅ "allocate_stale_primary" 옵션을 사용하여 강제로 샤드 재할당.

⚠ 주의: accept_data_loss: true 사용 시 데이터 손실 가능성이 있음.

Split Brain 문제 방지 (minimum_master_nodes 설정)

📌 Split Brain 문제란?

  • 마스터 노드가 여러 개로 분리되면서 클러스터가 정상적으로 동작하지 않는 현상.
  • 마스터 노드 간 네트워크 장애가 발생하면 각각 독립적인 클러스터가 생길 위험.
  • 이를 방지하려면 마스터 노드 수 설정이 중요.

✅ (1) 마스터 노드 개수 설정

Elasticsearch 7.0 이상에서는 minimum_master_nodes가 자동으로 관리됨.
하지만 7.0 미만 버전에서는 수동 설정이 필요.

discovery.zen.minimum_master_nodes: 2

✅ 마스터 노드가 최소 2개 이상 있어야 클러스터 유지 가능.

마스터 노드 개수에 따른 설정 값

마스터 노드 수 minimum_master_nodes 값
1 1
2 2
3 2
5 3

✅ 일반적으로 마스터 노드 개수는 홀수(3개 이상)를 유지하는 것이 좋음.

클러스터 및 샤드 최적화 정리

기능 설명
클러스터 상태 확인 _cat/nodes, _cluster/health, _cat/shards API 사용
샤드 개수 설정 number_of_shards, number_of_replicas 최적화
노드 장애 복구 _cluster/allocation/explain API로 문제 확인 후 수동 복구
Split Brain 방지 minimum_master_nodes 설정 (7.x 이상 자동 처리)

 

저작자표시 비영리 동일조건 (새창열림)