“5つのC”で考えるデータ分析基盤の構築　リクルートライフスタイルを支える、仕組みと運用

開発で失敗したポイント、成功したポイントは何か？

山田雄氏（以下、山田）：それではよろしくお願いします。「リクルートライフスタイルが考える、万人に使ってもらえる分析基盤の作り方」というタイトルで発表をさせてもらいます。

今回は、うちの会社でいろいろ失敗してきた中で、こういうふうにやったらよかったみたいなことを共有していければと思います。

この#tdtechというハッシュタグで、ぜひぜひ感想とか質問とかを書き込みしていただけるとうれしいです。

まず最初に自己紹介させてください。山田雄と申します。

リクルートライフスタイルのデータプラットフォームチーム、共通の分析基盤を作っているチームで働いています。「@nii_yan」という名前でTwitterをやっているので、よかったらフォローしてください。

もともと、Hadoopで、メールマーケティング用の基盤の作成をやってました。データ分析とかもやっていて、現在はリクルートライフスタイルで共通分析基盤の開発や運用を担当させてもらっています。

ビッグデータ周りの技術がすごく好きで、言語ではRubyが好きです。今月はRubyKaigiも参加する予定です。お祭りとかも好きで、ビールとかカップ焼きそばが好きです。これ、お祭りで子どもを担いでいる写真。下の子です。かわいいですね。

こっちの写真は僕がよく食べるカップ焼きそばです。カップ焼きそばっていろんな種類があって、社員の人たちが僕の机にいろいろ置いていってくれるので、僕はひたすら食べる役をやっています。

分析基盤はユーザーとの間柄で決まる

会社の紹介をしますと、リクルートライフスタイルという、ホットペッパーグルメ、ホットペッパービューティー、じゃらんなど、31のサービスを展開している会社です。

従業員は今3,300人ぐらいですが、エンジニアは100人ぐらいです。なんとか内製でがんばってやっているんですが、まだまだエンジニアは少ないという会社です。

この中で、実際にデータ分析基盤の構築とか運用とかに携わっている方はどれぐらいいらっしゃいますか？

（会場挙手）

やはりけっこう多いですね。データ分析基盤をやってるって人、まわりではなかなか聞かないんです。日本中の人がここに集まっているのかなという感じですね。

データ分析基盤を作っているとよくあるのが、例えば「このサービスのデータも入れて」と言われたけど運用者がいなくて「今リソース不足だからちょっと待って」となったり、「リアルタイムデータも分析したい」と言われたときに「まだぜんぜん検証できてなかったから2ヶ月ぐらい待って」とかなったり。

あとは「どんなデータが入っているか見てみよう」みたいな感じで、巨大なテーブルに対して、一応limitとかつけてくれてるんですけど、エンジンによってはフルスキャンが走ってしまうのでちきしょうと思ったりしますよね。「パーティションあるんだから指定してよ」と思う。

分析者がクエリに慣れてくると「cross joinなんて便利なものがあるじゃないか、これでデータ取っちゃうぞ！」なんて言って、たまに数億件同士のテーブルをcross joinする人がいるんです。何十億とか何百億のデータができて、中間データでディスク食いつぶされて、ほかの処理が落ちて「ちきしょう、こいつのアカウント消していいですか？」なんて言ってくる。

分析基盤の価値とはなにか？

でも世の中ではやっぱり機械学習とか、データサイエンティストの人がもてはやされるんですね。「結果出して表彰された！　やった！」なんて言うけど、分析基盤のほうはぜんぜん評価されない。

分析者と基盤の運用者って、けっこう衝突しがちだと思います。でも、データ分析基盤の価値とはなにかをよくよく考えると、やっぱり使ってもらってなんぼなんです。とにかくユーザーに使ってもらいたい。

たくさん分析してもらって、事業成果を上げてもらうことが分析基盤の価値だと思います。なので、なるべく衝突を避けたほうがいいとは思っています。

（スライドを指して）データを使ったビジネスの3大要素として、最近いろんなところで言われているのが、ビジネスとデータサイエンスとデータエンジニアリング、この3つが同じ大きさであるべきだということです。

データ分析基盤とかを作ってるところは、この図のデータエンジニアのところですね。なので、データサイエンスが頭でっかちになったりしがちですが、同じ丸の大きさであるべきだと思います。

