前提
- AWS OpenSearch ServiceでサポートするElasticsearch 7.10.2時点までの内容になります。
- ノードが3つ必要という結論に関してはAWS OpenSearchの特別な話ではなく分散システムでの一般的な話になります。
理解のステップ
以下が本記事での理解の流れです。
- マスターノードとは何か、他にどんなノードタイプがあるのかを把握する。
- 専用マスターノードとは何か把握する。
- quorumとは何か把握する。
- 理想のquoram数を出す式が
dedicated master nodes / 2 + 1の理由を把握する。 - これまでマスター候補ノード(master-eligible node)はなぜ奇数台にするべきだったのか把握する。
- Elasticsearch7.xでのマスター候補ノード設定の仕様変更を把握する。
マスターノードとは？
"master"の役割をするノードのこと。masterはノードが持ちうるロールの内の1つである。
masterのロールは以下のようなクラスター全体のアクションを担当します。
- インデックスの作成または削除
- クラスターの一部であるノードの追跡
- どのシャードをどのノードに割り当てるかを決定する
- etc..
その他のノードのタイプ
一番メインのデータのコンピュートをするデータノード、Ingest pipelinesの機能を持つIngestノードなどがあります。以下公式ページ参照。
専用マスターノード(Dedicated master nodes)とは
ノードは複数のロールを同時に担うことができますが、専用マスターノードはMasterのロールしか担当しないノードのことです。
複数のロールを担当するノード
【例】 [Data, Master]
専用マスターノード
[Master]
Amazon OpenSearch Service では専用マスターノードを利用することを推奨している
Amazon OpenSearch Serviceでのクラスターにおいて、masterロールの役割を果たすノードはdedicated master nodeとして専門にさせることで安定性が向上するとAWSは主張しています。
詳細は以下のAWS公式ドキュメント参照。
quorumとは何か？
masterのロールを持つ全ノードにおいて、障害が発生した際などに新たなMasterの選出やクラスタ構成変更をすることがあります。この変更の決定をするために参加するべきノードの最小数をquorumと呼びます。quorum数以上のノードで合意しているなら実行、そうで無いならば実行できません。
理想のquorum数を出す式がdedicated master nodes / 2 + 1の理由
Elasticsearchではdedicated master nodes / 2 + 1の式で出る値をquorumの値にするべきと推奨されています。
その理由は、ネットワーク上の障害が発生した際の「スプリットブレイン」と呼ばれるマスターノードらが分断されるときに、分断されたそれぞれでバラバラに構成変更が実行されてしまうという問題が起きないようにすることが目的です。
Master-eligible Node(マスターノード候補)の数が奇数台が良い理由
偶数台では結局1台分が無駄になることが理由です。
以下はquorumの設定がElasticsearch7.xで自動で設定されるようにmaster nodes / 2 + 1としている際のマスターノード台数とノードの障害発生時のクラスタ復旧に対応する表です。
| 1台障害発生 | 2台障害発生 | |
|---|---|---|
| master2台 | 復旧不可 | 復旧不可 |
| master3台 | 復旧可能 | 復旧不可 |
| master4台 | 復旧可能 | 復旧不可 |
ポイントなのはmaster3台でも4台でも障害発生数におけるクラスタ復旧具合に違いが無いことです。
master4台で2台障害が発生してもquorumが3なので4-2(=2)台では復旧ができません。master3台で1台障害ならばquorumは2なので3-1(=2)で復旧可能です。
このことから、偶数台ではその1つ少ない奇数台と同じ耐障害性の能力なので専用マスターノードであるならば1台分のノードが無駄と言えます。
Elasticsearch7.xからはquorumを自動で決定してくれるようになった
Elasticsearch7.x 以前ではquorumはユーザーが自分で設定する必要がありました。Elasticsearch7.x からはquorumを安全な形で自動で算出するようになりユーザーは考慮をしてなくても良くなりました。
これについては以下の記事が非常にわかりやすく説明されています。
しかし、上述したマスターノードが偶数台では1台が無駄になってしまうこと自体は変わりありません。
結論
ここまでをまとめると以下なります。
専用マスターノードが
- 1つ → 耐障害性なし
- 2つ → quorumが1ではスプリットブレインのリスクあり。quorumを2にして回避しても、1ノードの障害時にマスターを決めることができず障害になる、というリスクを抱える。
- 3つ → 推奨
- 4つ → Elasticsearch6以下ではスプリットブレインの障害リスクあり。Elasticsearch7からは耐障害性は3つと同等になるが専用マスターノードとしては1台が無駄である。
- 5つ以上 → 4つでのElasticsearch7の場合の理由と同じく、耐障害性の観点では専用マスターノードとしては無駄になる。このとき、パフォーマンスの観点ではシステム規模によって必要になる。
また、"前提"の内容の重複になりますが、ノードが3つ必要という結論に関してはAWS OpenSearchの特別な話ではなく分散システムでの一般的な話になります。
参考