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

Elasticsearch 마스터 노드 쿼럼은 클러스터가 안전하게 리더를 선출하고, 클러스터 상태 변경을 게시하며, 동일한 클러스터의 두 분리된 측면이 서로 다른 결정을 내리는 것을 방지할 수 있는지 결정합니다.

선출된 마스터는 그 자체로 검색 속도를 높이지 않습니다. 마스터는 클러스터를 조정합니다. 선출이 불안정하면 증상이 산발적으로 나타날 수 있습니다: 인덱스 생성이 중단되고, 샤드 할당이 중지되며, Kibana가 변경되는 상태를 보고하고, 로그에 마스터를 찾을 수 없다는 메시지가 반복됩니다.

마스터 노드의 중요한 역할

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

마스터 노드의 책임

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

선출된 마스터가 실패하면, 다른 마스터가 선출될 때까지 클러스터는 마스터 전용 작업을 중단합니다. 기존 검색은 사용 가능한 샤드에 대해 계속될 수 있지만, 인덱스 생성, 매핑 업데이트 및 할당 결정은 안정적인 마스터 조정에 의존합니다.

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

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

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

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

후보 발견: 마스터 자격 노드는 통신하여 활성 투표 멤버 집합을 결정합니다.
쿼럼 확인: 노드는 합의를 보장하기 위해 알려진 투표 노드의 과반수인 쿼럼에 도달할 수 있는지 확인합니다.
리더 선택: 쿼럼이 설정되면 Elasticsearch의 조정 하위 시스템은 내부 선출 규칙에 따라 마스터를 선택합니다.
투표 및 확정: 제안이 투표되고 과반수가 수락하면 새 마스터가 제어권을 잡고 새 클러스터 상태를 게시합니다.

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

완전히 새로운 클러스터를 처음 시작할 때 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{Number of Voting Nodes} / 2) \rfloor + 1$$

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

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

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

전용 마스터 노드 구성

프로덕션 환경의 경우 일반적으로 3개의 전용 마스터 자격 노드가 기본입니다. 이는 검색 및 인덱싱 로드를 조정 작업과 분리합니다. 소규모 개발 클러스터는 혼합 역할을 실행할 수 있지만, 중요한 클러스터는 무거운 집계 또는 수집 급증이 선출된 마스터를 굶주리게 해서는 안 됩니다.

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

노드를 마스터 자격으로 구성하지만 데이터를 저장하거나 수집 파이프라인을 실행하지 않도록 하려면 elasticsearch.yml에서 다음 역할을 사용하십시오:

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

# 전송을 개인 네트워크에 바인딩하고 방화벽/보안 그룹으로 액세스를 제한합니다.
# network.host: 10.0.0.1

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

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

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

# 역할이 지정되지 않으면 Elasticsearch는 해당 버전의 기본 역할 집합을 할당합니다.

클러스터 검색 설정

모든 노드는 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 등)의 주소가 포함되어야 합니다.

선출 문제 해결

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

문제	설명 및 해결 방법
네트워크 문제	방화벽 규칙, 라우팅 문제, DNS 문제 또는 높은 지연 시간으로 인해 노드가 통신할 수 없습니다. 일반적으로 9300인 전송 포트는 노드 간에 연결 가능해야 합니다. 일반적으로 9200인 HTTP는 클라이언트/API 액세스용이며 선출 채널이 아닙니다.
구성 불일치	`cluster.name`이 잘못되었거나 `discovery.seed_hosts`가 올바른 마스터 자격 노드를 가리키지 않습니다. 모든 노드가 동일한 설정을 사용하는지 확인하십시오.
쿼럼 손실	한 번에 너무 많은 투표 노드가 실패했습니다(예: 3개의 마스터 설정에서 2개의 장애). 누락된 노드가 영구적으로 사라진 경우, 장애 모드를 확인한 후에만 투표 구성 제외 API를 신중하게 사용하십시오.
디스크 I/O	마스터 노드의 디스크 I/O가 포화 상태여서 클러스터 상태를 빠르게 게시하지 못해 시간 초과 및 반복적인 선출이 발생합니다.

투표 구성 확인

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

GET /_cluster/state?filter_path=metadata.cluster_coordination

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

가장 안전한 프로덕션 패턴은 지루합니다: 별도의 장애 도메인에 3개의 전용 마스터 자격 노드, 안정적인 전송 네트워킹, 올바른 시드 호스트, 그리고 한 번만 사용되는 cluster.initial_master_nodes입니다. 선출이 실패하면 모든 노드를 한 번에 재시작하려는 충동을 참으십시오. 로그를 읽고, 어떤 마스터 자격 노드가 서로를 볼 수 있는지 확인하고, 한 번에 하나의 통제된 변경을 수행하십시오.