Elasticsearch 마스터 노드 선출 및 쿼럼 요구 사항 이해

Elasticsearch는 클러스터 상태에 대한 일관된 뷰를 유지하기 위해 노드 간의 조정에 의존하는 분산 시스템입니다. 이러한 조정의 핵심에는 마스터 노드가 있습니다. 마스터 노드는 클러스터 메타데이터의 단일 신뢰 소스이며, 안정성과 적절한 선출을 보장하는 것은 클러스터 상태, 확장성 및 복원력에 매우 중요합니다.

이 문서는 마스터 노드의 중요한 책임 사항을 자세히 설명하고, 최신 Elasticsearch 버전(7.x 이상)에서 사용되는 현대적인 선출 프로세스를 설명하며, 스플릿 브레인(split-brain) 문제라고 불리는 파괴적인 시나리오를 방지하는 데 필요한 메커니즘인 쿼럼(quorum)의 필수 개념을 명확히 합니다.

마스터 노드의 중요한 역할

데이터 노드는 인덱싱, 검색 및 데이터 저장의 힘든 작업을 처리하는 반면, 마스터 노드는 전체 클러스터의 구조와 메타데이터를 관리할 책임이 있습니다. 마스터 노드는 데이터 노드로도 구성되지 않는 한 일반적으로 쿼리 또는 인덱싱 작업에 참여하지 않습니다.

마스터 노드 책임

클러스터 상태 관리: 마스터는 클러스터의 현재 구성(어떤 인덱스가 존재하는지, 해당 인덱스의 매핑 및 설정, 모든 샤드의 위치 포함)의 청사진인 클러스터 상태를 유지하고 게시합니다.
노드 관리: 노드의 참여 및 탈퇴를 처리하고 그에 따라 클러스터 상태를 업데이트합니다.
인덱스 관리: 인덱스 생성, 삭제 또는 업데이트.
샤드 할당: 기본 및 복제본 샤드가 위치해야 할 위치를 결정합니다(초기 할당 및 노드 장애 후 재조정).

마스터 노드가 실패하면 새 마스터가 성공적으로 선출될 때까지 클러스터는 관리 작업을 수행하거나 샤드를 재할당할 수 없습니다.

마스터 선출 및 투표 이해하기

분산 시스템에서는 현재 마스터 노드가 실패하거나 도달할 수 없게 될 때마다 선출 프로세스가 필요합니다. Elasticsearch 7.0부터는 복잡한 discovery.zen.minimum_master_nodes 설정을 제거하고 자체 관리되는 투표 구성(Voting Configurations)을 도입함으로써 선출 메커니즘이 크게 단순화되고 강화되었습니다.

선출 프로세스 (Elasticsearch 7.x 이상)

마스터 선출은 이제 node.roles: [master, data] 또는 전용 마스터의 경우 node.roles: [master]를 사용하여 구성에서 정의된 마스터 권한 노드에 의해 자동으로 처리됩니다.

후보자 검색: 마스터 권한 노드는 활성 투표 멤버 세트를 확인하기 위해 통신합니다.
쿼럼 확인: 노드는 합의를 보장하기 위해 쿼럼—알려진 투표 노드의 과반수—에 도달할 수 있는지 확인합니다.
리더 선택: 쿼럼이 설정되면 클러스터 상태 ID와 같은 동점 해결 메커니즘을 기반으로 가장 순위가 높은 후보자가 새 마스터로 제안됩니다.
투표 및 확정: 제안에 대해 투표가 이루어지며, 과반수에 의해 승인되면 새 마스터가 제어권을 인계하고 새 클러스터 상태를 게시합니다.

초기 클러스터 부트스트래핑

새 클러스터를 처음 시작할 때 Elasticsearch는 어떤 노드가 초기 투표 구성에 참여해야 하는지 알아야 합니다. 이는 cluster.initial_master_nodes 설정을 사용하여 처리됩니다. 이 설정은 클러스터의 초기 시작 시 한 번만 사용해야 합니다.

# 초기 설정을 위한 elasticsearch.yml 조각
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# 초기 부트스트랩에 사용된 모든 마스터 권한 노드의 이름을 나열합니다.
cluster.initial_master_nodes: [node-1, node-2, node-3]

팁: 클러스터가 실행되고 안정화되면 나중에 노드들이 혼합된 상태로 다시 시작될 때 발생할 수 있는 잠재적 문제를 방지하기 위해 모든 노드의 구성 파일에서 cluster.initial_master_nodes 설정을 제거하거나 주석 처리해야 합니다.

쿼럼 요구 사항 및 스플릿 브레인 방지

쿼럼 요구 사항의 근본적인 이유는 한 번에 하나의 리더만 선출되도록 보장하여 스플릿 브레인 문제를 방지하는 데 있습니다.

스플릿 브레인이란?

스플릿 브레인은 네트워크 분할로 인해 클러스터가 둘 이상의 격리된 세그먼트로 나뉘고 각 세그먼트가 자신이 권한 있는 마스터라고 생각할 때 발생합니다. 이런 일이 발생하면 다른 세그먼트의 노드가 독립적으로 인덱싱 요청을 수락하고 샤드를 할당할 수 있어 네트워크가 결국 복구될 때 데이터 불일치 및 손상을 초래합니다.

쿼럼 규칙 (과반수 합의)

