リクルートライフスタイルの全サービス横断で、ログデータ（システム系ログやユーザ行動ログなど）をリアルタイムに収集・可視化・分析する基盤を構築するプロジェクトのご紹介 RCO Study Night #3 - Spark・Scala勉強会 ( https://atnd.org/events/72146 ) にて発表

1. CET – Capture EveryThing
全サービス横断リアルタイムデータ収集・分析基盤
吉田 啓二
ネットビジネス本部
ディベロプメントデザインユニット
アーキテクト2グループ
0

2. • 2014年7月に株式会社リクルートコミュニケーショ
ンズへ中途入社
• 株式会社リクルートライフスタイルへ出向中
• 約8年間Webアプリケーションの開発に従事
• 2015年6月より、リクルートライフスタイル全サー
ビス横断のリアルタイムデータ収集・分析基盤の構
築プロジェクト（CETプロジェクト）へ参画
自己紹介
1

3. • リクルートライフスタイルの全サービス横断で、リ
アルタイムにデータ（システムログ、ユーザの行動、
在庫変動など）を収集・分析するための基盤
• リアルタイムデータ分析に必要な処理（収集、加工、
集計、分析、可視化）を一気通貫で実施
• ビジネス系メンバ、データサイエンティスト、エン
ジニアでプロジェクトを推進
CETの概要・特徴
2

4. • サービス・ビジネスに関するあらゆる情報の変化
（ユーザの行動、在庫量の変動など）を、我々サー
ビス提供者がリアルタイムに把握できていない
• その結果、状況に応じて最適な施策を講じることが
できておらず、機会損失が発生している
CETが解決する課題
3

5. （参考）リクルートライフスタイルのサービス
4

6. CETのシステム構成
5
CET – Capture EveryThingサービス サービス
運用者
ELB
Elasticsearch,Kibana
BigQuery
S3
APIELB Cloud Bigtable
＊GCP関連製品は技術検証中
Cloud Pub/Sub
Cloud Dataproc,Apache Spark

7. • コールセンタでリアルタイムにログをモニタリング
• アプリケーションのスローダウンやユーザ操作の戸
惑いなど、ユーザビリティに関する情報を迅速に検
知し、顧客サポート品質向上に努める
リアルタイムデータ可視化事例 – Airレジ
6

8. • Spark Streamingを使用してウインドウ集計を実施
• 定期的に直近のユーザ行動ログを集計し、宿ページ
ごとのUU数をリアルタイムに算出
ストリームデータ処理事例1 – じゃらん
7

9. • Spark Streamingを使用してログを定期的に集計
• 処理時間が特定のしきい値を超えるログの件数を
URLごとに集計し、結果をサービス運用者へ通知
ストリームデータ処理事例2 – サービス共通
CET – Capture EveryThingサービス サービス
運用者
ELB Cloud Pub/Sub
Cloud Dataproc
Apache Spark
8
Amazon SNS
AWS Lambda
メール
Slack

10. • 1回のPublishで送信できるメッセージ数の上限が
1,000件まで
– 公式ドキュメントに記載あり
– サポートに問い合わせたが、この上限を緩和するのは
難しいらしい
– FluentdからCloud Pub/Subへデータを送信する際、
1,000件ずつ分割して送信するようにした
Cloud Pub/Subについて 1/3
9

11. • 1回のPullで受信できるメッセージ数の上限も、実は
1,000件までであった
– 公式ドキュメントには上限の記載はなく、Pullリクエ
スト時のオプション”maxMessages”で受信メッセー
ジ上限数を指定できる旨が記載されていた
– ”maxMessages”に1,000件を超える値を指定しても、
実際には最大1,000件のメッセージしか返却されな
かった
– サポート問い合わせの結果、Pullで受信できるメッ
セージ数の上限も1,000件までであることが発覚
– Apache SparkのReceiverでは、マルチスレッドで
Cloud Pub/SubからデータをPullできるようにした
Cloud Pub/Subについて 2/3
10

12. • Spark Streaming + Cloud Pus/Subの公式サンプ
ルが実用的なものではなかった
– 公式サンプル:
https://github.com/GoogleCloudPlatform/cloud-
bigtable-examples/tree/master/scala/spark-
pubsub
– Spark Streamingでデータを取得するためには、
Receiverクラスを実装する必要があるが、サンプル
ではこれが実装されておらず、1回のバッチ処理で1
回のデータ取得処理しか行われない（前述の制限で
1,000件しか取得できない）実装となっていた
– Receiverクラスを実装した
Cloud Pub/Subについて 3/3
11

13. • コスト観点でAmazon DynamoDBと比較し、
Cloud Bigtableを使用することを決定
• TTL（Time To Live）機能に頼ることができない
– 公式ドキュメントにTTL機能の記載あり
– 実際に使用してみたが、指定したTTLの時間を過ぎて
もデータが消えない
– サポート問い合わせの結果、BigtableのTTLは最低
データ残存期間を規定するものであり、いつデータが
消去されるかは不定であることが判明（Bigtableの
GCのタイミングで消去されるとのこと）
– Bigtableからデータを取得するAPI側で、TTLを考慮
した実装とした
Cloud Bigtableについて
12

14. • 在庫変動データに基づいた、在庫売り切れ予測
• リアルタイム異常検知
今後対応を検討していること
13

15. • SparkRをEC2上で動かして分散処理してみる |
Tech Blog | リクルートライフスタイル RECRUIT
LIFESTYLEhttp://engineer.recruit-
lifestyle.co.jp/techblog/2015-08-19-sparkr/
• 第4回 ［データ分析編］“制約なし”で大規模デー
タ分析基盤を構築：リクルートライフスタイルの技
術力を追え！｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/recruit-
lifestyle/0004
（補足）関連資料 1/2
14

16. • リクルートライフスタイル全サービス横断のリアル
タイムログ収集・可視化・分析基盤@JAWS-UG
Meguro #2
http://www.slideshare.net/RecruitLifestyle/ss-
53400381
• 「ビッグデータは“リアルタイム”でこそ価値があ
る」CETエンジニア 吉田啓二氏インタビュー |
Tech Blog | リクルートライフスタイル RECRUIT
LIFESTYLE http://engineer.recruit-
lifestyle.co.jp/techblog/2015-11-02-yoshida-
interview-1/
（補足）関連資料 2/2
15