Elasticsearch as a Distributed System

Elasticsearch as a Distributed System
～分散システムとしてのElasticsearch～
(簡易版)
2017-12-12
Acroquest Technology
束野仁政(つかのさとゆき)

はじめに
Copyright © Acroquest Technology Co., Ltd. All rights reserved.
2
1. Elasticsearchは分散システムである
2. 「Elasticsearch(の分散処理)を理解すること」と
「分散システムを理解すること」は共通点が多く、
Elasticsearchの分散処理を学ぶと応用が利く
3. この資料の内容は、単にインデクシング・検索するだけならオー
バースペックな知識
4. Elasticsearchを分散システムとして捉えたときに、
スケールアウト・耐障害性・運用・問題解析などで必要となる
知識を説明する
5. 次の書籍は分散システムのミドルウェアを学ぶ上でオススメ
 Hadoop: The Definitive Guide
 Elasticsearch: The Definitive Guide

目次
1. ノードの種類
2. シャード
3. インデクシングの流れ
4. 検索の流れ
5. Data nodeの障害検出
6. Master nodeの障害検出
3
この資料はElastic Stack5.6をベースに作成してます

ノードの種類
4

ノードの種類
5
その他にも、Ingest Node、
Machine learning node等がありますが、ここでは説明しません。
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 1
Replica
Data node 3
Shard 0
Replica
Shard 1
Primary
Data node 4
Coordinating node Master-eligible node
Master

ノードの種類
6
No. ノードの種類役割
1 Master-eligible node クラスタの状態管理、ノードに対するシャードの割り当て等、クラスタ全体の処
理を行うノードをMaster nodeと呼ぶ。Master nodeの候補となるノードを
Master-eligible nodeと呼び、この中から1ノードがMaster nodeに選出される。
2 Data node Elasticsearchのデータを保持するノード。データを保持し、クエリに対応した結
果を返す。
3 Coordinating node 検索リクエストやインデクシングリクエストなどを受け付けるノード。
すべてのノードは検索リクエストやインデクシングリクエストを受け付けることが
できる。
4 Coordinating only node
(Client node)
Coordinating nodeの役割のみのノード。
参考
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html
https://github.com/NII-cloud-operation/Literate-computing-Elasticsearch/blob/master/01_01_Outline.ipynb
ノードの種類は次の通り
※1ノードが複数の種類を兼任できます

シャード
7

シャードとは？
8
Elasticsearchはインデックス毎にシャードと呼ばれるファイルにデ
ータを保存する。
「1インデックス=複数シャード」にすることで、次の効果がある。
1. 処理のスケール
インデックスを複数のシャードに分割し、複数のノードに分散し保持す
ることで、並列処理が可能になる。そのため、シャードを増やすことによ
り、インデクシング・検索の性能を向上できる。
これにより、インデクシング・検索処理をスケールすることができる。
ただし、シャードを作成しすぎると負荷が高くなるので注意。
2. 冗長化による耐障害性の確保
データのコピー(=レプリカ)を別ノードに保持することで、特定ノードに障
害が発生した場合でも処理を継続できる。

シャードとは？～処理のスケール
9
インデックスのデータをシャードに分散して保持しているため、
並列処理を行うことができる
この例では3並列で検索が可能
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3

シャードとは？～冗長化による耐障害性の確保
10
Data Node 3が故障しても、コピーがあるため、
別ノードのシャードを利用して処理を継続
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3

シャードに関連する用語・機能
11
1. プライマリシャードとレプリカシャードの組をレプリケーション
グループと呼ぶ
2. シャードを割り当てる際に残ディスク容量を考慮し、
ディスクフルを防ぐことができる
3. 特定ノードへのシャードの偏りを改善するため、リバランス
できる
4. インデックス単位でシャード設定を行うことができ、
デフォルトではシャード数=5, レプリカ数=1
REST APIで変更可能
5. シャード数はインデックス作成後に変更できない
6. Aggregation等はシャード単位で行われる