「きちんとみんなが継続して使ってくれる基盤を作るにはどうしたらいいだろう？」っていろいろ失敗もしつつ考えて、今はこんなふうにするといいんじゃないかなと思っています。

「カスタマーセントリック」というマーケティング手法があります。分析基盤は、社内でいかに使ってもらうかがメインになってくるものなので、これはマーケティングだと思うんです。なので、マーケティング手法を取り入れる。

（スライドを指して）こちらはユーザーの声を中心に置いて戦略や戦術を決定するという、5つのCモデルで分析基盤の構築を行う方法です。

Collect、Confirm、Create、Check、Continueの5つです。これがいいんじゃないかと思って、今、取り組んでいます。

人がシステムに合わせるのではなく、システムが人に合わせる

まず、弊社では実際どのようにやっているかを共有します。まず声を集めるところについて。「人がシステムに合わせるのではなくて、システムが人に合わせるのだ」という、どっかの偉そうな格言があるんですけど。

分析基盤についてはいろんな例が出てくるんですが、やっぱり正解はないと思うんです。会社によってユーザーのレベルはいろいろ違います。会社の規模も違うので、さまざまな分析基盤があっていいと思います。

すごく最先端な基盤を作ってもいいかもしれない。でも、結局ユーザーが使ってくれなかったら意味がないので、なるべくシステムが人に合わせるほうがいいんじゃないかと思います。

先ほども申したように、使ってくれる人がいないと分析基盤は継続できません。なので、とにかくユーザーの使いやすい基盤にしたほうがいいと思っています。ユーザーの声を常に聞ける環境は整えましょう。

攻めの基盤を作っていかなきゃいけないときもあるとは思うんですけど、まずは社内のユーザーの信頼残高を築いてからするべきだと思います。突然作っても、使ってくれないことがある。

弊社で実際に取り組んでいることを一部紹介させてもらいます。DeNAさんの発表でもあったんですが、問い合わせ用にSlackのチャンネルを開設したりしています。

あとは定期的にユーザーアンケートを行っています。メールを送るだけだとなかなか答えてくれないので、基盤を実際に使ってる人のランキングを出して、トップ層に対面でのアンケートを行っています。

ユーザーと共に働くことで同じ目線を獲得

あと、弊社のチームのメンバーには「なるべく基盤を使う立場になれ」と言っています。マーケット部隊に兼務で入るなどして、外から基盤を見る目線を持つようにしてもらっています。ほかにも、データを使うチームと同じグループになるなどしています。

ここらへんは自分の趣味も入ってきますが、毎月メルマガを社内宛てに発行しています。あとは社内散歩をして顔を広めたり、いろんなところで話を聞くと「これどうなの？」みたいなちょっとした話を聞けたりします。こんなことを行って、とにかくユーザーと仲良くしてやっています。

どのテーブルがどのユーザーに使われているか、どのクエリの負荷が高いか、ユーザーがどれぐらいクエリを投げているか、平均レスポンスタイムなどをなるべく集めておくのも重要だと思います。これはアンケートで取るような項目ですが、機械的に取れる声もいくつかあると思います。

また社内SNSなどがある場合は、そちらでユーザーの声を集めてもいいかもしれないです。Slackを使っている場合はパブリックチャンネルの発言も全部集められます。そういったものでワードクラウドを作ったりするのもいいかもしれません。

「なぜこのユーザーは声をあげたか」を常に考える

次に、内容の精査です。「ユーザーの表面的な言動だけを捉えず、その背後にあるユーザー自身も気づいていない本音を探りあてる」と言うとすごく偉そうですが。

ユーザーって、1回ダメだっただけでも「これを改善してほしい」と言うことがけっこうあると思うんです。なので、ユーザーの声をがんばって集めても、全部聞いてるとさすがに対応しきれなくなってきます。その裏側になにかしらの課題がきっとあるはずなので、それをがんばって探り当てましょうということです。

弊社では、課題を、どう対応するかという点でレベル分けしています。方針としては、すぐ対応できるものと対応に時間がかかるものを織り交ぜて対応するようにしています。

