4장. 인덱스와 샤드 — 데이터는 어디에 놓이는가

Elasticsearch 운영 사고의 최다 원인은 쿼리가 아니라 샤드 설계 실수입니다. 라우팅, 사이징, 장애 대응까지 — 후회 없는 샤드 설계의 전부를 다룹니다.

4.1 인덱스는 논리, 샤드는 물리

이 구분이 모든 것의 출발점입니다. 인덱스(index)는 사용자가 보는 논리적 이름(products, logs-2026.07.11)이고, 실제 데이터는 인덱스를 쪼갠 샤드(shard)에 저장됩니다. 각 샤드는 3장에서 본 하나의 완전한 Lucene 인덱스이며, 클러스터의 어느 노드에든 배치될 수 있습니다.

# 인덱스 생성 — 샤드 수는 이 순간 결정된다
PUT /logs-2026.07.11
{
  "settings": {
    "number_of_shards": 3,     # primary 수 — 생성 후 변경 불가!
    "number_of_replicas": 1    # replica 수 — 언제든 동적 변경 가능
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "message":    { "type": "text" },
      "level":      { "type": "keyword" }
    }
  }
}

3 primary + replica 1이면 총 6개의 샤드가 생깁니다. 이들이 노드에 어떻게 놓이고, 문서가 어떻게 자기 샤드를 찾아가는지 봅시다.

4.2 Primary vs Replica — 두 개의 얼굴

replica는 고가용성과 읽기 처리량이라는 두 역할을 동시에 수행합니다. replica를 늘리면 검색 QPS는 선형으로 늘지만, 모든 사본에 복제해야 하므로 색인 처리량은 떨어집니다. 이 트레이드오프를 활용한 대표 패턴이 있습니다.

# 대량 초기 적재 패턴: replica 0으로 색인 → 끝나면 복원
PUT /logs-init/_settings
{ "index": { "number_of_replicas": 0 } }

# ... bulk 색인 (복제 비용 없이 최대 처리량) ...

PUT /logs-init/_settings
{ "index": { "number_of_replicas": 1 } }   # 완료된 세그먼트를 통째로 복사

4.3 라우팅 공식 — 문서의 주소 계산

정확한 공식은 split을 대비해 한 단계가 더 있습니다.

# 공식 문서에 명시된 라우팅 공식
routing_factor = num_routing_shards / num_primary_shards
shard_num      = (hash(_routing) % num_routing_shards) / routing_factor

# _routing 기본값 = 문서의 _id
# num_routing_shards는 미래의 split을 위한 여유분 (예: 4 primary에 128)
# → 4 → 8 → 16 ... 128까지 split해도 hash 결과가 유지됨

같은 사용자의 문서를 한 샤드에 모으고 싶다면 ?routing=user_42처럼 custom routing을 쓸 수 있습니다. 검색이 전체 샤드 broadcast 대신 1개 샤드만 조회해 빨라지지만, 특정 키에 데이터가 몰리는 skew(쏠림) 위험을 항상 평가해야 합니다.

4.4 노드 장애 — replica 승격의 순간

replica가 있는 이유를 가장 극적으로 보여주는 시나리오입니다. 노드 하나가 갑자기 사라지면 무슨 일이 벌어질까요?

4.5 샤드 사이징 — 10~50GB의 과학

공식 문서의 가이드는 명확합니다: "샤드 크기는 10GB~50GB, 샤드당 문서 2억 개 이하". 그리고 노드 관점에서는 "JVM heap 1GB당 샤드 20개 이하". 이 범위를 벗어나면 양쪽 어디로든 사고가 납니다.

샤드가 너무 많으면 어떤 파국이 오는지, 2장의 cluster state 지식과 연결해서 봅시다.

시계열 데이터라면 매일 새 인덱스 대신 rollover가 정석입니다. 크기 조건으로 전환하면 샤드가 늘 적정 크기를 유지합니다.

# ILM 정책 — 샤드가 50GB에 도달하면 새 인덱스로 자동 전환
PUT /_ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",   # 공식 권장 패턴
            "max_age": "1d"
          }
        }
      }
    }
  }
}

4.6 사후 도구함 — Shrink · Split · Clone · 그리고 watermark

이미 만들어진 인덱스의 샤드 수를 조정해야 한다면:

• Shrink (샤드 ↓): read-only 전환 + 모든 샤드 사본을 한 노드에 모은 뒤, hard link로 복사 없이 새 인덱스 생성. 새 primary 수는 기존의 약수(8→4, 2, 1).
• Split (샤드 ↑): num_routing_shards 여유분 안에서 배수로 증가(1→2→4→8...).
• Clone: 같은 설정의 사본. 백업·실험용.
• Reindex: 매핑·설정까지 바꿀 수 있는 만능 도구지만 모든 데이터를 다시 색인하므로 가장 느립니다.

# shrink 예: 8 shards → 1 shard
PUT /my-index/_settings
{
  "settings": {
    "index.routing.allocation.require._name": "node-1",  # 한 노드로 모으기
    "index.blocks.write": true                             # read-only
  }
}
POST /my-index/_shrink/my-index-shrunk
{ "settings": { "index.number_of_shards": 1 } }

✍️ 이해도 체크