Elasticsearchを使うときの注意点公開用スライド

© Acroquest Technology Co., Ltd. All rights reserved.
Elasticsearchを使うときの注意点
Acroquest Technology株式会社
2016/01/28
藤井崇介

© Acroquest Technology Co., Ltd. All rights reserved.2
 はじめに
社内でElasticsearchを使う機会が増えています。
一方で、こんな問題に遭うこともあります。
1. しばらく使っていると、OOMEが発生して落ちてしまう。
2. Elasticsearchが落ちていたせいで、データの復旧が必
要になったが、復旧する方法がない。
3. 想像していたほど性能が出ない。
4. どういうスペックのマシンを用意すればいいかわからな
い？
Elasticsearchの性能を引き出し、安定稼働させるためには
適切なチューニングを行う必要があります。
このスライドでは、仕事で適用して体験したことや
調査したことを共有したいと思います。
はじめに

 構成
はじめに

4

1. 2.X系を使うと安定度が増す
2. ヒープメモリを正しく設定する
3. シャード数を適切に設定する
4. データの復旧方法を確保する
5. stringをnot analyzedにできないか検討する
6. bulkAPIを使うときには設定を変える
5

1. 2.X系を使うと安定度が増す
 1.X系では、ヒープメモリを大量に消費する。
導入当初は、2か月に1回ElasticsearchがOOMEに
より、停止する問題が発生していた。
• 全文検索を効率的に行うため、Luceneが生成したイン
デックスから、検索用のインデックスを内部で生成してい
る。
• 1.x系ではインデックス情報をJavaのヒープメモリに保持
する方法が使われていたが、2.x系ではファイルを利用
する方法（Doc Values）がデフォルトになった。
Doc Valuesの詳細については以下を参照。
https://www.elastic.co/guide/en/elasticsearch/guide/current/doc-values.html

2. ヒープメモリを正しく設定する
 Elasticsearchの性能を引き出すためには、メモリ
設定のチューニングは不可欠である。
 ヒープメモリを設定するときの注意点
1. 物理メモリの半分以上は指定しない。
– 物理メモリをファイルキャッシュとしてLuceneが利用するため。
2. 30GB以上指定しない。
– Javaのメモリ使用量が32GBを越えるとポインタのサイズが
2倍になり、逆にメモリ消費量が増えるため
（Compressed Oopsのため）
3. CMS GCを利用する。G1GCを利用しない。
– G1GCを使うとLuceneの一部で問題が出るらしい（？）詳細は
未確認。

 シャードとは
シャードはElasticsearchのインデックスを分解したもの
ノード1（Elasticsearch）
8
3.シャード数を適切に設定する
インデックス
シャード
0P
シャード
1P
シャード
2P
実ファイルとして保存

 シャードとは
クラスタリングするときに、シャードが各ノードに配置される
ノード1
9
インデックス
シャード
0P
シャード
2R
ノード2 ノード3
インデックス
シャード
1P
シャード
0R
インデックス
シャード
2P
シャード
1R
Pはプライマリシャード、Rはレプリカシャードを表す

 設定方法
インデックス作成時のみ設定可能
• インデックス作成時に設定する方法
• インデックステンプレートを使う。
10
curl -XPUT localhost:9200/index-1 '{
"settings" : {
"number_of_shards" : 1
}
}'
curl -XPUT localhost:9200/template-1 ' {
"template": “index-*",
"settings": {
"number_of_shards": 1
},
order : 1
}

 シャードが多いとどうなるか？
ディスクアクセスが増えるので、IO待ちが発生する。
Kibanaなど、複数インデックスを検索する場合には、
影響が顕著に出る。
※デフォルト値は5。
ただし、1つのインデックスに大量のデータを
登録している場合には、性能が劣化する場合もあるので、
注意すること。
11

 シャード数はいくつにするのがよいか？
正解はない。
1シャード、1G程度を目安にし、ベンチマークし、決定する。
12