対応に時間がかかるものをずっとやっているとぜんぜん対応してないように見えちゃうので、ユーザー受けがいいように、すぐ対応できるものは対応して「ちゃんと対応してるんだよ」という姿勢を見せてあげるのが重要だと思います。

あとは、根本的な原因を解決したほうがいいと思うので、なぜユーザーさんがその声をあげたのかを常に考えるようにはしています。表面的な対応をずっと繰り返しても根本的な解決にならない場合があるので「本当に根本的な対応はなんだっけ？」ということを常に考えています。

実際、価値を創造って、ここ本当にいろいろ開発したり作ったりする部分なんですけど、やっぱりmake money、売上を上げることは重要だと思います。売上を上げないと予算はつかない。会社からお金をもらえないと分析基盤は作れません。

分析基盤はとにかくお金がかかります。予算はほぼほぼ毎年純増します。データ量は毎年増えていきますし、量に比例してお金もかかります。売上が上がれば予算がついて、よりよい基盤を作れます。

ここは賛否両論あると思いますが、僕は、分析基盤のROIは計算しなくていいと思っています。インフラって「道ができたら便利だよね」みたいなものだと思うので。

ただ「この分析基盤の上で20億とか30億稼ぐバッチが走ってるんだよ」というようなことはきちんと提示したほうがいいです。そのバッチの中で分析基盤が寄与しているのは何パーセントという数字を出すのはすごく難しくなるので、とにかく「分析基盤があるおかげで売上が上がるバッチが動いている」と伝えられたほうがいいとは思います。

継続可能で運用しやすい基盤の秘訣とは？

運用コストは、やっぱりなるべく下げたほうがいいです。運用をやりたい人ってあんまりいないと思うんです。運用にネガティブイメージを持っている人も多かったりするので、運用コストを下げるための開発はできるだけやりましょう。

あとは、キャパシティ管理ですね。ビッグデータって、データ量がどれだけ増えるかが予測不可能です。とくにうちみたいな会社ですと、ある日突然サービスが増えたりする。そのサービスがIoTだったりすると、今までの何十倍、何百倍みたいなデータが突然来たりするので、まったく予測不可能です。

そんなとき、ノードを追加とかだとけっこう厳しいこともあるので、なるべくキャパシティ管理をしないですむ基盤にしたほうがいいです。

あとは再実行が簡単にできる冪等性を持ったデータパイプラインですね。エラーや障害は必ず起きます。そのときに単純再実行できるだけで、運用がすごく楽になります。なので、冪等性を持ったデータパイプラインを作るようにしたほうがいいと思います。

あと、クラウドはとても便利なので、任せるところは任せたほうがいいです。例えば、EC2を立てるだけで運用は増えます。先日の例でいえば、IntelのCPUの脆弱性のようなことがあったとき対応しなきゃいけなくなります。

なので、サーバもなるべく立てないほうがいいと思います。低レイヤーの運用はなるべくクラウドに任せて、サーバレスとかフルマネージドの製品を使うのがいいです。

ユーザー教育でお互いの距離を縮める

あとは魔改造。僕もけっこう好きでもともとやってたんですが、例えばHadoopとかOSSを使っているときに、Hiveのソースをゴリゴリいじって自分の会社用にカスタマイズしたりすると、そのときはいいけど、バージョンアップのとき大変になっちゃうんです。最終的に自分の首を絞めることになるので、しないで済むならしないほうがいいと思います。

あと、敷居はとにかく下げたほうがいいと思います。ユーザーが分析したいときにすでにデータがある状態にしておくとか、ユーザーの使いやすいインターフェースを用意してあげるようにすると、ユーザーがどんどん使ってくれます。

ユーザー教育も重要だと思います。やはりユーザーとは仲良くしないといけない。もちろん、アホクエリを投げるようなユーザーもいますが、きちんとユーザー教育をしていけばだんだん減っていきます。弊社では、動画コンテンツを用意して「分析基盤を使う人はまずこれを見て学習してね」というふうにやっています。

使いやすいインターフェースの例としては、うちではけっこうbotが使われています。（スライドを指して）例えばこれはbotの一例ですが、S3にあるデータをSlackでつぶやくと勝手にRedshiftにロードしてくれるというものを用意しています。

