SlideShare a Scribd company logo
1 of 22
Download to read offline
© 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の性能を引き出し、安定稼働させるためには
適切なチューニングを行う必要があります。
このスライドでは、仕事で適用して体験したことや
調査したことを共有したいと思います。
はじめに
© Acroquest Technology Co., Ltd. All rights reserved.3
 構成
はじめに
© Acroquest Technology Co., Ltd. All rights reserved.
Elasticsearchを使うときの注意点
4
© Acroquest Technology Co., Ltd. All rights reserved.
Elasticsearchを使うときの注意点
1. 2.X系を使うと安定度が増す
2. ヒープメモリを正しく設定する
3. シャード数を適切に設定する
4. データの復旧方法を確保する
5. stringをnot analyzedにできないか検討する
6. bulkAPIを使うときには設定を変える
5
© Acroquest Technology Co., Ltd. All rights reserved.6
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
© Acroquest Technology Co., Ltd. All rights reserved.7
2. ヒープメモリを正しく設定する
 Elasticsearchの性能を引き出すためには、メモリ
設定のチューニングは不可欠である。
 ヒープメモリを設定するときの注意点
1. 物理メモリの半分以上は指定しない。
– 物理メモリをファイルキャッシュとしてLuceneが利用するため。
2. 30GB以上指定しない。
– Javaのメモリ使用量が32GBを越えるとポインタのサイズが
2倍になり、逆にメモリ消費量が増えるため
(Compressed Oopsのため)
3. CMS GCを利用する。G1GCを利用しない。
– G1GCを使うとLuceneの一部で問題が出るらしい(?) 詳細は
未確認。
© Acroquest Technology Co., Ltd. All rights reserved.
 シャードとは
シャードはElasticsearchのインデックスを分解したもの
ノード1(Elasticsearch)
8
3.シャード数を適切に設定する
インデックス
シャード
0P
シャード
1P
シャード
2P
実ファイルとして保存
© Acroquest Technology Co., Ltd. All rights reserved.
 シャードとは
クラスタリングするときに、シャードが各ノードに配置される
ノード1
9
3.シャード数を適切に設定する
インデックス
シャード
0P
シャード
2R
ノード2 ノード3
インデックス
シャード
1P
シャード
0R
インデックス
シャード
2P
シャード
1R
Pはプライマリシャード、Rはレプリカシャードを表す
© Acroquest Technology Co., Ltd. All rights reserved.
 設定方法
インデックス作成時のみ設定可能
• インデックス作成時に設定する方法
• インデックステンプレートを使う。
10
3.シャード数を適切に設定する
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
}
© Acroquest Technology Co., Ltd. All rights reserved.
 シャードが多いとどうなるか?
ディスクアクセスが増えるので、IO待ちが発生する。
Kibanaなど、複数インデックスを検索する場合には、
影響が顕著に出る。
※デフォルト値は5。
ただし、1つのインデックスに大量のデータを
登録している場合には、性能が劣化する場合もあるので、
注意すること。
11
3.シャード数を適切に設定する
© Acroquest Technology Co., Ltd. All rights reserved.
 シャード数はいくつにするのがよいか?
正解はない。
1シャード、1G程度を目安にし、ベンチマークし、決定する。
12
3.シャード数を適切に設定する
© Acroquest Technology Co., Ltd. All rights reserved.13
4.データの復旧方法を確保する
 データ復旧の必要性
データの欠損を考慮する必要があるため。
 原因
1. ElasticsearchがOOMEで落ちていた。
(1.X系ではよく落ちました)
2. 1ノードで運用していると、ネットワーク瞬断など、仕組
みとして拾えない場合がある。
3. クラスタを組み、レプリカを設定することで、救出できる
可能性もあがるが、高負荷時にノード間でデータがずれ
る場合がある。
※3.は設定で回避可能であるが、性能との兼ね合いが
ある。
© Acroquest Technology Co., Ltd. All rights reserved.14
4.データの復旧方法を確保する
 データ復旧方法とは?
