elasticsearch クラスタを EC2 上に構築する

はじめに

• elasticsearch クラスタを EC2 上に構築してみてクラスタ構築の手順について整理する
• 既に稼働しているクラスタにノードを追加する手順についても整理する

---

参考

• ElasticSearch入門
• Cluster機能を使う – AWSで始めるElasticSearch(2)
• elasticsearch on ec2

---

クラスタ構築の手順

ノード間でクラスタ名をあわせる

elasticsearch は基本的にノード間でクラスタ名を同じ名前にしておくと勝手にクラスタ構成を組んでくれる。

cluster.name: mycluster-test

どうやって仲間を見つけるか？

クラスタ内の仲間を見つける場合、elasticsearch.yml に以下のように書かれておりデフォルトでは Multicast を使って仲間を見つける。

Discovery infrastructure ensures nodes can be found within a cluster and master node is elected. Multicast discovery is the default.

また、仲間の探索には zen discovery が使われているとのこと。

EC2 の場合はちょっと事情が違う

EC2 上で elasticsearch クラスタを構築する場合にはちょっとした事情が介在してインストールして即クラスタ構成とはいかない。その大人の事情*1とは EC2 ではマルチキャストが利用出来ないとのこと。ということで、以下のようにユニキャストで仲間を見つける設定を行う。

--- elasticsearch.yml.original  2014-01-18 23:33:35.981570864 +0900
+++ elasticsearch.yml   2014-01-19 00:23:13.686020271 +0900

@@ -316,12 +316,12 @@
 #
 # 1. Disable multicast discovery (enabled by default):
 #
-# discovery.zen.ping.multicast.enabled: false
+discovery.zen.ping.multicast.enabled: false
 #
 # 2. Configure an initial list of master nodes in the cluster
 #    to perform discovery when new nodes (master or data) are started:
 #
-# discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
+discovery.zen.ping.unicast.hosts: ["xxx.xxx.xxx.1", "xxx.xxx.xxx.2"]

 # EC2 discovery allows to use AWS EC2 API in order to perform discovery.

上記のように discovery.zen.ping.multicast.enabled: false を有効に*2して仲間となる IP アドレスをそれぞれ指定してあげる。この設定は仲間となる全てのノードで設定する（した）。設定後、elasticsearch を再起動するとクラスタが構成される。このクラスタを見た目も鮮やかに管理したい場合には elasticsearch-head ã‚„ ElasticHQ を使うと良いと思う。以下、elasticsearch-head でインデックス内のシャードの状態を確認した図。

また、以下は同じクラスタを ElasticHQ で確認した図。

見た目は ElasticHQ が美しいが elasticsearch-head の方がシャード配置状況がパッと見れて嬉しいかも。ということで、実際のご利用はお好みで。

---

クラスタを色々とイジる

今回は fluent-plugin-twitter で収集したツイートを elasticsearch クラスタに突っ込んで色々とイジってみる。

既に稼働しているクラスタにノードを追加してみる

既に 2 台のノードで稼働しているクラスタに新たにノードを追加する。すべてのノードに新しい仲間を discovery.zen.ping.unicast.hosts に追加する。

discovery.zen.ping.unicast.hosts: ["xxx.xxx.xxx.1", "xxx.xxx.xxx.2", "xxx.xxx.xxx.3"]

各々のノードを再起動すると以下のように 3 ノード構成のクラスタが出来上がる。

「★」マークが master node の証。このインデックスは 5 つのシャードに 1 つのレプリカ（複製）なのでトータル 10 シャードを 3 ノードに分割している状態。

障害発生！（1）（worker node が停止した！）

worker node の elasticsearch を停止した場合...

シャードの再配置が発生して 10 シャードを 2 ノードで仲良く受け持つことになる。データ量も少ない為か再配置も一瞬。再度、elasticsearch を起動すると...

別の名前（停止前は N'Garai）で再デビューする。シャードの再配置も行われる。

障害発生！（2）（master node が停止した！）

ヤバイ、master node が停止した！（ら）以下のように問答無用に worker node の一台が master node に昇格してシャードの再配置も行われる。

改めて元 master node の elasticsearch を起動させると...

先ほどの worker node の時と同様に別の名前で再デビュー。但し、master node に戻ることはなくあくまでも worker node として再デビューするようだ。どのノードがマスターノードになるのかについてもう少し突っ込んで調べてみたい。

---

補足

検証していて気づいた点等。

• t1.micro で検証を行ったが swap 領域が無いと elasticsearch が起動しないことがあった
• ただ、swap 領域無くても起動したりすることもあった

---

次回は...

• EC2 で AWS API を利用して自動的にクラスタを構成出来る AWS Cloud Plugin for Elasticsearch を試してみる
• どーやってマスターが決まるのかを確認する
• クラスタへのデータ登録ってそもそもどうするのか？（fluent-plugin-elasticsearch等でマスターノードの IP しか指定していない場合とか...）

*1:絶対に大人の事情では無い

*2:false を有効にって一瞬？ってなる