こういうものによって、実際にユーザーがなんらかのCLIからとかコマンド叩くとかはなくても、いつも使っているSlackでちょっとつぶやくだけで勝手にデータが用意される、という環境を用意してあげています。

メタデータは一元的に管理すべき

あとはどこにどんなデータがあるかというメタデータの扱いについてですね。メタデータは一元的に管理して、ユーザーがすぐ分析できる環境を整えてあげるのがいいと思います。

（スライドを指して）これはWeb UIで出しているもので「META LOOKING」といって、メタを見る=Meta Lookingでメタが集まって「MEATAL OO KING（メタルキング）」ってすごい良い名前だなと思うんですけど。

ここで、どのデータベースにどんなテーブルがあるか、カラム定義はなんだったか、なんちゃらコードの1っていうやつはどういう意味かとかを一元的に見られるようになっています。これを使えばどこにどんなデータがあるかすぐにわかるので、新しく入ってきた人もすぐ分析が始められる環境になっています。

効果の検証も、ずっと続けたほうがいいと思います。こちらはKPI設計です。分析基盤のKPIをどのように設計するかというところはまだすごく悩んでいるので、後の懇親会でKPI設定をしておられる方がいたらぜひ教えていただきたいです。

うちで見ている値はここらへんですね。

ユーザーのアカウント数、クエリの数、平均レスポンスタイム、テーブル数、障害数、botも用意してるならbotの使用回数、ユーザーがどれぐらい使ってくれているかをKPIとして見ています。

これらの数字を、毎週、チーム全員で確認しています。ユーザーのアカウント数とかはどんどん増えていくので、それだけを見ても意味がなくてKPIとして適切じゃないので、ユーザーのアカウント数を運用している人の頭数で割ったりしています。

DataLake構成は将来を見たとき有用

これらのサイクルを継続するためには、進化ができる基盤にしておく必要があります。

進化できる基盤とはどういう構成かというと、よく言われていますが、DataLake構成がいいと思います。いろんなデータウェアハウスにデータを分散させるのではなく、常にある1箇所に集めるというかたちです。弊社ではS3を使っています。

DataLake構成にしておくとなにがいいかというと、世の中、新しいデータウェアハウスはどんどん出てきます。例えば最近だとBigQueryを使っている会社は多いですが、今後BigQueryよりいいデータウェアハウスが出てくるかもしれません。AmazonのRedshiftも使っていますけれども、それよりもっといいものが出てくるかもしれません。

いいものが出てきたときに、すぐそっちに対応できる基盤でないといけないと思うんです。そのためにはDataLake構成にしておくのが一番いいと思っています。

ここで重要になってくるのが、やはり、サイズ制限から開放されていることです。データは資産なので、いろんなデータをどんどん貯めておきたい、貯め続けたい。そのためには、なるべくキャパシティ制限のないオブジェクトストレージがいいと思います。

あと、最初は僕も勘違いしてたんですが、DataLakeではデータを1箇所に集めますけど、データを1個しか持っちゃいけないわけではないんです。3段構成でデータを持つと使いやすいです。

やみくもにデータを入れればいいわけではない

まずはRawデータですね。非構造データを、ログでもなんでもいいんですけど、いったん集めます。それをNormalizedして、TSVとかParquetとかいろんなエンジンが使いやすい、構造化されたデータに変えて持ちます。

その後、ここに置いてあるデータを直接加工してもいいですし、1回データウェアハウスに入れて加工して戻してもいいんですが、マート化されたデータにして持ちます。この3段構成で持っておくと、のちのちどんなエンジンでも使えるようになります。

DataLakeで重要なことは、常に透明性を持ち続けることです。なにも考えずに「データどんどん突っ込めるから突っ込め」って突っ込んでいくと、どこになんのデータがあるかわからなくなって、透明性がなくなってどんどん沼になっていきます。常に透明性を持った基盤にしておくことが必要です。

スクラムにも、透明性という言葉があります。そちらではどう定義されているかというと「正しい情報が1箇所に整理してあり、次の行動が誘発されること」となっている。

データでいうと「データを情報に変えて、より多くのユーザーに動機と機会を提供する」ということでしょうか。これは弊社の全体的なキックオフでも言われることなんですが、常にどんなデータがあるかをわかるようにして、ユーザーが勝手にどんどん動いてくれるような基盤にすることが重要です。