4.データの復旧方法を確保する
 データ復旧の必要性
データの欠損を考慮する必要があるため。
 原因
1. ElasticsearchがOOMEで落ちていた。
（1.X系ではよく落ちました）
2. 1ノードで運用していると、ネットワーク瞬断など、仕組
みとして拾えない場合がある。
3. クラスタを組み、レプリカを設定することで、救出できる
可能性もあがるが、高負荷時にノード間でデータがずれ
る場合がある。
※3.は設定で回避可能であるが、性能との兼ね合いが
ある。

4.データの復旧方法を確保する
 データ復旧方法とは？
1. ログを残しておき、リアルタイム投入とは別のタイミング
で定期投入する。
→ただしログが重複して投入されないよう、ドキュメント
のIDをログ内容から算出する必要がある。
2. スナップショットを定期的に取る。

 Elasticsearchでは、ドキュメントのインデックス時に、
string型のフィールドに対してanalyzer処理が行わ
れる。
ログ解析など、テキスト検索として利用しない場合
には、not analyzedに指定する方が、性能もよくな
るし、適切な結果が得られる。

 analyzer処理のデメリット
1. キーワード検索、suggestionを行わない場合には、
analyzer処理のコストが無駄に掛かる。
2. Kibanaの集計結果が期待通りにならないことがある。

 bulkAPIで一度に大量のデータを投入すると、
Elasticsearchが処理しきれない場合がある。
 原因
1. 内部キューのスレッド数の上限に達する。
2. 内部で行われるインデックスの更新処理が重い。

1. 内部キューのスレッド数の上限に達する
Elasticsearchでは、内部に処理を行うキューとThreadPoolが
あるが、高負荷のときにキューが溢れることがある。
キューのデフォルト値は50、あふれるとデータが破棄される。
※ThreadPoolも設定可能だが、非推奨。
curl -XGET localhost:9200/_nodes/stats
...
“bulk”:{
“threads”: 4,
“queue”: 15, // 現在処理待ちのキューに溜まっているリクエスト数
"active": 4,
"rejected": 320, // これまでにリジェクトされたリクエスト数
"largest": 5,
"completed": 203312
}, ...

1. 内部キューのスレッド数の上限に達する
キューが溢れた場合には、
429エラー（Too Many Request）が返り、
送信したドキュメントは破棄されてしまう。
 設定方法
curl -XPUT localhost:9200/_cluster/settings
{
"transient": {
"threadpool.bulk.queue_size": 10000
}
}

2. 内部で行われるインデックスの更新処理が重い
Elasticsearchへのドキュメント登録はバッファに蓄積されるの
みであり、
定期的にインデックスへの反映処理が行われている。
更新処理はデフォルトで1秒に1回だが、
時間の掛かるbulkAPI実行時にはこの頻度で行う必要がない。
そのためbulkAPI実行時には、
更新間隔を-1(バッファの上限になるまで反映処理を行わない)
に設定し、
実行完了後に元に戻すとよい。
curl -XPOST 'localhost:9200/index-d/_settings?index.refresh_interval=-1s'

現在、取り組んでいるもの
 現在、取り組んでいるもの
1. 一定期間を過ぎたインデックスをクローズする、削除す
る。
– クローズされたインデックスは検索対象外となるが、オープンすれ
ば再び検索対象となる。
– 削除されたインデックスはディスクから削除される。
2. エイリアスを利用する。
3. _all, _sourceの廃止を検討する。
– allは全項目に対する串刺し検索で用いる。ログ収集においては
あまり使わない。
– _sourceはJSON化する前のログ。ハイライトや部分更新で用いる。
ログ収集にはあまり使わない。

適切なチューニングを行い、
Elasticsearchを活用しましょう。
22

Elasticsearchを使うときの注意点 公開用スライド

More Related Content

What's hot

Similar to Elasticsearchを使うときの注意点 公開用スライド

More from 崇介 藤井