1. ログを残しておき、リアルタイム投入とは別のタイミング
で定期投入する。
→ただしログが重複して投入されないよう、ドキュメント
のIDをログ内容から算出する必要がある。
2. スナップショットを定期的に取る。
© Acroquest Technology Co., Ltd. All rights reserved.15
5. stringをnot analyzedにできないか検討する
 Elasticsearchでは、ドキュメントのインデックス時に、
string型のフィールドに対してanalyzer処理が行わ
れる。
ログ解析など、テキスト検索として利用しない場合
には、not analyzedに指定する方が、性能もよくな
るし、適切な結果が得られる。
© Acroquest Technology Co., Ltd. All rights reserved.16
 analyzer処理のデメリット
1. キーワード検索、suggestionを行わない場合には、
analyzer処理のコストが無駄に掛かる。
2. Kibanaの集計結果が期待通りにならないことがある。
5. stringをnot analyzedにできないか検討する
© Acroquest Technology Co., Ltd. All rights reserved.17
6. bulkAPIを使うときには設定を変える
 bulkAPIで一度に大量のデータを投入すると、
Elasticsearchが処理しきれない場合がある。
 原因
1. 内部キューのスレッド数の上限に達する。
2. 内部で行われるインデックスの更新処理が重い。
© Acroquest Technology Co., Ltd. All rights reserved.18
6. bulkAPIを使うときには設定を変える
1. 内部キューのスレッド数の上限に達する
Elasticsearchでは、内部に処理を行うキューとThreadPoolが
あるが、高負荷のときにキューが溢れることがある。
キューのデフォルト値は50、あふれるとデータが破棄される。
※ThreadPoolも設定可能だが、非推奨。
curl -XGET localhost:9200/_nodes/stats
...
“bulk”:{
“threads”: 4,
“queue”: 15, // 現在処理待ちのキューに溜まっているリクエスト数
"active": 4,
"rejected": 320, // これまでにリジェクトされたリクエスト数
"largest": 5,
"completed": 203312
}, ...
© Acroquest Technology Co., Ltd. All rights reserved.19
6. bulkAPIを使うときには設定を変える
1. 内部キューのスレッド数の上限に達する
キューが溢れた場合には、
429エラー(Too Many Request)が返り、
送信したドキュメントは破棄されてしまう。
 設定方法
curl -XPUT localhost:9200/_cluster/settings
{
"transient": {
"threadpool.bulk.queue_size": 10000
}
}
© Acroquest Technology Co., Ltd. All rights reserved.20
6. bulkAPIを使うときには設定を変える
2. 内部で行われるインデックスの更新処理が重い
Elasticsearchへのドキュメント登録はバッファに蓄積されるの
みであり、
定期的にインデックスへの反映処理が行われている。
更新処理はデフォルトで1秒に1回だが、
時間の掛かるbulkAPI実行時にはこの頻度で行う必要がない。
そのためbulkAPI実行時には、
更新間隔を-1(バッファの上限になるまで反映処理を行わない)
に設定し、
実行完了後に元に戻すとよい。
curl -XPOST 'localhost:9200/index-d/_settings?index.refresh_interval=-1s'
© Acroquest Technology Co., Ltd. All rights reserved.21
現在、取り組んでいるもの
 現在、取り組んでいるもの
1. 一定期間を過ぎたインデックスをクローズする、削除す
る。
– クローズされたインデックスは検索対象外となるが、オープンすれ
ば再び検索対象となる。
– 削除されたインデックスはディスクから削除される。
2. エイリアスを利用する。
3. _all, _sourceの廃止を検討する。
– allは全項目に対する串刺し検索で用いる。ログ収集においては
あまり使わない。
– _sourceはJSON化する前のログ。ハイライトや部分更新で用いる。
ログ収集にはあまり使わない。
© Acroquest Technology Co., Ltd. All rights reserved.
適切なチューニングを行い、
Elasticsearchを活用しましょう。
22

More Related Content

What's hot