レプリケーショングループ
12
Shard 0のレプリケーショングループ
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
• 同一レプリケーショングループのデータは別ノードに配置される
• 「レプリカ数 ≧ ノード数」に設定しても、ディスクアクセスを並列化できなければ
性能を向上できない

ディスクベースのシャード割り当て
13
• cluster.routing.allocation.disk.watermark.low
ノードのディスク使用率がこの値を超えると、新規シャードを割り当てない。デフォルト値は85％
残ディスク容量(MB等)を指定することもできる
• cluster.routing.allocation.disk.watermark.high
ノードのディスク使用率がこの値を超えると、別ノードにシャードを再配置する。デフォルト値は90％
残ディスク容量(MB等)を指定することもできる
• cluster.info.update.interval
クラスタ内の各ノードのディスク使用率をチェックする頻度。デフォルト値は30s
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
シャードを割り当てる際に残ディスク容量を考慮し、
ディスクフルを防ぐ
82% 87% 92%
新規シャードを割り当て可能新規シャードを割り当てない別ノードにシャードを再配置

リバランス
14
リバランスが行われる主なケース
• cluster.routing.allocation.disk.watermark.highを
超え、残ディスク容量が少なくなった場合
• クラスタにノードが追加・削除された場合
(計画的な追加・削除、障害検出・障害回復、etc)
Shard 0
Primary
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Data node 3
特定ノードへのシャードの偏りを改善するため、リバラン
スできる(基本的には自動で実行されます)
50% 90% 50%

インデックス単位でシャード数、レプリカ数を設定可能
15
• シャード数はインデックス作成後に変更できない
(再インデックスが必要)
• レプリカ数はインデックス作成後でも変更可能
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
• デフォルトではシャード数=5, レプリカ数=1
• REST APIで変更可能
インデックスA (シャード数=3, レプリカ数=1)
Shard 0
Primary
Shard 0
Replica
Shard 0
Replica
インデックスB (シャード数=1, レプリカ数=2)

シャード単位で処理することの注意点
16
• Aggregation等は、まずシャード単位で実行し、各シャードの
実行結果をマージし、クライアントに返す
• そのため、処理によっては正確な結果にならない場合がある
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
各シャードの実行結果をマージ
シャード単位の実行結果

インデクシングの流れ
17

インデクシングの流れ～概要
18
Elasticseachクラスタ内でのインデクシング処理の流れ
1. クライアントからのリクエストを受けたCoordinating nodeは
インデクシング先のシャード番号を決める
2. Coordinating nodeはPrimaryシャードにインデクシングを
リクエストする
3. Primaryシャードは、インデクシングを行う
4. Replicaシャードは、並列でインデクシングを行う
5. Replicaシャードは、Primaryシャードにレスポンスを返す
6. Primaryシャードに全Replicaシャードからレスポンスが返って
きたら、Coordinating nodeにレスポンスを返す
7. Coordinating nodeはクライアントにレスポンスを返す

インデクシングの流れ(1/8)
19
• クライアントからのリクエストを受けたCoordinating nodeはインデ
クシング先のシャード番号を決める。
• シャード番号 = hash(document_id) % シャード数
この場合はシャード数=3
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
①シャード番号を決定

20
• Coordinating nodeはPrimaryシャードにインデク
シングをリクエストする
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
①シャード番号を決定②Primaryシャードにリクエスト

21
• Primaryシャードはインデクシングを行う
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
③インデクシング

22
• Replicaシャードにインデクシングをリクエストする
• 全Replicaシャードに並列でリクエストする
(この場合は、Replica数=1なので、1並列)
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
④Replicaシャードにリクエスト
③インデクシング

23
• Replicaシャードにインデクシングを行う
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
③インデクシング ⑤インデクシング

24
• Primaryシャードにレスポンスを返す
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
⑥レスポンス

25
• 全Replicaシャードからレスポンスが返ってきたら、
Coordinating nodeにレスポンスを返す
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
⑥レスポンス
⑦レスポンス

26
• Coordinating nodeはクライアントにレスポンスを
返す
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
⑥レスポンス
⑦レスポンス

検索の流れ
27

