Shard Allocation Awareness — '어디에 갈 수 있는가'가 아니라 '어떻게 흩어질 것인가'
Elasticsearch Shard Allocation Awareness 및 Shard Request Cache 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(shard-allocation-awareness, shard-request-cache) Elastic 공식문서 Shard allocation awareness
이 모듈을 다 읽으면
- Allocation Awareness가 elasticsearch-learn-30의 Allocation Filtering과 목적이 어떻게 다른지 구분할 수 있다
- forced awareness가 기본 동작(가용 위치로 재분산)과 어떻게 다른지 설명할 수 있다
elasticsearch-learn-30에서 다룬 샤드 할당 필터링(특정 노드로 가는 걸 명시적으로 허용·차단)과 달리, Allocation Awareness는 프라이머리와 그 레플리카가 물리적으로 같은 장애 단위(랙·존)에 몰리지 않도록 '분산 방식'을 조정하는 별개 기능이다.
필터링과는 다른 목적 — '분산의 질'을 높인다
elasticsearch-learn-30의 Allocation Filtering(include/exclude/require)은 '이 샤드가 어떤 노드에 갈 수 있는지 없는지'를 명시적으로 통제하는 기능이다. Allocation Awareness는 이와 목적이 다르다 — cluster.routing.allocation.awareness.attributes로 커스텀 노드 속성(예: rack_id, zone)을 awareness 속성으로 지정하면, Elasticsearch가 물리적 배치(어느 노드가 같은 서버·랙·존에 있는지)를 인식해서 프라이머리 샤드와 그 레플리카를 서로 다른 랙·존에 분산 배치하려고 시도한다 — 장애 하나가 그 샤드의 모든 사본을 동시에 잃게 만드는 위험을 최소화하려는 목적이다.
핵심 포인트
- Allocation Filtering(module30): 특정 노드로 갈 수 있는지 없는지를 명시적으로 통제
- Allocation Awareness: 프라이머리·레플리카가 같은 물리적 장애 단위(랙·존)에 몰리지 않게 분산 방식을 조정 — cluster.routing.allocation.awareness.attributes로 노드 속성(rack_id 등) 지정
기본 동작 vs forced awareness — '위치 하나가 죽으면'의 대응이 다르다
기본적으로 awareness가 켜져 있어도, 한 위치(예: 특정 랙)가 통째로 사라지면 Elasticsearch는 남은 위치들에 샤드를 다시 흩뿌려서라도(설령 그 결과 같은 샤드의 사본 여러 개가 한 곳에 모이게 되더라도) 가용성을 우선시한다. forced awareness를 켜면 이 기본 동작이 바뀐다 — 특정 샤드의 여러 사본이 같은 위치에 함께 배치되는 것을 아예 막아버려서, 어떤 상황에서도 '같은 랙에 프라이머리와 레플리카가 함께 있는' 상태를 허용하지 않는다.
핵심 포인트
- 기본 동작: 한 위치가 사라지면 남은 위치로 재분산 우선(같은 샤드 사본이 한 곳에 몰리는 결과가 나올 수도 있음) — 가용성 우선
- forced awareness: 어떤 상황에서도 같은 샤드의 여러 사본이 같은 위치에 함께 배치되는 것을 아예 금지