2장. 클러스터 아키텍처 — 노드들은 어떻게 한 팀이 되는가

마스터는 지휘하고, 데이터 노드는 일하고, coordinating 노드는 교통정리를 합니다. 이후 모든 트러블슈팅과 용량 산정은 이 장의 모델 위에서 이루어집니다.

2.1 노드 역할 — 한 노드는 하나의 프로세스가 아니라 "역할의 집합"

Elasticsearch 노드는 node.roles 설정으로 결정되는 하나 이상의 역할을 갖습니다. 소규모에서는 한 노드가 모든 역할을 겸하지만, 규모가 커지면 역할을 분리하는 것이 운영의 기본입니다.

# elasticsearch.yml — 역할별 노드 설정 예

# 마스터 전용 노드: 데이터/검색 부하로부터 격리
node.roles: [ master ]

# hot 데이터 노드: 최신 데이터 색인 + 검색 + 전처리
node.roles: [ data_hot, data_content, ingest ]

# coordinating-only 노드: 역할을 전부 비운다
node.roles: [ ]

시계열 데이터(로그·메트릭)는 Hot → Warm → Cold → Frozen 순으로 값싼 하드웨어로 이동시키는 것이 표준 패턴입니다. 데이터가 오래될수록 검색 빈도가 급감하기 때문에, 비용/성능 곡선을 따라 내려보내는 것이죠. 이 이동은 ILM(Index Lifecycle Management)이 자동화합니다.

2.2 Cluster State — 클러스터의 단일 진실

Cluster state는 클러스터의 모든 메타데이터를 담은 하나의 자료구조입니다. 인덱스 설정과 매핑, 샤드가 어느 노드에 있는지, 노드 목록과 역할, ILM 정책까지 전부 여기 들어 있습니다. 그리고 이 정보의 단일 진실 공급자(single source of truth)는 마스터 노드입니다.

2.3 Discovery — 노드들이 서로를 찾는 법

노드는 마법처럼 서로를 찾지 않습니다. 각 노드는 마스터 후보 노드의 주소 목록을 알고 시작해야 합니다. 7.0부터 도입된 새 Discovery 체계의 핵심 설정은 두 가지입니다.

# elasticsearch.yml

# (1) 같은 cluster.name을 가진 노드만 합류할 수 있다
cluster.name: prod-logs

# (2) seed_hosts — 처음 접속해 볼 마스터 후보들의 주소 (상시 유지)
discovery.seed_hosts:
  - master-1.es.internal
  - master-2.es.internal
  - master-3.es.internal

# (3) initial_master_nodes — "최초 부트스트랩" 한 번만 사용!
# 클러스터가 형성된 후에는 모든 노드의 yaml에서 제거할 것
cluster.initial_master_nodes:
  - master-1
  - master-2
  - master-3

2.4 마스터 선출 — 왜 하필 3대인가

마스터 선출은 Raft에서 영감을 받은 합의 프로토콜로 동작합니다. 선출에 투표하는 마스터 후보들의 집합을 voting configuration이라 하고, 이 집합의 과반수(strict majority)가 동의해야 마스터가 정해집니다. 과반수 규칙이 있어야 네트워크가 반으로 갈라져도 두 쪽이 동시에 마스터를 뽑는 사태(split-brain)를 막을 수 있습니다.

7.x 이후 voting configuration은 노드가 추가/제거될 때 자동으로 조정됩니다. 다만 장애 상황에서 stale하게 남으면 POST _cluster/voting_config_exclusions로 수동 개입이 필요할 수 있습니다.

2.5 요청 라우팅 — coordinating 노드에서 샤드로 fan-out

클라이언트 요청은 어느 노드로 보내도 됩니다. 요청을 받은 노드가 그 순간 coordinating node가 되어 교통정리를 맡습니다. 검색은 Query then Fetch라는 2단계로 처리됩니다.

색인(쓰기) 요청은 경로가 다릅니다. coordinating 노드가 hash(_id) % 샤드 수로 단 하나의 primary 샤드를 찾아 전달하고, primary가 색인 후 모든 in-sync replica에 동기 복제합니다. 모든 사본의 ack를 받은 뒤에야 클라이언트에 응답하므로, 색인 응답 시점에 데이터는 모든 활성 사본에 도달해 있습니다 (4장에서 상세히).

2.6 운영 팁 — 클러스터 토폴로지 설계

• 전용 마스터 3대는 규모와 무관한 표준입니다. 데이터 노드의 GC pause나 디스크 I/O 폭증이 마스터 선출 타임아웃을 유발하면 클러스터 전체가 멈춥니다. 마스터 노드는 heap 4~8GB의 작은 사양이면 충분합니다.
• coordinating-only 노드는 대부분 불필요합니다. 거대한 집계 쿼리가 잦거나, 클라이언트 연결이 수천 개이거나, 검색/색인 트래픽 격리가 필요할 때만 검토하세요.
• 마스터 노드의 디스크도 모니터링하세요. cluster state를 디스크에 persist하므로, 디스크가 차면 선출이 실패합니다.

# 클러스터 토폴로지 상시 확인 — 운영자의 3종 세트
GET /_cluster/health

# 노드별 역할/heap/디스크 (master 칼럼의 *가 현재 마스터)
GET /_cat/nodes?v=true&h=name,node.role,heap.percent,disk.used_percent,master

# 지금 마스터는 누구인가
GET /_cat/master?v=true

✍️ 이해도 체크