はじめに
本連載では、リアルタイムなストリームデータ活用を実現する基盤について紹介します。
連載の1回目は「マイクロモーメント」という言葉に代表されるユーザー行動の変化とそれを取り巻く課題、そしてそれらの課題を解決するために構築した独自のリアルタイムデータ基盤について解説します。
連載の2回目は構築したリアルタイムデータ基盤について、実際の導入事例や、今後の展望をお伝えします。
対象読者
- リアルタイムなストリームデータ活用を検討中の方
- 最新のクラウドサービスの選定について検討中の方
データ基盤構築の取り組みの背景
世の中の流れ――「マイクロモーメント」と呼ばれるユーザー行動の変化
総務省の「平成29年情報通信メディアの利用時間と情報行動に関する調査報告書」によると、国内のスマートフォン普及率は8割を超え、20代では96.8％と非常に高くなっています。また、総務省の別の調査では、インターネット接続機器で個人のスマートフォンの割合が54.2％と、PCの48.7％を上回ったという報告もあります。
この調査結果を見るまでもなく、ユーザー行動はPCからスマートフォンへ移行していることは皆さんも生活の中で実感されていることと思います。スマートフォンはPCに比べ、移動中の利用や他コンテンツを視聴しながらの利用が多く、１セッションのあたり平均滞在時間が短いため、よりリアルタイムにその瞬間のニーズに合わせた接客が必要となります。
リクルートのサービスにおいてもコンバージョン数（応募や予約）の半数以上がスマートフォンからであり、シェアは年々増加傾向にあります。
テクノロジーの進化によって、人々が「～したい」と思った瞬間に、手元にあるスマートフォンですぐに情報収集を行えるようになりました。Googleはこの新しい変化に対して「マイクロモーメント」という概念を提唱し、「マイクロモーメントこそが新しい購買プロセスである」と伝えています。
リクルートにおける課題
リクルートは多数のサービスを展開していますが、多くのサービスでは初回訪問のユーザーの割合が高くなっています。長きにわたりサイトを愛用いただいているロイヤルカスタマーの方は別として、こういった「一見さん」ユーザーの方々に対しては、初回訪問時に事前のデータがないため画一的な「おもてなし（接客）」しかできていなかった課題がありました。
さらに、これまでのデータ基盤はデイリーなどバッチ処理を経て作られることが多く、その場の行動ログを参照してリアルタイムな接客することが難しい状況でした。就職、旅行、グルメ、結婚、住宅、美容、中古車など多方面にわたってサービスを展開するリクルートのデータ優位性を十分に活用できていなかったのです。
また、昨今、Web上でリアルタイムに接客するニーズが高まってきていることもあり、さまざまなWeb接客ツールが開発されてはいます。しかし、リクルートのサービスでより容易にカスタマイズができるように、またコストの観点から、これらの課題を解決するためのソリューションを自前で開発する判断をしました。
テクノロジーの進化
Google Cloud Platform（以下、GCP）やAmazon Web Services（以下、AWS）に代表されるクラウドサービスの飛躍的な発展により、自前でサーバーを調達しなくても、比較的容易に高付加価値を生み出すデータプラットフォームを構築することができるようになってきました。
独自のデータ基盤「hacci」を開発
以上の背景から、私たちはGCP上に「hacci（ハッチ）」というリクルート全社共通で利用できるデータ基盤を開発・展開しました。
hacciとは一言で表すなら、「リクルートのWebサービスを使うユーザーのデータをリアルタイムに収集・分析・活用するためのプラットフォーム」です。
リアルタイムなデータを活用することで、ユーザーの「今の状態」を知り「今」に寄り添ったコミュニケーションを図ることができます。イメージは「Web上のコンシェルジュ」といったところでしょうか。
コンセプト
hacciはリクルートのデータを活用する全ての施策担当者、エンジニア、データサイエンティストに対して、以下3つの価値を提供します。
- リアルタイムなデータを高速でhacciの中に「蓄積」できる
- 蓄積したデータをhacci上で自由に「演算」できる
- 蓄積・演算したデータを、高速に、欲しい形で「分析」でき、施策に「活用」できる
使いやすい「データパイプライン」にするために
hacciはデータ基盤であると同時に、「データパイプライン」とも言えます。データのパイプラインとは、データをある場所から別の場所に流すシステムを指しています。hacciは、データパイプラインとして、「入口と出口がどうあれば利用者が使いやすいと感じるだろうか、長く使ってもらえるだろうか」という視点を突き詰めて設計・開発しています。
一般的にパイプラインと言えば、水やガスなどを流す管を指すことが多いと思います。水を流すパイプラインは水道ですが、例えばこんな水道だったら、利用者はたまったものではありません。
- 自分の家の蛇口を交換するために水道管を交換しなければならない
- 水道管の交換や上水下水施設の更新のために水道管がつながっている全家屋の蛇口を交換しなければならない
データのパイプラインとしてのhacciも同じ考えを持っています。つまり以下の考えです。
- データの入力がどこから・どのようなものであっても、利用者が期待する出力に届けなければならない
- hacciの中身（実装）が置き換わったとしても、データの入力と出力に影響を与えるべきではない
開発時にこだわったこと
また、システムを「作りっぱなし」にすることは回避すべきことです。特に、Web上のデータを扱うサービスにひも付いている基盤は、常にWebの成長（ユーザー数の増加・データ量の増加）に耐えられるシステムであることが求められます。データパイプライン中の流量・負荷として最初に予測した数値も、数年もすれば大きく変わる可能性があります（そのサービスが人気になればなるほどにうれしい悲鳴があがることでしょう）。そんな変化に耐えられる基盤というのは、いくつか要件があると、hacciでは以下の通り定義しました。
運用がしやすいこと
- 障害の検知が素早く行われる
- 障害の原因を見つけやすく、取り除きやすい構成になっている
- 人に依存しない運用ができている（基盤の中身を誰でも容易に説明できる状態である）
継続的な改善ができること
- 基盤を構成する部品を置き換えることが容易である
このように、DevOps・SRE（Site Reliability Engineering）といったコンセプトも意識して、システムを開発しました。次の章では、このようなコンセプトで開発されたhacciのアーキテクチャについて具体的に紹介します。
