Elasticsearch における Replication
Replication レプリケーションとは
フォールトトレラントとしてレプリケーションをサポートしている
※システムの一部に問題が生じても全体が機能停止するということなく動作し続けるようなシステム
Elasticsearch においてレプリレーション機能はデフォルト（フリー）で提供されている。
どのように動くか
- レプリケーションはインデックスレベルで作成される
- レプリケーションはシャードをコピーすることで行われる
- コピー元のシャード(データの読み書き双方可能)は、プライマリシャードと呼ばれる
- プライマリシャードから作成されたレプリカはレプリカシャード(データの読み込み可能)と呼ばれる
- プライマリシャードとそのレプリカ群はまとめてレプリケーショングループと呼ばれる
- レプリカシャードはプライマリシャードと同様にリクエスト(データの読み込み可能)を処理可能
- レプリカの数はインデックスの生成時に構成される(index の設定に依存)
- レプリカシャードはプライマリシャードと同じノード上に生成されることはない
⇒仮に1台消失しても、他のノード上に残っている状態を確保するため
あるインデックスにおける Replication group A の例
Replication group A
- Primary Shard A
- Replica A1
- Replica A2
Replication group B
- Primary Shard B
- Replica B1
- Replica B2
Primary Shard と Replica Shard の例
2台Node構成で2つの indices が存在している場合。
それぞれの index 用に Primary Shard と Replica Shard が作られ、それぞれ違うノードに保持される。
Node1
- Primary Shard A
- Primary Shard B
Node2
- Replica Shard A
- Replica Shard B
このケースでも2台同時にノードが壊れてしまった場合は復旧ができない。
いくつの replica shards を保持するべきかはケースによる。
一時的にでもデータのロストが許容される場合、1つの replica shard
一時的にでもデータのロストが許容されない場合、少なくとも2つの は replica shard を確保したい（合計3台のノード上でデータが保持される）
Snapshots
Elasticsearch は snapshots をデータバックアップ用としてサポートしている。
⇒ある時点（snapshots取得時)でのデータ復旧が可能
snapshots は index レベルあるいは、cluster 全体の何れかのレベルで取得可能。
Snapshots があれば replication は必要なのか ?
⇒ snapshots はバックアップのため、replication は高可用性のために必要
⇒ replication はデータロストを防ぐために必要だが、データをクエリを投げる前に戻すことはできない
⇒ 何か大きなクエリを投げる前に snapshots を取得しておき、もし失敗したら復旧に使う
例）
デイリーで snapshot をバックアップ用で取得する。
作業前に手動で snapshot をデータ復旧用に取得する。
Snapshots に対する Replication
replication はノードが壊れた時にでも、データを継続して使用し続けることが出来ることを保証する。
また、 データロストを防ぐのと同時に、スループットの向上にも期待ができる。
例）
ユーザーはあるインデックスに対して、何らかのクエリを大量に投げるとする
⇒ このインデックスはたくさんのクエリ（リクエスト）を受け取る
⇒ ただ、このインデックスは1つの Shardで構成されている、何故ならドキュメントの数が少ないから
どのようにしてスループットを向上させるか?
⇒ 例えば、一つノードを追加する
⇒ Node1 が Primary shard、Node2 が replica shardをもつ状態になる
⇒ この時点で、読み込みリクエストが半分に分散される
スループット向上のためにノードを有効に活用するには、replica shards の数を増やす必要がある
⇒ Replica shards の数を増やすことでスループットの向上が期待できる
Elasticsearch は自動的にクエリを実行するための shard を選択する
⇒ もし同じインデックスにリクエストが同時に３つあったとしても、もし3つの shard (primary + 2 replica) が存在していれば、異なる shard 上で同時に処理することが可能
２つしかノードがないのに、なぜ３つ処理できるのか？
⇒ CPUがマルチコア構成だから、1ノード上で複数のリクエストを同時に処理可能
よって、replication はデータの可用性と、データのスループットの向上に役立つ。
ただし、replica の数を増やすためには、shard を丸ごとコピーできる程のディスクサイズが必要。
kibana 上でインデックスを作成してみる
news という名前の インデックスを作成します。
成功すれば以下のようなレスポンスが返ってきます。
インデックスの状態をチェックすると、ステータスが yellow になっています。
シャードの状態を以下のクエリで確認してみると、
"primary shard(p)" は STARTED になっていますが、”replica shard(r)” は UNASSIGNED になっています。
これはこのクラスターが1台のノードでしか構成されていないため、”replica shard(r)” はどこにも作られていないことを意味します。
従って、インデックスのステータスが yellow になっています。