Elasticsearchインデクシングのパフォーマンスを測ってみた
Elasticsearchインデクシングのパフォーマンスを測ってみたElasticsearchインデクシングのパフォーマンスを測ってみた
Elasticsearchインデクシングのパフォーマンスを測ってみたRyoji Kurosawa
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計Re: ゼロから始める監視設計
Re: ゼロから始める監視設計Masahito Zembutsu
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンKentaro Yoshida
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)NTT DATA Technology & Innovation
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことAmazon Web Services Japan
 
データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介Amazon Web Services Japan
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」Takuto Wada
 
AWSで作る分析基盤
AWSで作る分析基盤AWSで作る分析基盤
AWSで作る分析基盤Yu Otsubo
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法Takeshi Fukuhara
 
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮Hibino Hisashi
 
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Takahiko Ito
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAkihiro Kuwano
 
The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発Amazon Web Services Japan
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)NTT DATA Technology & Innovation
 
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティElasticsearch
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれKumazaki Hiroki
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 

What's hot (20)

Elasticsearchインデクシングのパフォーマンスを測ってみた
Elasticsearchインデクシングのパフォーマンスを測ってみたElasticsearchインデクシングのパフォーマンスを測ってみた
Elasticsearchインデクシングのパフォーマンスを測ってみた
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
 
データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
AWSで作る分析基盤
AWSで作る分析基盤AWSで作る分析基盤
AWSで作る分析基盤
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法
 
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
 
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 

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

CloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみたCloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみたTerui Masashi
 
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...オラクルエンジニア通信
 
Elasticsearch as a Distributed System
Elasticsearch as a Distributed SystemElasticsearch as a Distributed System
Elasticsearch as a Distributed SystemSatoyuki Tsukano
 
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報yoyamasaki
 
20190319 xtech recochoku_15m_pub
20190319 xtech recochoku_15m_pub20190319 xtech recochoku_15m_pub
20190319 xtech recochoku_15m_pubDai Fujikawa
 
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke HiramaInsight Technology, Inc.
 
MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編Takanori Sejima
 
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡心 谷本
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例terurou
 
Ingest node scripting_deep_dive
Ingest node scripting_deep_diveIngest node scripting_deep_dive
Ingest node scripting_deep_diveHiroshi Yoshioka
 
C24 analyzing oracle database hang issues using various diagnostics_pubic by ...
C24 analyzing oracle database hang issues using various diagnostics_pubic by ...C24 analyzing oracle database hang issues using various diagnostics_pubic by ...
C24 analyzing oracle database hang issues using various diagnostics_pubic by ...Insight Technology, Inc.
 
Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.Ryota Watabe
 
Intro2 Sqlanalyzer
Intro2 SqlanalyzerIntro2 Sqlanalyzer
Intro2 Sqlanalyzersaeka
 
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
CDP 勉強会 - Multiple Datacenter Deployment ガイダンスCDP 勉強会 - Multiple Datacenter Deployment ガイダンス
CDP 勉強会 - Multiple Datacenter Deployment ガイダンスKuniteru Asami
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Yoshinori Matsunobu
 
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月VirtualTech Japan Inc.
 
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記心 谷本
 
BtoCでバインド変数
BtoCでバインド変数BtoCでバインド変数
BtoCでバインド変数Yoshito Ueki
 

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

Elastic ML Introduction
Elastic ML IntroductionElastic ML Introduction
Elastic ML Introduction
 
CloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみたCloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみた
 
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
 
Elasticsearch as a Distributed System
Elasticsearch as a Distributed SystemElasticsearch as a Distributed System
Elasticsearch as a Distributed System
 
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
 
20190319 xtech recochoku_15m_pub
20190319 xtech recochoku_15m_pub20190319 xtech recochoku_15m_pub
20190319 xtech recochoku_15m_pub
 
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
 
MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編
 
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
 
Ingest node scripting_deep_dive
Ingest node scripting_deep_diveIngest node scripting_deep_dive
Ingest node scripting_deep_dive
 
