Official
Elastic{ON}報告＋Sheild、Watcherの紹介（仮？） Elastic Jun Ohtani @johtani
AWSで実現するelasticsearchの大規模運用 株式会社インティメート・マージャー 松田和樹さん @mats116
- 資料(ブログ)
- 株式会社インティメートでの使用方法&構成&オートスケーリングとか運用の話
- 4億UU情報を保持しており、任意条件の検索に使用している。
- クラスター1つ。タイプ1つ。ノード数86台。
- master:3
- data:80
- searcher:2
- indexer:1
- indexer以外はAutoScalingで対応
- version 1.5.2。
- 100台まで台数に応じてパフォーマンス向上
- 200台規模ではAggregationのパフォーマンスが劣化
- awsインスタンスはc3.large
- shared/nodeが1超えると激しくパフォーマンスが劣化(shared/nodeではなく、shared/cpuの方が重要かも)
- データ量が多い場合は、xlarge以上の方がコスパが優れる。
- JVMのメモリ割当は2〜3割割当。
- AutoScalingさせている理由
- 100台規模のサーバーを1台1台管理して運用することが人的に困難だったから
- terminateすれば元に戻る
- recoveryのチューニング
- 帯域や同時移動可能なシャード数を調整し、リカバリのかかる時間を短縮している
- クラスタリングの高速化
- elasticsearch-cloud-awsプラグインの利用
- master nodeのオートスケーリングの設定にtagを利用
- ELBで監視
- Multi-AZ構成で構築
- ノード名をhostnameにする
- 監視ツール
- ELB
- Mackerel
- Papertrail
（仮）Spark in small or middle scale data processing with Elasticsearch 株式会社ビズリーチ 島本 多可子さん @chibochibo03
- slide
- ビズリーチ内でのSparkとESの使用事例。
- ユーザー辞書が使えるとかngramが使えるとか検索の細かいチューニングが肝になってESを採用した
- elasticsearch-scala-httpclient
- elastic4s
- クエリがJSONで辛い。
- スキーマを何度も作り直すのが辛い -> dynamicフィールド採用。
- Spark
- elasticsearch-hadoop
- JOINができる(複数のインデックスを結合出来る)。時間のかかるデータを前もって作っておいて補完出来る。
- 辞書更新が最大の懸念だった
- 辞書更新が頻繁に発生
- 再インデックスを考慮したアーキテクチャ
- rawデータの更新削除の必要性
- アーキテクチャを統一
- SparkStreaming
- スケールアウトが容易
- elasticsearch-sparkはbetaだけど、利用には問題ない
LT
Elasticsearchのサジェスト機能を使った話 株式会社アイスタイル 渡邊 紘太朗さん @ktaro_w
- slide
- Completion Suggester
- Analysisは、kuromojiとanalysis-icuを使用
- Gatling
- サジェスト用インデックスはまとめるのが良い
Elasticsearchで作る形態素解析サーバ 株式会社エヌツーエスエム 菅谷信介さん
- slide
- Analyze API
- Extend Analyze API・・・遅い
- elasticsearch-analyze-api