Elasticsearchの運用は大変（冷凍庫のガリガリ君食ったのは誰だ編）

GYAOの窓際エンジニア　玉利です。

休日返上で仕事をするようになると、家計が大変です。

まずは、弁当をつくらなくなります。仕入れも仕込みもできないので仕方ありません。今は夏だから食中毒こわいし。。。とか適当な理由をつけますが、単に家に帰ってくると抜け殻でなにもできないからです。１日800円x25くらいになるので月2万円近くアップ。

そして、ヨメの面倒を見るのがおざなりになるため、PKO(Peace Keeping Operation)活動として、なぜかヨメの軍事費（主に服）が増大します。これで10万円の出費。

自分も、細々したものを通販でポチってしまうので、今月マジでやばい。定時で効率よく仕事をするように、残業代の規定は雀の涙になるように設定されているので、普段はいいけれど炎上案件に関わると無事死ねます。

そして、我々の作ったESクラスタも、同様にメモリという家計をどうやってバランスさせるかが問題でした。

HEAPメモリ問題にもうすこしお付き合いください

設定をいじりまくる（失敗）

Quiteに先人たちがたくさんの資料を残してくれていました。公式資料も英語ですが、なんとか我々でも読める優しい英語です。

まずはHEAPサイズをいじりました。ESの資料では、実メモリの半分以下、なおかつ32GBを超えないことと書いてあります、しかしそんなに強力な実機をぶちこんでるわけではないので、メモリはインスタンス半分の6GBに設定しました。これを「もしかしたらGCが早めに反応するかも」と、4GBとか少なめにもしてみましたが、死期が早くなるだけでした。素直に実メモリの半分を設定しましょう。

/etc/init.d/elasticsearch

# 12GMEMのインスタンスを利用しているので、半分をESに割当
ES_HEAP_SIZE=6g
MAX_OPEN_FILES=65535

shard/replicaの数を調整する

初めてのES運用ということで、保守的に手厚い設定をしたのですが、ドキュメント数が増えるだけメモリには厳しいものになりました。shardが増えるとレスポンスが改善しますが、その分メモリを圧迫します。最速を目指すのではなく、困らない程度にshardの数を減らすのが良さそうです。

当初は20 shard(サーバ数= shard数）に設定しました。これだとちょっとHEAPメモリ消費が速いので、BCP片系を設定しながら、減らすことにしました。

１クラスタ20台構成で、10 shard 2replicaにしました。BCP構成をとっているので、6面ミラーとなり安全性は担保できてると思います。このあたりは正解は無いので、ビジネス要件に合わせた設計を行ってください。

elasticsearch.yml

## パフォーマンスのためシェードはサーバ数の半分で10,安全のためレプリカは1 -> 2 に増やす。BCP構成でトータル6面のミラー
index.number_of_shards: 10
index.number_of_replicas: 2

これで、ずいぶんメモリが楽になりました。

なんか1台だけ、やばいやつがいる

我々のチームには、CICEO(Chief ICE Officer)という要職のメンバー、二次元氏がいます。メンバーが消費するアイスキャンディーの在庫について責任を持っているのです。だいたい1 issueを3アイス(3人日)などと計算しています。アイスが切れるとパフォーマンスが低下するので、我々にとっては非常に大切なロジスティクス担当です。

で、アイスをかじりながら火照ったアタマを冷やしつつ仕事をしています、もう2週間以上、綱渡りの運用をしているのですがどうしよう。。。オフィス移転でアイスのまとめ買い出しが難しくなったのでピンチです。

そして、elasticsearch[01-20]という20台1クラスタx2のサーバを運用しているのですが、片系の01だけ微妙にメモリの消費が速いのです。このサーバには、企画さんが使うKibanaと、Kibanaに依存したMarvelプラグインが入っていました。

記事に紹介があるMarvelは強力なモニタリングツールだと思います。ただし現在、ESの監視はNewRelicのElasticsearchプラグインで行っています。たぶんMarvelはなくても大丈夫そうなので、思い切って外すことにしました。

まだ、メモリ盗み食いしてるやつがいる

これで少し改善しました。marvelのインデックスが毎日増えていって運用が大変ということもなくなりました。

しかし、やはりメモリを消費する速度が速いのです。そして27日のトラブルで、クラスタ全体が重くなった時に全台リスタートをかけたのですが、elasticsearch01だけリスタートしただけで速度がガクンと改善しました。

「01が足引っ張ってるんじゃね？」

その時は再起動でなんとかなったのですが、どうやらkibanaが足を引っ張ってるのが読めてきました。散々悩んだ結果、ついに先達の資料を見つけました。

マスタカの ChangeLog メモ
https://masutaka.net/chalow/2016-06-26-1.html

マスタカ氏は、「Node.JSがメモリを1.5GB食う」と書いておられます。私がHEAPの動きを見てる限り一致しました。

というわけで、手動で起動スクリプトに以下設定を入れ、設定スクリプトにもメモを書きました。

これで、01のメモリが厳しい問題が解決できました。他のサーバとたいして差のない利用率になっています。冷蔵庫のアイスを盗み食いしたメモリイーターはnode.jsでした。nodeには別案件でも過去２回ひどい目に遭わされていて、できれば避けて通りたいとしみじみ感じました。

# Please add following couple of lines in /etc/init.d/kibana
+ NODE_OPTIONS="--max-old-space-size=256"
+ export NODE_OPTIONS

しかし、elasticsearchにしろkibanaにしろ、/etc/init.d以下をいじるというのはなんとかしてもらえないものですかね。設定が手動になってしまうので構成管理上めんどくさすぎます。

とりあえず、メモリ対策は以下２個

結論としては、我々の運用において以下２点が運用ノウハウと思いました。定期的再起動は、できればなくしたいのですが、どなたか良いプランお持ちでないでしょうか？

• 定期的再起動(月火・木金でcronで回してます＞毎日再起動を入れることにしました)
• kibanaの設定見直し