SlideShare a Scribd company logo
© 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

What's hot (20)

今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
 
事例で学ぶApache Cassandra
事例で学ぶApache Cassandra事例で学ぶApache Cassandra
事例で学ぶApache Cassandra
 
Fess/Elasticsearchを使った業務で使える?全文検索への道
Fess/Elasticsearchを使った業務で使える?全文検索への道Fess/Elasticsearchを使った業務で使える?全文検索への道
Fess/Elasticsearchを使った業務で使える?全文検索への道
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
各種データベースの特徴とパフォーマンス比較
各種データベースの特徴とパフォーマンス比較各種データベースの特徴とパフォーマンス比較
各種データベースの特徴とパフォーマンス比較
 
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
 
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみようSolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみよう
 
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかSQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するか
 
Apache Spark 2.4 and 3.0 What's Next?
Apache Spark 2.4 and 3.0  What's Next? Apache Spark 2.4 and 3.0  What's Next?
Apache Spark 2.4 and 3.0 What's Next?
 
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Apache Atlasの現状とデータガバナンス事例 #hadoopreading
Apache Atlasの現状とデータガバナンス事例 #hadoopreadingApache Atlasの現状とデータガバナンス事例 #hadoopreading
Apache Atlasの現状とデータガバナンス事例 #hadoopreading
 
IoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache FlinkIoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache Flink
 
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
 
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
サンプルアプリケーションで学ぶApache Cassandraを使ったJavaアプリケーションの作り方
 
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
 
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
 

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...
オラクルエンジニア通信
 
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
Insight Technology, Inc.
 
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
心 谷本
 
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
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
Yoshinori Matsunobu
 
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.
 
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でバインド変数
 
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントPostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
 

More from 崇介 藤井

みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
崇介 藤井
 

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サイクルを作るまでの道のり
 
システムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったことシステムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったこと
 

Recently uploaded

2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
ssuserbefd24
 

Recently uploaded (11)

2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
 
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
YugabyteDB適用に向けた取り組みと隠れた魅力 (DSS Asia 2024 発表資料)
 
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
論文紹介: Exploiting semantic segmentation to boost reinforcement learning in vid...
 
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
MPAなWebフレームワーク、Astroの紹介 (その2) 2024/05/24の勉強会で発表されたものです。
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 
20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf
 
【AI論文解説】Consistency ModelとRectified Flow
【AI論文解説】Consistency ModelとRectified Flow【AI論文解説】Consistency ModelとRectified Flow
【AI論文解説】Consistency ModelとRectified Flow
 
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
 
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
 
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
 
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
論文紹介: Offline Q-Learning on diverse Multi-Task data both scales and generalizes
 

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