つづいて、各企業の事例紹介に移ります。
Elastic{ON}は、この東京だけでなく、Elastic{ON} Tourとして世界中をツアーしているのですが、
いずれの地域でも、必ずたっぷり事例紹介が行われています。
リクルート流Elasticsearchの使い方
そんな事例紹介の第一弾は、
株式会社リクルートテクノロジーズの中原裕成さんによる
「リクルート流Elasticsearchの使い方」です。
検索基盤や通知基盤でElasticsearchを利用
全社検索基盤「QASS」や、全社プッシュ通知基盤「Pusna-RS」、
またそれらを含む様々なサービスの可視化などでElasticsearchを利用しています。
元々はApache Solrで、各サービスごとに検索エンジンのクラスタを組んでいたが、
当時の構成の都合上、検索性能 / 更新性能に限界がありました。
検索品質を向上させるため、全サービス共通の、検索サービスの共通基盤を作ることにして、
その時に盛り上がっていたElasticsearchを採用することにしました。
それで出来たのが全社共通検索基盤「QASS」です。
Spark / Hadoopを用いた分析基盤があるため、これでelasticsearchの検索結果を分析し、
専門チームがelasticsearchの検索結果の継続的品質向上を行っているとのことです。
（何それすごい！）
続いてPusna-RSですが、これはリアルタイムなプッシュ通知を送るシステムです。
データをDynamoDBに保存しているのですが、単純な投入や全件取得は高速なのですが
検索条件を指定した検索は苦手で、そこでelasticsearchを利用することにした。
同じデータを、DynamoDBとelasticsearchの両方に投入し、用途に応じて使い分けている。
（マジか！！）
そして、それぞれのサービスは可視化しており、QASSの検索結果の指標や
プッシュ通知の登録状況や配信状況を可視化しています。
運用ノウハウ
ありがたいことに運用ノウハウの共有もありました。
1. プラグイン機構の利用
2. スナップショットの利用
3. Re-indexの手法
elasticsearchにで提供されているプラグイン機構を用いて、検索を最適化する、
スナップショット機能を利用してS3やHDFS、ディスクなどにスナップショットを残す、
スナップショットのリストアはJenkinsを用いて行うなどしています。
またre-indexですが、考え方的にはブルーグリーンデプロイメントと同様で
クラスタごと再構築を行い、データを流し込んでから、クラスタの切り替えを行っているそうです。
あと、バージョンアップでそれなりに内部構造も変わるので
バージョンアップは計画的に、とのことでした
（分かる！！）
Searching and Alerting for application logs with Elasticsearch at Naver
2社目は、NaverのJaeik Leeさん、Seungjin Leeさんによる
「Searching and Alerting for application logs with Elasticsearch at Naver」です。
最初にLINEを使っている人、という質問がありましたが、ほぼほぼ全員が手を挙げる感じでした。
ちなみにこのブログの写真も、他のメンバーに撮ってもらってLINEで共有しています。
さて、そんなNaver社のElasticsearchの使い方ですが、
元々、エラーログの収集や解析をするシステムを利用していたところ
収集や検索性能に限界を感じて、elasticsearchで再構築をしたとのことです。
スケールとしては、8クラスタ、229ノード、毎日2TBのログが集まっており
現在までに160TBのログが集まっているとのこと。
（半端ないんですけど、何すかそれ？）
Kafka + Kafka Riverを使ってElasticsearchにデータを流し込んでいたところ
パフォーマンス問題や、不安定さ、デバッグの難しさがあったため
Kafka + Stormの構成に変更し、改善させたそうです。
クラスタはマスターノード群、データノード群、クライアントノード群（or ロードバランサ）に分けるほか
直近1週間のデータはSSD、それより古いものはHDDに入れて、保存しているとのことです。
通知の仕組みとして、パーコレーターAPIを用いてこれに合致したものを
Kafkaに送り、そこで判定を行って通知を投げているそうです。
（パーコレーターAPIの一番正しい使い方ですよねこれ）
そしてKafka側で、設定された閾値と時間（たとえば5分間に10回、とか）に従って
ログイベントの通知判定を行って、通知しているとのこと。
通知ルールを変えた際には、Kafkaに通知して、キャッシュをクリアすることにしているとのこと。
2社とも相当なスケールの事例紹介で、少ないノードでなんとか回してる私としては圧倒される感もありますが
リカバリの方法や、通知の方法など、ぜひ取り入れたい学びもありました。
さぁ、続いてのセッションも楽しみですよ！
