Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

Elastic{ON} Tokyo 2015レポート 〜事例紹介 その2 日本経済新聞 #elasticon

記事検索とログ解析でのElasticsearch活用事例

続いては、日本経済新聞社デジタル編成局の梅崎裕利さんによる
「記事検索とログ解析でのElasticsearch活用事例」です。

f:id:acro-engineer:20151216142913j:plain

新聞記事の全文検索とか、なかなか胸が熱くなるタイプのヤツですね。

検索の需要がある中で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の準備が進んでないー!!