ElasticsearchのReading and Writing documentsの基本的な書き込みモデル

ElasticsearchのReading and Writing documentsについて記す。

公式ドキュメント Reading and Writing documents を参考にした。

www.elastic.co

検証環境: Elasticsearch 6.0.0-rc1

はじめに

Elasticsearchの各インデックスはシャードに分割され、各シャードは複数のコピーをもつことができる。これらのコピーはレプリケーショングループと呼ばれ、ドキュメントが追加または削除されたときに同期されている必要がある。そうしなければ、1つのコピーから読むと、別のコピーを読むことと比べて結果が大きく異なることになる可能性がある。同期したシャードコピーを保持しそこから読み取りを処理するプロセスは、データレプリケーションモデルと呼ばれている。

Elasticsearchのデータレプリケーションモデルは、プライマリバックアップモデルに基づいており、Microsoft ResearchのPacificAの論文( https://www.microsoft.com/en-us/research/publication/pacifica-replication-in-log-based-distributed-storage-systems/ )でとてもよく説明されている。このモデルは、プライマリシャードとして機能するレプリケーショングループからの単一のコピーを持つことに基づいている。他のコピーはレプリカシャードと呼ばれる。プライマリは、すべてのインデックス操作のメインエントリポイントとして機能する。それらが正しいことを確認し検証する必要がある。プライマリによってインデックス操作が受け入れられると、プライマリは他のコピーにコピーする役割も担う。

このセクションのこの目的は、Elasticsearchレプリケーションモデルの大まかな概要を説明と書き込み操作と読み取り操作の間のさまざまな相互作用に与える影響について説明することだ。

基本的な書き込みモデル

Elasticsearchのすべてのインデックス操作は、通常はドキュメントIDに基づいたルーティングを使用してレプリケーショングループによって最初に解決される。レプリケーショングループが1回決定されると、インデックス操作はグループの現在のプライマリシャードに内部的に転送される。プライマリシャードは、インデックス操作を検証しそれを他のレプリカシャードに転送する役割を担う。レプリカシャードはオフラインにすることができるため、プライマリシャードはすべてのレプリカシャードにコピーする必要はない。代わりに、Elasticsearchは操作を受け取るべきシャードコピーのリストを保持する。このリストはin-sync copiesと呼ばれマスターノードによって保持される。名前が示すように、これらはユーザーに承認されたすべてのインデックス操作および削除操作を処理したことが保証されている「good」なシャードコピーのセットである。プライマリシャードはこのinvariantを保持する責任があり、したがって、このセットの各コピーにすべての操作をコピーする必要がある。

プライマリーシャードは基本的にこの流れに従う

  1. 構造的に無効な場合は受信操作を検証しrejectする(例:数値が必要なオブジェクトフィールドをもつ)
  2. ローカルで操作を実行する。すなわち関連する文書をインデックス付けまたは削除する。これにより、フィールドの内容が検証され必要に応じてrejectされる(例:キーワードの値がLuceneでのindex作成には長すぎるときなど)。
  3. 現在のin-sync copiesセットの各レプリカにインデックス操作を転送する。複数のレプリカがある場合、これは並行して行われる。
  4. すべてのレプリカシャードがインデックス操作を正常に実行してプライマリシャードに応答すると、プライマリシャードはクライアントへのリクエストの正常終了を確認する。

障害処理

インデックス作成中に多くのことが間違っている可能性がある - ディスクが破損したり、ノードが相互に切断されたり、設定ミスによってプライマリシャードで成功したにもかかわらずレプリカシャードで操作が失敗する可能性がある。これらは頻繁に起こることではないがプライマリシャードはこれに応答する必要がある。

プライマリシャード自体に障害が発生した場合、プライマリシャードをホストしているノードはマスタに対してメッセージを送信する。インデックス作成操作では、マスターがレプリカシャードの1つを新しいプライマリシャードに昇格させるまで待機する(デフォルトでは1分まで)。新しいプライマリシャードに処理が転送される。マスターはノードの正常性も監視しプライマリシャードを降格させることもできる。これは、通常プライマリシャードを持つノードがネットワークの問題によってクラスタから隔離されている場合に発生する。

プライマリシャードで操作が正常に実行されると、プライマリシャードはレプリカシャード上で実行する際に潜在的な障害に対処しなければならない。これはレプリカシャード上の実際の障害またはネットワーク上の問題により、インデックス操作がレプリカシャードに到達しない(またはレプリカシャードが応答しない)ために発生している可能性がある。これらのすべてが同じ最終結果を共有する。 in-sync replicaセットの一部であるレプリカシャードは承認される予定の操作をミスする。invariantに違反しないように、プライマリシャードは問題のあるシャードがin-sync replicaセットから削除されることを要求するメッセージをマスタに送信する。シャードのremovalがマスタによって認識されると、プライマリシャードが操作を認識する。

レプリカシャードに操作を転送する際、プライマリシャードはレプリカシャードを使用してレプリカシャードがまだアクティブプライマリであることを検証する。プライマリシャードがネットワークパーティション(または長いgarbage collection)のために隔離されている場合、プライマリシャードが降格したことを認識する前に受信したインデックス操作を処理し続けることがある。失効したプライマリシャードからの操作は、レプリカシャードによって拒否される。プライマリシャードが要求を拒否するレプリカシャードから応答を受け取ると、それはもはやプライマリシャードではないため、マスタがreachし置換されることを知る。この操作は新しいプライマリシャードにルーティングされる。

レプリカシャードがないとどうなるか?

これはindexの構成またはすべてのレプリカシャードが失敗したために発生する可能性がある有効なシナリオである。この場合、プライマリシャードは外部検証なしで処理操作を処理しているため問題があるようだ。一方、プライマリシャードは自分自身で他のシャードにfailできないが、代わりにマスタにそうするように要求する。これは、マスタがプライマリシャードが唯一の「good」なコピーであることを認識していることを意味する。したがって、マスタは他の(期限切れの)シャードコピーを新しいプライマリシャードに昇格させず、プライマリシャードにインデックスされた操作は失われないことを保証する。もちろんその時点ではデータのコピーを1つだけ実行しているため、物理的なハードウェアの問題によってデータが失われる可能性はある。いくつかのmitigation optionsのためには以下のリンクを参照するのがいい。 www.elastic.co