こんな感じでぐるぐる回して、一度で終わらないように、サイクルを回していければいいと思います。

データウェアハウスを使い分ける

次に、弊社の分析基盤の構成を紹介します。（スライドを指して）これで全部ではないんですが、リクルートライフスタイルが持つデータはこんな感じでたくさんあります。

じゃらんとかホットペッパービューティーとか、最近だとAirレジとかAirメイトとかいう店舗に対するコンサルができるサービスも出ましたが、ほぼすべてのサービスのデータを一元的に管理して、横断で分析できる環境を提供しています。

分析基盤の概要としては、データウェアハウスとしてはOracle Exadata、Amazon Redshift、BigQuery、Treasure Dataを使わせてもらっています。DataLakeとしてはS3を使っています。

分析ツールとしては、ユーザーはAginityなどのツールを使ってアドホックなクエリを投げたりしていて、BIでは主にTableauを使っています。それ以外にも外への連携として、Salesforceとか、あとはExperian、今はチーターデジタルという名前に変わっていますが、そちらにデータを渡したりしています。SPSSなどのModelerツールも使っています。

データ利活用の3大要素と言われているものがあります。どんなデータも必ず入力、処理、出力の3つの要素を通ります。

これを先ほどの分析基盤の概要図と組み合わせるとこんなかたちになります。

データウェアハウスがなんでこんなにいっぱいあるのか、疑問もあると思うので、それぞれどんな使い方をしているのか説明します。

ユーザーの声に合わせてスタイルを作っている

まずExadataについて、弊社のホットペッパーグルメやホットペッパービューティーなどの事業データはほぼオンプレのOracleを使っています。なので、例えばExadataを使うと、DBリンクを貼ってOracleから直接データを取ることができます。

また、OracleのレプリケーションサーバをExadata上に持つこともできます。弊社の場合ですと、Exadataはデータを集めるのにも便利なので、活用しています。また、Exadataの中は売上がすごくあがるような本番バッチを動かす環境になっています。

Redshiftについても、Exadataと同じように事業データも入れています。

それ以外にS3やNFSなどで連携されてきたファイル、TSVファイルなどもあります。あとはWebの行動ログもいったんS3に全部集約して、そのあとバッチ処理でRedshiftにデータをロードしています。

Redshiftのクラスタは2つあって、なぜかというと、片方のRedshiftが、弊社では毎日4,000テーブルぐらいデータをロードして、しかもそのあとにマート作成も行っているんですね。ものすごい高負荷になってしまっています。

その中でさらにアドホックのクエリを投げると、すごく単純なクエリでも30秒ぐらい返ってこないことがあって「遅くてとても分析できない」という声がいくつもあがったんです。Redshiftにはレプリケーション機能みたいなものはないので、Redshiftのスナップショットから、週次で別のクラスタを起こして「データ鮮度は古いけど快適に分析ができる環境」を提供しています。

用途ごとにクラスタを立てる

基本的に、1週間遅れのデータでもとくに問題なく分析してくれていますが、どうしても新鮮なデータと突合したいユーザーは、元データはS3にあるので、Slackでつぶやくと勝手にS3のデータがこちらのRedshiftに入ってくるようになっています。

今、Redshiftがいろいろ進化して、新しい機能も出てきているので、構成を変えている最中です。Redshift Spectrumを活用しています。Redshift Spectrumというのは、S3オブジェクトを直接参照できるようなものです。

なので、複数のDBから入ってきたデータをいったんS3に集めています。いったんTSVで入れたデータを、ファイルサイズが大きかったらGlueで加工して、ファイルサイズが小さかったらLambdaで加工して、Parquetファイル形式に戻して、もう一度S3に置いています。Redshift SpectrumからParquet形式のファイルを直接読むということをしています。

Parquetファイルにするとカラムナー方式で読めるので、スキャン量が減るんです。Redshift Spectrumはスキャン量での課金なので、TSVだと全量課金されてしまいます。

なので、Parquetにして、用途ごとにRedshiftのクラスタを立てることによって、例えばある人がすごいアホなクエリを投げても、ほかのクラスタは影響なくできるようにしています。Tableau用のクラスタとアドホック分析用のクラスタと、みたいな分け方もできるようにしています。

