클러스터 상태와 스냅샷/복구 — 운영 관점
Elasticsearch 벡터 검색(kNN/HNSW) 및 클러스터 운영(상태·스냅샷) 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(dense-vector, knn, cluster-health, red-yellow-cluster-status) 종합 Elastic 공식 문서 cluster-health, red-yellow-cluster-status, snapshot-restore
이 모듈을 다 읽으면
- 클러스터 상태 green/yellow/red가 각각 무엇을 의미하는지 설명할 수 있다
- 스냅샷이 증분(incremental) 방식으로 동작하는 원리를 설명할 수 있다
elasticsearch-learn-01의 샤드/레플리카 개념을 전제로, 클러스터 상태 신호를 해석하는 법과 백업·복구 메커니즘인 스냅샷을 정리한다.
클러스터 상태 — green / yellow / red
green은 모든 프라이머리와 레플리카 샤드가 정상 할당된 상태다. yellow는 모든 프라이머리 샤드는 할당돼 있어 데이터 자체는 온전하지만, 레플리카 샤드 중 일부가 할당 안 된 상태다(예: 노드가 하나 죽어서 그 노드에 있던 레플리카를 다른 곳에 아직 못 만든 경우) — 서비스는 계속되지만 장애 대비 여유(redundancy)가 줄어든 상태다. red는 프라이머리 샤드 자체가 할당 안 된 상태로, 그 샤드가 담당하던 데이터의 일부가 실제로 조회 불가능해진다 — 즉시 조치가 필요한 심각한 상태다. 미할당 샤드(unassigned shard)의 원인은 노드 장애, 디스크 공간 부족, 샤드 배치 규칙(allocation rule) 충돌 등 다양하며, GET _cat/shards API로 원인을 조회할 수 있다.
핵심 포인트
- green: 전부 정상 / yellow: 프라이머리는 정상, 레플리카 일부 미할당(서비스 지속, 여유 감소) / red: 프라이머리 미할당(데이터 일부 조회 불가, 즉시 조치 필요)
- 미할당 샤드 원인: 노드 장애, 디스크 공간 부족, 배치 규칙 충돌 등 — GET _cat/shards로 진단
스냅샷 — 증분 백업의 원리
Elasticsearch 스냅샷은 매번 전체 데이터를 통째로 복사하는 게 아니라 증분(incremental) 방식으로 동작한다 — elasticsearch-learn-02에서 다룬 Lucene 세그먼트의 불변(immutable) 특성이 여기서 핵심적으로 활용된다. 세그먼트는 한 번 쓰이면 안 바뀌므로, 새 스냅샷을 찍을 때는 '이전 스냅샷 이후 새로 생긴 세그먼트만' 저장소(S3/HDFS/공유 파일시스템 등)에 복사하고, 이미 이전 스냅샷에 올라가 있는 세그먼트는 그대로 재사용(참조)한다. 이 덕분에 자주(예: 매시간) 스냅샷을 찍어도 디스크/스토리지 사용량이 크게 늘지 않는다. 스냅샷을 삭제할 때도 그 스냅샷만 참조하던 세그먼트만 실제로 지우고, 다른 스냅샷이 아직 참조하는 세그먼트는 남겨둔다(디듀플리케이션).
핵심 포인트
- 스냅샷은 증분 방식 — Lucene 세그먼트의 불변성을 이용해 '새로 생긴 세그먼트만' 저장소에 추가한다
- 자주 스냅샷을 찍어도 디스크 사용량이 크게 늘지 않는 이유가 바로 이 증분+세그먼트 재사용 구조
- 스냅샷 삭제 시에도 다른 스냅샷이 참조 중인 세그먼트는 남기고 그 스냅샷만 쓰던 것만 제거(디듀플리케이션)