AWS OpenSearch (Elasticsearch) Serviceで専用マスターノードは3つが推奨な理由を段階を踏んで理解する

<!-- Google Slice link https://docs.google.com/presentation/d/1FUKtT6nL71nntJevIs_ctGJ5XdUxSgQFTqzNx92JJKM/edit?usp=sharing -->

# 前提

* [AWS OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/index.html)でサポートするElasticsearch 7.10.2時点までの内容になります。
* ノードが3つ必要という結論に関してはAWS OpenSearchの特別な話ではなく分散システムでの一般的な話になります。

# 理解のステップ

以下が本記事での理解の流れです。

0. マスターノードとは何か、他にどんなノードタイプがあるのかを把握する。
0. 専用マスターノードとは何か把握する。
0. quorumとは何か把握する。
0. 理想のquoram数を出す式が`dedicated master nodes / 2 + 1`の理由を把握する。
0. これまでマスター候補ノード(master-eligible node)はなぜ奇数台にするべきだったのか把握する。
0. Elasticsearch7.xでのマスター候補ノード設定の仕様変更を把握する。

# マスターノードとは？

"master"の役割をするノードのこと。masterはノードが持ちうるロールの内の1つである。

masterのロールは以下のようなクラスター全体のアクションを担当します。

* インデックスの作成または削除
* クラスターの一部であるノードの追跡
* どのシャードをどのノードに割り当てるかを決定する
* etc..

## その他のノードのタイプ

一番メインのデータのコンピュートをするデータノード、[Ingest pipelines](https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html)の機能を持つIngestノードなどがあります。以下公式ページ参照。

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html

# 専用マスターノード(Dedicated master nodes)とは

ノードは複数のロールを同時に担うことができますが、専用マスターノードはMasterのロールしか担当しないノードのことです。

複数のロールを担当するノード

【例】 `[Data, Master]`

専用マスターノード

`[Master]`

# Amazon OpenSearch Service では専用マスターノードを利用することを推奨している

Amazon OpenSearch Serviceでのクラスターにおいて、masterロールの役割を果たすノードはdedicated master nodeとして専門にさせることで安定性が向上するとAWSは主張しています。

詳細は以下のAWS公式ドキュメント参照。

https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-dedicatedmasternodes.html

# quorumとは何か？

masterのロールを持つ全ノードにおいて、障害が発生した際などに新たなMasterの選出やクラスタ構成変更をすることがあります。この変更の決定をするために参加するべきノードの最小数をquorumと呼びます。quorum数以上のノードで合意しているなら実行、そうで無いならば実行できません。

# 理想のquorum数を出す式が`dedicated master nodes / 2 + 1`の理由

Elasticsearchでは`dedicated master nodes / 2 + 1`の式で出る値を`quorum`の値にするべきと推奨されています。

その理由は、ネットワーク上の障害が発生した際の「スプリットブレイン」と呼ばれるマスターノードらが分断されるときに、分断されたそれぞれでバラバラに構成変更が実行されてしまうという問題が起きないようにすることが目的です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/91562/70f3db92-e283-bea5-3130-9e488f395e5f.png)

# 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を安全な形で自動で算出するようになりユーザーは考慮をしてなくても良くなりました。

これについては以下の記事が非常にわかりやすく説明されています。

https://qiita.com/tetsuyasodo/items/3182476f327be6d8cb28

しかし、上述したマスターノードが偶数台では1台が無駄になってしまうこと自体は変わりありません。

# 結論

ここまでをまとめると以下なります。

専用マスターノードが
* **1つ** → 耐障害性なし
* **2つ** → quorumが1ではスプリットブレインのリスクあり。quorumを2にして回避しても、1ノードの障害時にマスターを決めることができず障害になる、というリスクを抱える。
* **3つ** → 推奨
* **4つ** → Elasticsearch6以下ではスプリットブレインの障害リスクあり。Elasticsearch7からは耐障害性は3つと同等になるが専用マスターノードとしては1台が無駄である。
* **5つ以上** → 4つでのElasticsearch7の場合の理由と同じく、耐障害性の観点では専用マスターノードとしては無駄になる。このとき、パフォーマンスの観点ではシステム規模によって必要になる。

また、"前提"の内容の重複になりますが、ノードが3つ必要という結論に関してはAWS OpenSearchの特別な話ではなく分散システムでの一般的な話になります。


# 参考

https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-discovery-quorums.html

https://discuss.elastic.co/t/should-dedicated-master-nodes-and-data-nodes-be-considered-separately/75093

https://www.elastic.co/jp/blog/how-to-configure-elasticsearch-cluster-better