検索の流れ～概要
28
Elasticseachクラスタ内での検索処理の流れ
Query Phase
1. Coordinating nodeは各シャードにリクエスト
2. 各シャード内で検索を行う
Fetch Phase
3. 各シャードの検索結果をCoordinating nodeに
返す
4. Coordinating nodeが各シャードからの検索結果
をマージし、クライアントにレスポンスを返す

検索の流れ(1/4)
29
• Coordinating nodeは全レプリケーショングループから1シャードずつ選び、リ
クエストする
• リクエスト先のシャードは、各レプリケーショングループ内でラウンドロビンにより
バランシングされる
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
①各シャードにリクエスト
①
①
Shard 0の
Shard 1の
Shard 2の

30
• 各シャード内で検索を行う
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
①
①
②シャード内で検索 ②シャード内で検索 ②シャード内で検索

31
• 各シャードの検索結果をCoordinating nodeに返す
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
③検索結果 ③ ③①
①

32
• Coordinating nodeが各シャードからの検索結果
をマージし、クライアントにレスポンスを返す
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
④各シャードの検索結果をマージ
③ ③①
①
③検索結果

検索にかかる時間
33
検索にかかる時間
• Query Phaseの時間 + Fetch Phaseの時間
= 検索が一番遅いシャードの処理時間 + マージ時間
Coordinating node
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 0
Replica
Shard 1
Replica
Data node 2
Shard 1
Primary
Shard 2
Primary
Data node 3
④各シャードの検索結果をマージ
③ ③①
①
③検索結果

DATA NODEの障害検出
34

Data Node障害検出～目次
35
本章では次の内容を説明する
1. クラスタ状態
2. Data Nodeの障害検出の流れ
3. インデックス復旧の優先度
4. Data Nodeの障害検出に関連する設定
5. シャード再割り当て途中でのノード復旧
障害検出方法にはいくつか種類があるが、
Elasticsearchのデフォルト方式である
Zen Discoveryを前提として説明する

クラスタ状態
36
1. インデックス単位の状態には、次の種類がある
2. クラスタ全体の状態は、
インデックス単位の状態の最悪値になる
3. 具体的な状態(status)はREST APIで確認可能
状態内容
green 正常な状態
yellow 割り当てられていないレプリカシャードあり
red 割り当てられていないシャードあり
GET _cluster/health/インデックス名
GET _cluster/health
インデックス
単位
クラスタ
全体

Data Nodeの障害検出の流れ～概要
37
Data Nodeの障害検出の流れ
1. Master nodeは各ノードにヘルスチェックを行う
2. Data nodeに障害が発生し、
Master nodeが障害検出する
3. Data nodeがすぐに復旧するケースに備え、
Master nodeは1分間待機する
4. 障害により失われたプライマリシャードを復旧させる
5. 障害により失われたレプリカシャードを復旧させる

Data Nodeの障害検出の流れ(1/5)
38
• Master nodeは各ノードにヘルスチェックを行う
• ヘルスチェック間隔は1s
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
Shard 1
Replica
Data node 3

39
• Data nodeに障害が発生する
• タイムアウト30s×3回連続でヘルスチェックに失敗すると、
Master nodeは「Data nodeに障害が発生した」と認識する
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
①障害検知
Shard 1
Replica
Data node 3

40
• 障害検出したノードが保持するデータを復旧させたい
• ただ、Data nodeがすぐに復旧するケースに備え、
Master nodeは1分間待機する
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
①障害検知
②1分間待機
Shard 1
Replica
Data node 3

Shard 1
R→P
Data node 3
41
• 障害により失われたプライマリシャード(ここではShard 1)を復旧させる
• レプリカシャードの1つをプライマリシャードに変更する
• これは状態更新のみのため、即完了する
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
①障害検知
②1分間待機
③プライマリシャードの復旧

Shard 1
Primary
Data node 3
42
• 障害により失われたレプリカシャード(ここではShard 0, 1)を復旧させる
• プライマリシャードを別ノードにコピーし、レプリカシャードとする
• ネットワーク上でデータ転送が行われるため、時間がかかる可能性あり
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
①障害検知
②1分間待機
Shard 0
Replica
④レプリカシャードの復旧
③プライマリシャードの復旧Shard 1
Replica