스플릿 브레인을 방지하기 위해 Elasticsearch는 과반수 합의 규칙을 시행하며, 클러스터 상태 변경에 동의하는 최소 수의 투표 노드를 요구합니다. 이 최소값이 쿼럼이며, 다음과 같이 계산됩니다.

$$\text{Quorum} = \lfloor (\text{투표 노드 수} / 2) \rfloor + 1$$

엄격한 과반수를 요구함으로써 네트워크가 분할되면 과반수를 보유한 더 큰 쪽만 쿼럼에 도달하여 계속 작동할 수 있습니다. 쿼럼에 도달할 수 없는 작은 쪽은 중단하고 네트워크 연결이 복원될 때까지 대기하므로 분할된 세그먼트에 대한 데이터 쓰기를 방지합니다.

투표 마스터 노드 수 (N)	필요한 쿼럼 (N/2 + 1)
3	2
5	3
7	4

모범 사례 경고: 항상 홀수 개의 마스터 권한 노드(예: 3개 또는 5개)를 배포하십시오. 짝수 개(예: 4개)를 배포하는 것은 리소스는 더 많이 사용하지만 이전 홀수 개(3개)와 동일한 내결함성을 제공합니다. 예를 들어, 4노드 투표 클러스터는 3표(N/2+1)가 필요하므로 1개의 실패만 허용할 수 있으며, 이는 3노드 클러스터와 동일하지만 서버를 하나 더 사용합니다.

전용 마스터 노드 구성

프로덕션 환경, 특히 대규모 클러스터(20개 이상의 데이터 노드)의 경우 전용 마스터 노드를 사용하는 것이 강력히 권장됩니다. 이는 리소스 집약적인 검색/인덱싱 작업과 마스터의 중요한 관리 작업을 분리합니다.

노드 구성 예시 (전용 마스터)

노드를 마스터 권한은 있지만 데이터를 저장하거나 인제스트 파이프라인을 실행하지 않도록 구성하려면 elasticsearch.yml에서 다음 역할을 사용합니다.

# 노드 1: 전용 마스터
node.name: es-master-01
node.roles: [master]

# 순수 마스터의 경우 HTTP/전송 트래픽 비활성화(선택 사항이지만 좋은 보안 관행)
# http.enabled: false 
# transport.bind_host: [master의_private_ip]

노드 구성 예시 (전용 데이터 노드)

반대로, 전용 데이터 노드는 마스터 선출 프로세스에 참여하지 않도록 방지해야 합니다.

# 노드 4: 전용 데이터 노드
node.name: es-data-04
node.roles: [data]

# 참고: 역할이 지정되지 않은 경우 Elasticsearch는 [master, data, ingest]로 기본 설정됩니다(8.0 이전 기본값).

클러스터 검색 설정

모든 노드는 discovery.seed_hosts 설정을 사용하여 동일한 마스터 권한 노드 세트를 찾도록 구성되어야 합니다. 이 설정은 Elasticsearch가 클러스터에 가입하기 위해 다른 노드에 연락을 시도할 수 있는 네트워크 주소를 나열합니다.

# 클러스터의 모든 노드에 대한 공통 설정
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

이 목록에는 마스터 권한 노드(es-master-01, es-master-02, es-master-03 등)의 주소가 포함되어야 합니다.

선출 문제 해결

클러스터가 마스터를 선출하지 못하면 일반적으로 '빨간색' 또는 '노란색' 상태로 들어가고 지속적인 오류를 기록합니다. 일반적인 원인은 다음과 같습니다.

문제	설명 및 해결 방법
네트워크 문제	방화벽 규칙, 라우팅 문제 또는 높은 지연 시간으로 인해 노드가 서로 통신할 수 없습니다. 노드 간에 포트 9200(HTTP) 및 9300(전송)이 열려 있는지 확인하십시오.
구성 불일치	`cluster.name`이 잘못되었거나 `discovery.seed_hosts`가 올바른 마스터 권한 노드를 가리키지 않습니다. 모든 노드가 동일한 설정을 사용하고 있는지 확인하십시오.
쿼럼 손실	너무 많은 마스터 권한 노드가 동시에 실패했습니다(예: 3노드 마스터 설정에서 2회 실패). 실패한 노드를 투표 목록에서 강제로 제거하기 위해 수동 개입(예: `api/cluster/decommission/voting_config_exclusions` API 사용)이 필요할 수 있습니다.
디스크 I/O	마스터 노드의 디스크 I/O가 포화되어 클러스터 상태를 신속하게 게시하지 못하고 시간 초과 및 반복적인 선출로 이어집니다.

투표 구성 확인

클러스터 API를 사용하여 현재 투표 구성을 검사할 수 있습니다.

GET /_cluster/state?filter_path=metadata.cluster_coordination.voting_config_excluding_deferred

이 출력은 현재 쿼럼에 포함되는 노드를 확인하여 구성이 내결함성 목표와 일치하는지 확인합니다.

요약

마스터 노드 선출 프로세스는 Elasticsearch 클러스터 복원력의 근간입니다. 마스터의 책임을 이해하고 쿼럼 규칙(홀수 개의 마스터 권한 노드를 사용하고 부트스트랩 시 올바른 cluster.initial_master_nodes 보장)을 올바르게 구현함으로써 관리자는 스플릿 브레인 시나리오를 안정적으로 방지하고 고가용성 분산 시스템을 유지할 수 있습니다. 프로덕션 환경에서는 관리 작업을 격리하고 안정적인 클러스터 상태 게시를 보장하기 위해 항상 전용 마스터 노드를 사용하십시오.