新しいものを取り入れてもっともっと柔軟な対応を目指したい

続いて、BigQueryです。こちらも今はアドホックの分析をメインにやっています。

Redshiftのクラスタだと中でマート作成とかも行っているんですけど、マート作成されたデータはS3に戻されています。

戻されたデータをすべてイベントドリブンでクラウドストレージに入れて、BigQueryにもロードしているので、BigQueryにはほぼほぼRedshiftと同じようなデータが入っていて、アドホックの分析環境として提供されています。

BigQueryへのデータのロードは、マルチクラウドを使って実現しています。S3にデータが入ったタイミングでイベントドリブンでSQSにキューが入って、そのキューを見たクラスタがBigQueryにデータをロードするというかたちを取っています。

これは、バッチとかユーザーがS3にデータを置いてもBQに勝手にロードしてくれるような仕組みを作ることで、すごく分析しやすい環境になっています。

Treasure Dataについては、SDKを使ってアプリのログを収集しています。こちらで収集したあとにTreasure Data上でマート作成処理をして、そのあとRedshiftにデータを移すということもしています。

今後については、うちではSalesforceとかDataRobotとかMarketoとか、そういうところとのデータ連携をしているんですが、今までのデータ連携って、それぞれのAPIを叩くものを全部がんばって実装していたんですね。

ですが、Treasure Dataを使えばもっと柔軟にデータを取れる、ETLのハブとしてRedshiftやBigQueryにもデータを連携できるということなので、そういった使い方をしていけないかと思っています。

「まず作る、ダメだったら謝ればいい」

このデータ基盤の実際の利用状況としては、テーブル数がだいたい4,000テーブル。レコード件数は4,500億レコードぐらい、ユーザーアカウントも1,200から1,300ぐらいあります。クエリ数は、だいたい2万クエリぐらいが毎日流れています。かなり多くの人に使ってもらえてると思います。

弊社では、アナリストとかのデータサイエンティストの人ではない、営業の方などもけっこう実際にTableauのレポートを使って営業したりしてくれています。データがかなり日常的に使われるようになってきて、分析基盤の価値はどんどん高まっている状況です。

まとめです。カスタマーセントリックというマーケット手法を紹介させていただきました。要はきちんと情報と意味を持ったデータで、透明性のある基盤をずっと継続して提供していきましょうということです。このようにできればどんどんユーザーも増えて、社内でも多く使われるようになるんじゃないかと思います。

最後に「許可を求めるな。謝罪せよ。従え、心の声に」と言うとなんのこっちゃと思われるかもしれませんが、これは、弊社のエンジニアのキーワードです。「これやっていいですか？」って聞いてから作るんじゃなくて「まず作っちゃって、ダメだったら謝ればいいじゃない」ということです。

実際にいろいろ作らせてくれたりはするので、最初にエンジニアはスケールができないという話もありましたが、うちもぜんぜんスケールができていないので、興味ある方は「リクルートライフスタイル　エンジニア」で検索をしてみてください。

以上です。ありがとうございます。

（会場拍手）

ユーザーをサポートするコンテンツを作るときのコツ

司会者：山田様、ありがとうございます。お時間が少しあるので、質問を受けたいと思います。

質問者：ユーザーのサポートコンテンツとして動画などを作られているという話について、私たちも一部やっているんですが、基盤だとかUIの更新に応じてどんどん遅れていくので、そもそも作るのが大変なのに追従するのも大変で苦労してます。そのへんはどうやって乗り越えていますか？　あと、どういうところを抽出するかなど考えているポイントはありますか？　

山田：まず動画のコンテンツについては、何本か用意していて、会社の全体的な分析基盤の構成とか、BigQueryに特化した動画とか、DataRobotに特化した動画とかがあります。

さらにその動画の中でタームを分けることで、タームごとに差し替えられるようになっています。あと、資料へのリンクが貼ってあるんですけど、リンク先の資料を変えることで切り替えられるようにしています。

質問者：ありがとうございます。

司会者：ほかは大丈夫ですか？　山田様も懇親会に参加していただけるとのことなので、なにかありましたらそちらで捕まえてお話してみてください。では、山田さんありがとうございました。

山田：ありがとうございました。

（会場拍手）