Elasticsearchマスターノードの選出とQuorum要件の理解

Elasticsearchは分散システムであり、クラスタの状態の一貫したビューを維持するためにノード間の調整に依存しています。この調整の中心にあるのがマスターノードです。マスターノードはクラスタのメタデータの唯一の真の情報源であり、その安定性と適切な選出を確保することは、クラスタの健全性、スケーラビリティ、および回復性にとって極めて重要です。

この記事では、マスターノードの重要な責任、最新のElasticsearchバージョン（7.x+）で使用されている現代の選出プロセス、そして壊滅的なシナリオであるスプリットブレイン問題を防ぐために必要なメカニズムであるQuorumの基本的な概念について詳しく説明します。

マスターノードの重要な役割

データノードがインデックス作成、検索、データ保存といった負荷の高い作業を処理する一方で、マスターノードはクラスタ全体の構造とメタデータの管理を担当します。通常、データノードとしても設定されていない限り、クエリやインデックス作成操作には参加しません。

マスターノードの責任

クラスタ状態の管理: マスターは、クラスタ状態—どのインデックスが存在するか、それらのインデックスのマッピングと設定、各シャードの場所など、クラスタの現在の構成の設計図—を維持し、公開します。
ノード管理: ノードの参加と離脱を処理し、それに応じてクラスタの状態を更新します。
インデックス管理: インデックスの作成、削除、または更新を行います。
シャード割り当て: プライマリシャードとレプリカシャードがどこに配置されるべきかを決定します（初期割り当ておよびノード障害後の再バランス）。

マスターノードが故障した場合、新しいマスターが正常に選出されるまで、クラスタは管理タスクを実行したりシャードを再割り当てしたりすることができません。

マスター選出と投票の理解

分散システムでは、現在のマスターノードが故障したり到達不能になったりするたびに選出プロセスが必要です。Elasticsearch 7.0以降、選出メカニズムは大幅に簡素化され、強化されました。これは主に、複雑なdiscovery.zen.minimum_master_nodes設定の廃止と、自己管理型の投票構成 (Voting Configurations) の導入によるものです。

選出プロセス (Elasticsearch 7.x+)

マスター選出は現在、マスター適格ノードによって自動的に処理されます。これらのノードは、設定でnode.roles: [master, data]、または専用マスターの場合はnode.roles: [master]を使用して定義されます。

候補者の発見: マスター適格ノードは通信し、アクティブな投票メンバーのセットを決定します。
Quorumチェック: ノードは、コンセンサスを確保するために、既知の投票ノードの過半数であるQuorumに到達できるかどうかを確認します。
リーダー選出: Quorumが確立されると、最も上位の候補者（クラスタ状態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設定を削除するかコメントアウトする必要があります。

Quorum要件とスプリットブレインの防止

Quorum要件の根本的な理由は、常に1つのリーダーのみが選出されることを保証し、それによってスプリットブレイン問題を防止することにあります。

スプリットブレインとは？

スプリットブレインは、ネットワークパーティションがクラスタを2つ以上の隔離されたセグメントに分割し、各セグメントが自身を権威あるマスターであると信じる場合に発生します。これが起こると、異なるセグメントのノードが独立してインデックス作成リクエストを受け入れ、シャードを割り当てることがあり、ネットワークが最終的に回復したときにデータの一貫性の欠如と破損につながります。

Quorumルール (過半数コンセンサス)

スプリットブレインを防ぐため、Elasticsearchは過半数コンセンサスルールを強制し、クラスタ状態の変更に合意するために最小限の投票ノード数を要求します。この最小値がQuorumであり、次のように計算されます。

$$\text{Quorum} = \lfloor (\text{Number of Voting Nodes} / 2) \rfloor + 1$$

厳格な過半数を要求することで、ネットワークがパーティション分割された場合、より大きな側（過半数を保持する側）のみがQuorumに達し、動作を継続できます。より小さな側はマスターを選出できず、ネットワーク接続が回復するまで停止して待機するため、パーティション分割されたセグメントへのデータ書き込みが回避されます。

投票マスターノード数 (N)	必要なQuorum (N/2 + 1)
3	2
5	3
7	4

ベストプラクティス警告: マスター適格ノードは常に奇数（例：3つまたは5つ）でデプロイしてください。偶数（例：4つ）をデプロイした場合、先行する奇数（3つ）と同じフォールトトレランスしか提供せず、より多くのリソースを必要とします。例えば、4ノードの投票クラスタは3票（N/2+1）を必要とし、3ノードクラスタと同じく1つの障害しか許容できませんが、サーバーを1台余分に使用します。

専用マスターノードの構成

本番環境、特に大規模なクラスタ（データノードが20以上）では、専用マスターノードの使用を強くお勧めします。これにより、検索/インデックス作成の計算集約型タスクと、マスターの重要な管理業務が分離されます。

ノード構成例 (専用マスター)

マスター適格でありながら、データを保存したりインジェストパイプラインを実行したりしないノードを構成するには、elasticsearch.ymlで以下のロールを使用します。

# ノード 1: 専用マスター
node.name: es-master-01
node.roles: [master]

# ピュアマスターのHTTP/Transportトラフィックを無効にする（オプションだが、セキュリティ上の良いプラクティス）
# http.enabled: false 
# transport.bind_host: [private_ip_of_master]

ノード構成例 (専用データノード)

逆に、専用データノードはマスター選出プロセスに参加しないようにすべきです。

# ノード 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など）のアドレスが含まれている必要があります。

選出に関する問題のトラブルシューティング

クラスタがマスターを選出できない場合、通常は「red」または「yellow」状態になり、永続的なエラーをログに記録します。一般的な原因は以下のとおりです。

問題	説明と解決策
ネットワーク問題	ファイアウォールルール、ルーティング問題、または高レイテンシにより、ノードが互いに通信できない。ノード間でポート9200 (HTTP) と9300 (Transport) が開いていることを確認してください。
設定の不一致	`cluster.name`が正しくない、または`discovery.seed_hosts`が正しいマスター適格ノードを指していない。すべてのノードが同一の設定を使用していることを確認してください。
Quorumの喪失	あまりにも多くのマスター適格ノードが同時に故障した（例：3ノードマスター設定で2つの障害）。失敗したノードを投票リストから強制的に削除するために、手動介入（例：`api/cluster/decommission/voting_config_exclusions` APIの使用）が必要になる場合があります。
ディスクI/O	マスターノードのディスクI/Oが飽和状態になり、クラスタ状態を迅速に公開できないため、タイムアウトと選出の繰り返しにつながる。

投票構成の確認

Cluster APIを使用して、現在の投票構成を検査できます。

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

この出力は、現在Quorumにカウントされているノードを確認し、設定がフォールトトレランスの目標と一致していることを保証します。

まとめ

マスターノードの選出プロセスは、Elasticsearchクラスタの回復性のバックボーンです。マスターの責任を理解し、Quorumルールを正しく実装する（マスター適格ノードを奇数で構成し、ブートストラップ時にcluster.initial_master_nodesが正しく設定されていることを確認する）ことで、管理者はスプリットブレインシナリオを確実に防止し、高可用性の分散システムを維持できます。管理タスクを分離し、信頼性の高いクラスタ状態の公開を確実にするために、本番環境では常に専用マスターノードを使用してください。