インデックス復旧の優先度
43
複数のインデックス復旧が必要な場合、
次の優先度で順番に復旧する
1. 設定値index.priorityが大きいもの
 インデックス毎にREST APIで変更可能
 デフォルトの優先度は0
2. 作成日が新しいもの
3. インデックス名の辞書式順序で先に来るもの

Data Nodeの障害検出に関連する設定
44
1. リバランスも行われるため、実際の動作はもっと複雑
2. 関連する設定値(Zen Discoveryの場合)
No. 設定名設定内容デフォルト値
1 discovery.zen.fd.ping_interval ヘルスチェック間隔 1s
2 discovery.zen.fd.ping_timeout ヘルスチェックタイムアウト 30s
3 discovery.zen.fd.ping_retries ヘルスチェック回数 3
4 index.unassigned.node_left.delayed_timeout ノードの障害検出後、データ復旧開始まで
Master nodeが待機する時間
1m

MASTER NODEの障害検出
45

Master Node障害検出～目次
46
本章では次の内容を説明する
1. Master Nodeの障害検出の流れ
2. Split Brain対策
障害検出方法にはいくつか種類があるが、
Elasticsearchのデフォルト方式である
Zen Discoveryを前提として説明する

Master Nodeの障害検出の流れ(1/3)
47
• Master-eligible nodeはMaster nodeにヘルスチェックを行う
• ヘルスチェック間隔は1s
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
Shard 1
Replica
Data node 3

48
• Master nodeに障害が発生する
• タイムアウト30s×3回連続でヘルスチェックに失敗すると、
Master-eligible nodeは「Master nodeに障害が発生した」と認識する
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
Shard 1
Replica
Data node 3
①障害検知

49
• Master-eligible node間で新しいMaster nodeを選出
• 後で説明する「Split Brain対策」に注意
• 以降は通常の処理に戻る
Shard 0
Primary
Shard 2
Replica
Data node 1
Shard 2
Primary
Data node 2
Shard 0
Replica
Shard 1
Primary
Data node 4
Master
Shard 1
Replica
Data node 3
①障害検知
②新Masterを選出
Master

Split Brain対策(1/3)
50
次のケースでは、Master nodeが2台になってしまい、
矛盾した処理を行う危険性がある
Master
Master
Master Master
Master nodeにヘルスチェック
Master nodeは正常だが、ネッ
トワーク障害により、ヘルスチェック
が失敗
Master nodeに障害が発生し
たと思い込み、別のノードが
Master nodeになる
このような現象を「Split Brain」と言う
Node 1 Node 2
Node 1 Node 2
Node 1 Node 2
①
②
③

51
過半数以上のMaster-eligible nodeを確認可能な
ときだけ、Master nodeになれるようにする
Master
過半数(この場合は2ノード)確認できず、
Node 2はMasterになれない
Node 1はMasterのまま
Master
過半数確認できず、
Masterになれない
過半数確認し、
Masterになる
Master
過半数確認できず、
Masterをやめる
Node 1 Node 2
Node 1 Node 2
Node 3
Node 3
過半数(この場合は2ノード)確認し、
Node 2(or Node 3)は
Masterになる
Node 1はMasterをやめる

52
1. そのため、Master-eligible nodeは3以上の奇数
台用意する
2. 最低限必要なMaster-eligible nodeの台数を
elasticsearch.ymlの
discovery.zen.minimum_master_nodesに
設定する
3. 次の値を設定すること(小数点は切り捨て)
(Master-eligible nodeの台数 / 2) + 1

53
分散システムとしての側面も押さえ、
Elasticsearchを効果的に使いましょう！

Elasticsearch as a Distributed System

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Elasticsearch as a Distributed System

Similaire à Elasticsearch as a Distributed System (20)

Plus de Satoyuki Tsukano

Plus de Satoyuki Tsukano (10)

Elasticsearch as a Distributed System