C24 analyzing oracle database hang issues using various diagnostics_pubic by ...
C24 analyzing oracle database hang issues using various diagnostics_pubic by ...C24 analyzing oracle database hang issues using various diagnostics_pubic by ...
C24 analyzing oracle database hang issues using various diagnostics_pubic by ...
 
Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.
 
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
 
Intro2 Sqlanalyzer
Intro2 SqlanalyzerIntro2 Sqlanalyzer
Intro2 Sqlanalyzer
 
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
CDP 勉強会 - Multiple Datacenter Deployment ガイダンスCDP 勉強会 - Multiple Datacenter Deployment ガイダンス
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
 
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
 
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
 
BtoCでバインド変数
BtoCでバインド変数BtoCでバインド変数
BtoCでバインド変数
 

More from 崇介 藤井

チームを作る中で経験した自律的に成長するチームの作り方
チームを作る中で経験した自律的に成長するチームの作り方チームを作る中で経験した自律的に成長するチームの作り方
チームを作る中で経験した自律的に成長するチームの作り方崇介 藤井
 
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌崇介 藤井
 
非ITの宿泊業なのに、なぜDXを推進できるのか?
非ITの宿泊業なのに、なぜDXを推進できるのか?非ITの宿泊業なのに、なぜDXを推進できるのか?
非ITの宿泊業なのに、なぜDXを推進できるのか?崇介 藤井
 
僕があるいた内製化の3年間
僕があるいた内製化の3年間僕があるいた内製化の3年間
僕があるいた内製化の3年間崇介 藤井
 
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略崇介 藤井
 
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~崇介 藤井
 
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発崇介 藤井
 
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦いピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い崇介 藤井
 
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘いコロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い崇介 藤井
 
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて崇介 藤井
 
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方崇介 藤井
 
20191129 kyoto lt_up
20191129 kyoto lt_up20191129 kyoto lt_up
20191129 kyoto lt_up崇介 藤井
 
ホテル・旅館運営企業が 毎週リリースするDevOpsサイクルを作るまでの道のり
ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のりホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり
ホテル・旅館運営企業が 毎週リリースするDevOpsサイクルを作るまでの道のり崇介 藤井
 
システムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったことシステムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったこと崇介 藤井
 

More from 崇介 藤井 (14)

チームを作る中で経験した自律的に成長するチームの作り方
チームを作る中で経験した自律的に成長するチームの作り方チームを作る中で経験した自律的に成長するチームの作り方
チームを作る中で経験した自律的に成長するチームの作り方
 
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
 
非ITの宿泊業なのに、なぜDXを推進できるのか?
非ITの宿泊業なのに、なぜDXを推進できるのか?非ITの宿泊業なのに、なぜDXを推進できるのか?
非ITの宿泊業なのに、なぜDXを推進できるのか?
 
僕があるいた内製化の3年間
僕があるいた内製化の3年間僕があるいた内製化の3年間
僕があるいた内製化の3年間
 
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
 
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
 
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
 
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦いピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
 
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘いコロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
 
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
 
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
 
20191129 kyoto lt_up
20191129 kyoto lt_up20191129 kyoto lt_up
20191129 kyoto lt_up
 
ホテル・旅館運営企業が 毎週リリースするDevOpsサイクルを作るまでの道のり
ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のりホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり
ホテル・旅館運営企業が 毎週リリースするDevOpsサイクルを作るまでの道のり
 
システムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったことシステムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったこと
 

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

  • 1. © Acroquest Technology Co., Ltd. All rights reserved. Elasticsearchを使うときの注意点 Acroquest Technology株式会社 2016/01/28 藤井 崇介
  • 2. © Acroquest Technology Co., Ltd. All rights reserved.2  はじめに 社内でElasticsearchを使う機会が増えています。 一方で、こんな問題に遭うこともあります。 1. しばらく使っていると、OOMEが発生して落ちてしまう。 2. Elasticsearchが落ちていたせいで、データの復旧が必 要になったが、復旧する方法がない。 3. 想像していたほど性能が出ない。 4. どういうスペックのマシンを用意すればいいかわからな い? Elasticsearchの性能を引き出し、安定稼働させるためには 適切なチューニングを行う必要があります。 このスライドでは、仕事で適用して体験したことや 調査したことを共有したいと思います。 はじめに
  • 3. © Acroquest Technology Co., Ltd. All rights reserved.3  構成 はじめに
  • 4. © Acroquest Technology Co., Ltd. All rights reserved. Elasticsearchを使うときの注意点 4
  • 5. © Acroquest Technology Co., Ltd. All rights reserved. Elasticsearchを使うときの注意点 1. 2.X系を使うと安定度が増す 2. ヒープメモリを正しく設定する 3. シャード数を適切に設定する 4. データの復旧方法を確保する 5. stringをnot analyzedにできないか検討する 6. bulkAPIを使うときには設定を変える 5
  • 6. © Acroquest Technology Co., Ltd. All rights reserved.6 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
  • 7. © Acroquest Technology Co., Ltd. All rights reserved.7 2. ヒープメモリを正しく設定する  Elasticsearchの性能を引き出すためには、メモリ 設定のチューニングは不可欠である。  ヒープメモリを設定するときの注意点 1. 物理メモリの半分以上は指定しない。 – 物理メモリをファイルキャッシュとしてLuceneが利用するため。 2. 30GB以上指定しない。 – Javaのメモリ使用量が32GBを越えるとポインタのサイズが 2倍になり、逆にメモリ消費量が増えるため (Compressed Oopsのため) 3. CMS GCを利用する。G1GCを利用しない。 – G1GCを使うとLuceneの一部で問題が出るらしい(?) 詳細は 未確認。
  • 8. © Acroquest Technology Co., Ltd. All rights reserved.  シャードとは シャードはElasticsearchのインデックスを分解したもの ノード1(Elasticsearch) 8 3.シャード数を適切に設定する インデックス シャード 0P シャード 1P シャード 2P 実ファイルとして保存
  • 9. © Acroquest Technology Co., Ltd. All rights reserved.  シャードとは クラスタリングするときに、シャードが各ノードに配置される ノード1 9 3.シャード数を適切に設定する インデックス シャード 0P シャード 2R ノード2 ノード3 インデックス シャード 1P シャード 0R インデックス シャード 2P シャード 1R Pはプライマリシャード、Rはレプリカシャードを表す
  • 10. © Acroquest Technology Co., Ltd. All rights reserved.  設定方法 インデックス作成時のみ設定可能 • インデックス作成時に設定する方法 • インデックステンプレートを使う。 10 3.シャード数を適切に設定する 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 }
  • 11. © Acroquest Technology Co., Ltd. All rights reserved.  シャードが多いとどうなるか? ディスクアクセスが増えるので、IO待ちが発生する。 Kibanaなど、複数インデックスを検索する場合には、 影響が顕著に出る。 ※デフォルト値は5。 ただし、1つのインデックスに大量のデータを 登録している場合には、性能が劣化する場合もあるので、 注意すること。 11 3.シャード数を適切に設定する
  • 12. © Acroquest Technology Co., Ltd. All rights reserved.  シャード数はいくつにするのがよいか? 正解はない。 1シャード、1G程度を目安にし、ベンチマークし、決定する。 12 3.シャード数を適切に設定する
  • 13. © Acroquest Technology Co., Ltd. All rights reserved.13 4.データの復旧方法を確保する  データ復旧の必要性 データの欠損を考慮する必要があるため。  原因 1. ElasticsearchがOOMEで落ちていた。 (1.X系ではよく落ちました) 2. 1ノードで運用していると、ネットワーク瞬断など、仕組 みとして拾えない場合がある。 3. クラスタを組み、レプリカを設定することで、救出できる 可能性もあがるが、高負荷時にノード間でデータがずれ る場合がある。 ※3.は設定で回避可能であるが、性能との兼ね合いが ある。
  • 14. © Acroquest Technology Co., Ltd. All rights reserved.14 4.データの復旧方法を確保する  データ復旧方法とは? 1. ログを残しておき、リアルタイム投入とは別のタイミング で定期投入する。 →ただしログが重複して投入されないよう、ドキュメント のIDをログ内容から算出する必要がある。 2. スナップショットを定期的に取る。
  • 15. © Acroquest Technology Co., Ltd. All rights reserved.15 5. stringをnot analyzedにできないか検討する  Elasticsearchでは、ドキュメントのインデックス時に、 string型のフィールドに対してanalyzer処理が行わ れる。 ログ解析など、テキスト検索として利用しない場合 には、not analyzedに指定する方が、性能もよくな るし、適切な結果が得られる。
  • 16. © Acroquest Technology Co., Ltd. All rights reserved.16  analyzer処理のデメリット 1. キーワード検索、suggestionを行わない場合には、 analyzer処理のコストが無駄に掛かる。 2. Kibanaの集計結果が期待通りにならないことがある。 5. stringをnot analyzedにできないか検討する
  • 17. © Acroquest Technology Co., Ltd. All rights reserved.17 6. bulkAPIを使うときには設定を変える  bulkAPIで一度に大量のデータを投入すると、 Elasticsearchが処理しきれない場合がある。  原因 1. 内部キューのスレッド数の上限に達する。 2. 内部で行われるインデックスの更新処理が重い。
  • 18. © Acroquest Technology Co., Ltd. All rights reserved.18 6. bulkAPIを使うときには設定を変える 1. 内部キューのスレッド数の上限に達する Elasticsearchでは、内部に処理を行うキューとThreadPoolが あるが、高負荷のときにキューが溢れることがある。 キューのデフォルト値は50、あふれるとデータが破棄される。 ※ThreadPoolも設定可能だが、非推奨。 curl -XGET localhost:9200/_nodes/stats ... “bulk”:{ “threads”: 4, “queue”: 15, // 現在処理待ちのキューに溜まっているリクエスト数 "active": 4, "rejected": 320, // これまでにリジェクトされたリクエスト数 "largest": 5, "completed": 203312 }, ...
  • 19. © Acroquest Technology Co., Ltd. All rights reserved.19 6. bulkAPIを使うときには設定を変える 1. 内部キューのスレッド数の上限に達する キューが溢れた場合には、 429エラー(Too Many Request)が返り、 送信したドキュメントは破棄されてしまう。  設定方法 curl -XPUT localhost:9200/_cluster/settings { "transient": { "threadpool.bulk.queue_size": 10000 } }
  • 20. © Acroquest Technology Co., Ltd. All rights reserved.20 6. bulkAPIを使うときには設定を変える 2. 内部で行われるインデックスの更新処理が重い Elasticsearchへのドキュメント登録はバッファに蓄積されるの みであり、 定期的にインデックスへの反映処理が行われている。 更新処理はデフォルトで1秒に1回だが、 時間の掛かるbulkAPI実行時にはこの頻度で行う必要がない。 そのためbulkAPI実行時には、 更新間隔を-1(バッファの上限になるまで反映処理を行わない) に設定し、 実行完了後に元に戻すとよい。 curl -XPOST 'localhost:9200/index-d/_settings?index.refresh_interval=-1s'
  • 21. © Acroquest Technology Co., Ltd. All rights reserved.21 現在、取り組んでいるもの  現在、取り組んでいるもの 1. 一定期間を過ぎたインデックスをクローズする、削除す る。 – クローズされたインデックスは検索対象外となるが、オープンすれ ば再び検索対象となる。 – 削除されたインデックスはディスクから削除される。 2. エイリアスを利用する。 3. _all, _sourceの廃止を検討する。 – allは全項目に対する串刺し検索で用いる。ログ収集においては あまり使わない。 – _sourceはJSON化する前のログ。ハイライトや部分更新で用いる。 ログ収集にはあまり使わない。
  • 22. © Acroquest Technology Co., Ltd. All rights reserved. 適切なチューニングを行い、 Elasticsearchを活用しましょう。 22