Submit Search
Upload
Elasticsearchを使うときの注意点 公開用スライド
•
20 likes
•
30,510 views
崇
崇介 藤井
Follow
Elasticsearchを初めて使うときの注意点をまとめてみました。
Read less
Read more
Technology
Report
Share
Report
Share
1 of 22
Download now
Download to read offline
Recommended
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアル
貴志 上坂
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみよう
Shinsuke Sugaya
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Amazon Web Services Japan
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
Recommended
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアル
貴志 上坂
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみよう
Shinsuke Sugaya
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Amazon Web Services Japan
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
Elasticsearchインデクシングのパフォーマンスを測ってみた
Elasticsearchインデクシングのパフォーマンスを測ってみた
Ryoji Kurosawa
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
NTT DATA Technology & Innovation
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介
Amazon Web Services Japan
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
AWSで作る分析基盤
AWSで作る分析基盤
Yu Otsubo
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法
Takeshi Fukuhara
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
Hibino Hisashi
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Takahiko Ito
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発
Amazon Web Services Japan
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
Elasticsearch
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Elastic ML Introduction
Elastic ML Introduction
Hiroshi Yoshioka
CloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみた
Terui Masashi
More Related Content
What's hot
Elasticsearchインデクシングのパフォーマンスを測ってみた
Elasticsearchインデクシングのパフォーマンスを測ってみた
Ryoji Kurosawa
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
NTT DATA Technology & Innovation
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介
Amazon Web Services Japan
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
AWSで作る分析基盤
AWSで作る分析基盤
Yu Otsubo
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法
Takeshi Fukuhara
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
Hibino Hisashi
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Takahiko Ito
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発
Amazon Web Services Japan
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インデクシングのパフォーマンスを測ってみた
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
Kubernetes 疲れに Azure Container Apps はいかがでしょうか?(江東区合同ライトニングトーク 発表資料)
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
データ活用を加速するAWS分析サービスのご紹介
データ活用を加速するAWS分析サービスのご紹介
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
AWSで作る分析基盤
AWSで作る分析基盤
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
Azure Monitor Logで実現するモダンな管理手法
Azure Monitor Logで実現するモダンな管理手法
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
The Twelve-Factor Appで考えるAWSのサービス開発
The Twelve-Factor Appで考えるAWSのサービス開発
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
ログ+メトリック+トレースの組み合わせで構築する一元的なオブザーバビリティ
分散システムについて語らせてくれ
分散システムについて語らせてくれ
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Similar to Elasticsearchを使うときの注意点 公開用スライド
Elastic ML Introduction
Elastic ML Introduction
Hiroshi Yoshioka
CloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみた
Terui Masashi
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
オラクルエンジニア通信
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
Satoyuki Tsukano
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
yoyamasaki
20190319 xtech recochoku_15m_pub
20190319 xtech recochoku_15m_pub
Dai Fujikawa
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
Insight Technology, Inc.
MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編
Takanori Sejima
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
心 谷本
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
terurou
Ingest node scripting_deep_dive
Ingest node scripting_deep_dive
Hiroshi Yoshioka
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.
Ryota Watabe
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
NTT DATA OSS Professional Services
Intro2 Sqlanalyzer
Intro2 Sqlanalyzer
saeka
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
Kuniteru Asami
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
Yoshinori Matsunobu
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
VirtualTech Japan Inc.
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
心 谷本
BtoCでバインド変数
BtoCでバインド変数
Yoshito Ueki
Similar to Elasticsearchを使うときの注意点 公開用スライド
(20)
Elastic ML Introduction
Elastic ML Introduction
CloudWatch(+sns+sqs)で障害対応を自動化してみた
CloudWatch(+sns+sqs)で障害対応を自動化してみた
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義!!ストレージ管理のベストプラクティス ~ASMからExada...
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
MySQL Cluster 解説 & MySQL Cluster 7.3 最新情報
20190319 xtech recochoku_15m_pub
20190319 xtech recochoku_15m_pub
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
[C31]世界最速カラムナーDBは本物だ! by Daisuke Hirama
MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
Ingest 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 ...
Analyzing Oracle Database hang issues using various diagnostics.
Analyzing Oracle Database hang issues using various diagnostics.
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
Intro2 Sqlanalyzer
Intro2 Sqlanalyzer
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
AIの力で障害検知・解析をサポート!Loom(ログ解析ソリューション)のご紹介 - OpenStack最新情報セミナー 2017年7月
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
人気番組との戦い! Javaシステムのパフォーマンスチューニング奮闘記
BtoCでバインド変数
BtoCでバインド変数
More from 崇介 藤井
チームを作る中で経験した自律的に成長するチームの作り方
チームを作る中で経験した自律的に成長するチームの作り方
崇介 藤井
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
崇介 藤井
非ITの宿泊業なのに、なぜDXを推進できるのか?
非ITの宿泊業なのに、なぜDXを推進できるのか?
崇介 藤井
僕があるいた内製化の3年間
僕があるいた内製化の3年間
崇介 藤井
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
崇介 藤井
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
崇介 藤井
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
崇介 藤井
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
崇介 藤井
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
崇介 藤井
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
崇介 藤井
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
崇介 藤井
20191129 kyoto lt_up
20191129 kyoto lt_up
崇介 藤井
ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり
ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり
崇介 藤井
システムを毎週リリースするために頑張ったこと
システムを毎週リリースするために頑張ったこと
崇介 藤井
More from 崇介 藤井
(14)
チームを作る中で経験した自律的に成長するチームの作り方
チームを作る中で経験した自律的に成長するチームの作り方
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌
非ITの宿泊業なのに、なぜDXを推進できるのか?
非ITの宿泊業なのに、なぜDXを推進できるのか?
僕があるいた内製化の3年間
僕があるいた内製化の3年間
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
コロナ禍に躍進した星野リゾートのIT戦略 ~コストカットと事業拡大を両立するAWS活用術~
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
旅館運営企業で実現した現場出身者の力を活かしたアジャイル開発
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
ピンチはチャンス!大逆境のコロナ期での現場とエンジニアの戦い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
コロナで大打撃を受けた宿泊業のエンジニアの逆境との闘い
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
旅館運営企業にエンジニアがもたらした価値とこれからの戦いについて
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
創業105年の旅館運営企業が実現した 毎週リリースするチームの作り方
20191129 kyoto lt_up
20191129 kyoto lt_up
ホテル・旅館運営企業が毎週リリースする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
Download now