記事検索とログ解析でのElasticsearch活用事例
続いては、日本経済新聞社デジタル編成局の梅崎裕利さんによる
「記事検索とログ解析でのElasticsearch活用事例」です。
新聞記事の全文検索とか、なかなか胸が熱くなるタイプのヤツですね。
検索の需要がある中でSolrとElasticsearchの検証を進める中、
気がついたらElasticsearchがメインの仕事になっていたとのこと。
これ、Elasticsearchあるあるですかね。
コンテンツ検索とログ可視化の両方で使えるから、という理由でElasticsearchを採用したそうです。
コンテンツ検索は、200万のデータ（5GB）で、1日数千の更新頻度、リクエストは秒間100回ぐらい。
検索APIは、Django API + Elasticsearchで、マスターはMySQLに別途保存。
本番稼働を始めてから半年以上運用しているようです。
Kuromoji、ICU normalizerの利用、ngramと形態素解析の両方でインデックス作成、
また完全一致用にnot_analyzed（文節や単語で分かち書きしないやつです）も残しています。
（なるほど、検索のために全力だ）
また、新聞記事をスマホで撮ると、関連記事を検索する「もっと日経」というサービスが提供されていまして、
こちらは写真の画像をOCRして、Elasticsearchを用いて検索しています。
OCRの課題はあるそうですが、これは面白いサービスですね。
一方、アクセスログ解析の方は、いわゆるELK/EFK構成（Elasticsearch + Logstash/Fluentd + Kibana）
アクセスログは、1日約3億件（120GB）で、1週間分を保持。
r3.xlargeを6台で運用し、物理メモリ180GB（うちヒープは72GB）という構成。
それで月額20万円程度、もしスポットインスタンスが使えれば月約3万円ぐらいになること。
24時間分のログ集計に、10秒〜1分ぐらいかかるそうです。
検索回数が多くないので、この程度の台数で済んでいるとのこと。
（かなりサイジングの参考になる事例ですやん！）
アクセスログから、HTTPエラーやファイルごとの帯域の可視化、
どの地域からのアクセスが多いかなどを分析しているとのこと。
何よりも、これまでエンジニアが秘伝のソースで解析していたログを
Kibanaで可視化することで、URLや画像で共有できるようになったことが大きな改善ポイント。
また解析に掛かる時間も、当初10分〜1日以上というバッチだったところから
長くとも1分ぐらいになっている点で、フィードバックも早くなりました。
「Kibanaは楽しいから、気づいたら時間がすごい経ってる」というのは、私も共感するところです！
ということで、ここで休憩に入りました。
きゃー、LTの準備が進んでないー！！
