클러스터·노드 아키텍처 (Cluster/Node Architecture)

Elasticsearch를 분산·확장 가능하게 만드는 핵심 부품이 바로 노드(node) 와 샤드(shard) 예요. 처음 시작할 때 이 개념까지 꼭 알아야 하는 건 아니고, Elasticsearch를 어떻게 운영하느냐에 따라 필요한 지식이 달라집니다. 세 가지 배포 방식으로 나눠서 볼게요.

Self-managed Elasticsearch: 클러스터·노드·샤드·레플리카를 직접 구성하고 관리합니다. 인프라와 확장, 장애 복구(failover)·백업 전략을 통한 고가용성 확보까지 모두 본인 몫이에요.
Managed deployments: ECH, ECE, ECK 같은 관리형 배포를 말해요. Elastic이 워크로드 변화에 맞춰 리소스를 자동으로 확장(autoscale)해 주고, 배포 유형에 따라 적절한 기본값을 골라 적용해 줍니다. 그래도 노드·샤드·레플리카에 대한 기본적인 이해는 여전히 중요해요.
Elastic Cloud Serverless: 노드·샤드·레플리카를 신경 쓸 필요가 없어요. 이 자원들은 서버리스 플랫폼에서 100% 자동화되어 있고, 플랫폼이 워크로드에 맞춰 알아서 확장됩니다.

노드(Node) — 클러스터를 이루는 서버 한 대

노드는 Elasticsearch 인스턴스 하나를 말해요. 서버(노드)를 클러스터에 더 추가하면 용량이 늘어나고, Elasticsearch가 데이터와 쿼리 부하를 모든 노드에 자동으로 분산합니다. 서로 연결된 노드들의 모음이 바로 클러스터(cluster) 죠.

샤드(Shard) — 인덱스를 쪼갠 조각

Elasticsearch가 데이터를 여러 노드에 분산할 수 있는 이유는 인덱스를 샤드로 쪼개기 때문이에요. 인덱스 하나는 물리적 샤드 한 개 이상의 묶음인데, 각 샤드는 독립된 Lucene 인덱스로 인덱스 안의 문서 일부를 담고 있습니다. 인덱스의 문서를 여러 샤드에 나누고, 그 샤드들을 여러 노드에 분산하면 그만큼 인덱싱과 쿼리 용량이 커집니다.

샤드에는 두 가지 유형이 있어요 — 프라이머리(primary) 와 레플리카(replica).

인덱스의 각 문서는 정확히 하나의 프라이머리 샤드에 속합니다.
레플리카 샤드는 프라이머리 샤드의 복사본이에요. 클러스터의 노드들에 데이터의 중복 복사본을 유지해서 하드웨어 장애로부터 보호해 주고, 검색이나 문서 조회 같은 읽기 요청을 처리할 용량도 늘려 줍니다.

팁: 인덱스의 프라이머리 샤드 수는 인덱스를 만드는 시점에 고정되지만, 레플리카 샤드 수는 인덱싱이나 쿼리 작업을 중단하지 않고도 언제든 바꿀 수 있어요.

클러스터 안의 샤드 복사본들은 확장과 고가용성을 위해 노드들 사이에 자동으로 균형 조정됩니다. 모든 노드는 클러스터의 다른 노드들을 모두 알고 있어서 클라이언트 요청을 적절한 노드로 전달할 수 있고, 이를 통해 Elasticsearch가 인덱싱과 쿼리 부하를 클러스터 전체에 분산해요.

개발 환경과 운영 환경은 다르게

Elasticsearch를 처음 익히거나 개발 환경에서 작업할 때는 단일 노드 클러스터에 샤드 한 개짜리 인덱스를 만들어도 충분합니다. 하지만 운영(production) 환경에서는 성능과 복원력을 높이기 위해 여러 노드와 여러 샤드를 가진 인덱스로 클러스터를 구성하는 것이 좋아요.

더 깊게 볼 주제가 있다면 이어서 보면 돼요.

클러스터의 샤드 수와 크기를 최적화하는 법 → Size your shards
읽기·쓰기 작업이 샤드와 샤드 복사본에 어떻게 복제되는지 → Reading and writing documents
샤드를 노드에 어떻게 할당하고 균형 조정하는지 → Shard allocation, relocation, and recovery