Hadoop＋Embulk＋Kibanaのデータ集計基盤によるデータ可視化と集計データを活用したキーワードサジェストの仕組み：Elasticsearch＋Hadoopベースの大規模検索基盤大解剖（3）（1/3 ページ）

リクルートの事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する連載。今回は、ログデータの分析および可視化の基盤を構成する5つの主なOSSや集計データを活用したキーワードサジェストの事例を紹介します。

[高林貴仁，リクルートテクノロジーズ]

検索基盤を根本から支えるデータ集計基盤の裏側

今回の主な内容

• 検索基盤を根本から支えるデータ集計基盤の裏側
• ログデータの分析および可視化の基盤を構成する5つの主なOSS
  • Hadoop／Hadoop Streaming
  • Kibana
  • Embulk
  • Nginx
  • fluentd
• Kibanaでどのようなデータを可視化しているのか？
  • キーワードランキング
  • ページビュー／ユニークユーザー
  • カスタマー分析
  • A/Bテスト
• キーワードサジェストのシステムとIndexの構成
• Hadoopで集計してサジェストのランキングを生成する基になるパラメーター
• 今後の展望――Apache Spark、Apache Drillの活用に向けて
• 次回は、DevOpsの取り組みについて

連載目次

　リクルートの全社検索基盤「Qass」の事例を基に、大規模BtoCサービスに求められる検索基盤はどう構築されるものなのか、どんな技術が採用されているのか、運用はどうなっているのかなどについて解説する本連載。

　初回の「リクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか」では全体的なアーキテクチャ、採用技術、開発体制について紹介しました。

　検索システムを構築する際に、最も重要なのは、前回の「ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上」でも紹介した、検索品質の向上です。Qassでは、いろいろなログを組み合わせて分析したり、ランキングデータに活用したりと、ログデータはシステムの中核となっています。

　第3回の今回はQassの検索基盤を支えるデータ集計基盤と、それによるデータ可視化、集計したデータを生かす事例などを紹介します。また現在、これまでQassで利用していた可視化基盤の中核を新しいミドルウエアに切り替えようと考えているので、最後に紹介します。

ログデータの分析および可視化の基盤を構成する5つの主なOSS

　Qassでは、現在以下のOSS（オープンソースソフトウエア）を活用して、ログデータの分析および可視化を行っています。図1は概要図です。

図1　全体の構成

　カスタマーが検索したキーワード、滞在時間、「どんな検索結果が表示されたか」「検索順位の何番目を選択したか」などのデータをログから回収します。回収したデータは、データ集計基盤で集計し、Kibanaを利用して可視化されます。集計されたデータは可視化するだけではなく、検索機能をサポートするサジェスト（後述）、誤字などを補正するスペラー、入力したワードに関連度が高いキーワードを表示させる関連検索や、辞書生成に活用されます。

Hadoop／Hadoop Streaming

　現在のQassのHadoop環境は、MapReduce 1系のシステムで運用されています。主にHadoop Streamingを利用している理由には、MapReduce 2系への移行スケジュールが決まっていたため、ゼロからHadoop 1系で開発するメリットがあまりなかったこと、

また、Apache Hiveなどを利用すると、細かい処理が柔軟にできないことがあります。言語は、主にPythonやRuby、PHPを利用しています。

Kibana

　Kibanaは、バックエンドにElasticsearchを利用した可視化ソフトウエアです。Qassでは定期的（1時間〜1日）に集めたデータを格納し、データを可視化しています。

Embulk

　Kibana／Elasticsearchに格納するデータの入力元は、アクセスログやtsv、csv、jsonといった、さまざまなデータソースです。それらのデータソースに対応して、データを加工し、Amazon S3に出力して、その後Kibana／Elasticsearchに出力する。これらの一連のパイプラインにEmbulkを利用しています。

　Embulkは、まだ登場して間もないOSSですが、Qassでは、サービスへの影響が少ないため、検証目的および、「ナレッジを蓄えておく」という観点から導入しています。インフラ構築・運用をメインで行う部隊でも、比較的使うことが容易なことも導入の一因です。

Nginx

　Nginxは、カスタマーログを格納するために利用しています。Webアプリケーションサーバーとしての機能はありませんが、カスタマーのアクションごとにアクセスがあるので、それなりのトラフィックがあります。

fluentd

　Nginxで出力したカスタマーログを定期的に回収します。回収したログは、HDFS（Hadoop Distributed File System）上に格納され、分析データの一つとして活用しています。

Kibanaでどのようなデータを可視化しているのか？

　データを視覚的にモニタリングすることは、非常に重要です。可視化することで、サイトの属性や「どのようなキーワードが入力されているのか」がひと目で分かるようになります。導入しているサイトによって違いますが、主に以下のデータを可視化して分析を行っています。

キーワードランキング

　「どのようなキーワードが入力されているか」「日々入力されているキーワードに変わったものがないか」を確認しています。「新しいキーワード、急上昇したキーワードに対して、検索品質に問題がなかったか」「ゼロマッチしたキーワードに対して、なぜ検索結果が表示されなかったのか」「ドキュメント自体が存在しないのか」などを調査したり、調査結果を辞書に反映したりすることで、検索品質を改善していきます。

ページビュー／ユニークユーザー

　ページビューやユニークユーザーは、「サイトにどれだけの訪問があったのか」の目安になります。例えば、「キャンペーンなどの施策を行ったことで何回ぐらいのアクションが生まれたのか」が分かります。また、サイトの訪問ピーク時期が可視化されることで「いつサイトへのアクション誘導施策を行えばいいのか」が分かりやすくなります。

カスタマー分析

　「カスタマーがサジェストの何番目を選択したのか」「検索結果の何番目がよく押されているのか」など確認します。

図2　Kibanaによるキーワードサジェストの利用率と「どのポジションが選択されているか」の可視化

A/Bテスト

　A/Bテストの指標を可視化することは、非常に重要です。

　例えば、検索のランキングパラメーターを変更することで、「既存の検索結果と比較して、どのくらい効果が出たのか」「QPS（1秒に処理できるリクエスト数）などに影響はないか」など、いろいろな視点から分析を行います。有意差が出たところで、本番の環境にリリースします。

　検索ランキングのチューニングは、トライ＆エラーです。微妙なパラメーターの変更でアクション数に大きな影響が出るので、A/Bテストを行うことで、既存のランキングと新しいランキングで有意差があることを証明することが重要です。