DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Elasticsearchマスターノード選出とクォーラム要件の理解

Elasticsearchのマスター選出とクォーラムの仕組み、およびスプリットブレインや安全でないブートストラップ設定を回避するための実践的なガイダンス。

Elasticsearchマスターノード選出とクォーラム要件の理解

Elasticsearchのマスターノードクォーラムは、クラスターが安全にリーダーを選出し、クラスター状態の変更を公開し、同じクラスターの2つの分離された側が異なる決定を行うことを防ぐかどうかを決定します。

選出されたマスター自体は検索を高速化しません。クラスターを調整します。選出が不安定な場合、症状は散在的に見えることがあります：インデックス作成がハングし、シャード割り当てが停止し、Kibanaが変化するヘルス状態を報告し、ログにマスターが発見されないというメッセージが繰り返されます。

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

データノードがインデックス作成、検索、データ保存の重い処理を担当する一方で、マスターノードはクラスター全体の構造とメタデータの管理を担当します。通常、クエリやインデックス作成操作には参加しません（データノードとしても設定されている場合を除く）。

マスターノードの責任

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

選出されたマスターが失敗した場合、別のマスターが選出されるまでクラスターはマスター専用の作業を一時停止します。既存の検索は利用可能なシャードに対して継続される可能性がありますが、インデックス作成、マッピング更新、割り当ての決定は安定したマスターの調整に依存します。

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

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

選出プロセス（Elasticsearch 7.x以降）

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

  1. 候補発見： マスター適格ノードは通信してアクティブな投票メンバーのセットを決定します。
  2. クォーラムチェック： ノードは、コンセンサスを確保するために、既知の投票ノードの過半数であるクォーラムに到達できるかどうかを確認します。
  3. リーダー選択： クォーラムが確立されると、Elasticsearchの調整サブシステムは内部の選出ルールに従ってマスターを選択します。
  4. 投票とコミット： 提案が投票され、過半数によって受け入れられると、新しいマスターが制御を引き継ぎ、新しいクラスター状態を公開します。

初期クラスターブートストラップ

新しいクラスターを初めて起動するとき、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を削除してください。後続の再起動時にこの設定を残しておくと危険です。この設定は新しいクラスターの最初のブートストラップ専用です。

クォーラム要件とスプリットブレイン防止

クォーラム要件の根本的な理由は、常に1つのリーダーのみが選出されることを保証し、スプリットブレイン問題を防ぐことです。

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

スプリットブレインは、ネットワークパーティションがクラスターを孤立したセグメントに分割し、複数のセグメントが権威あるマスターを持っていると信じる場合に発生します。その場合、異なる側が矛盾するクラスター状態の変更を受け入れる可能性があり、これはまさにクォーラムが防ぐように設計されているものです。

クォーラムルール（過半数コンセンサス）

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

$$\text{クォーラム} = \lfloor (\text{投票ノード数} / 2) \rfloor + 1$$

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

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

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

専用マスターノードの設定

本番環境では、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）はノード間で到達可能である必要があります。HTTP（通常9200）はクライアント/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。選出が失敗した場合、すべてのノードを一度に再起動する衝動を抑えてください。ログを読み、どのマスター適格ノードが互いに見えるかを確認し、一度に1つの制御された変更を行ってください。