CET – Capture EveryThing 全サービス横断リアルタイムデータ収集・分析基盤

吉田　啓二　ネットビジネス本部ディベロプメントデザインユニットアーキテクト 2グループ

1

2

• 2014 年 7 月に株式会社リクルートコミュニケーションズへ中途入社

• 株式会社リクルートライフスタイルへ出向中• 約 8 年間 Web アプリケーションの開発に従事• 2015 年 6 月より、リクルートライフスタイル全

サービス横断のリアルタイムデータ収集・分析基盤の構築プロジェクト（ CET プロジェクト）へ参画

自己紹介

3

• リクルートライフスタイルの全サービス横断で、リアルタイムにデータ（システムログ、ユーザの行動、在庫変動など）を収集・分析するための基盤

• リアルタイムデータ分析に必要な処理（収集、加工、集計、分析、可視化）を一気通貫で実施

• ビジネス系メンバ、データサイエンティスト、エンジニアでプロジェクトを推進

CET の概要・特徴

4

• サービス・ビジネスに関するあらゆる情報の変化（ユーザの行動、在庫量の変動など）を、我々サービス提供者がリアルタイムに把握できていない

• その結果、状況に応じて最適な施策を講じることができておらず、機会損失が発生している

CET が解決する課題

5

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

6

CET のシステム構成

CET – Capture EveryThingサービス サービス運用者

ELB

Elasticsearch,Kibana

BigQuery

S3

APIELB Cloud Bigtable＊ GCP 関連製品は技術検証中

Cloud Pub/Sub

Cloud Dataproc,Apache Spark

7

• コールセンタでリアルタイムにログをモニタリング

• アプリケーションのスローダウンやユーザ操作の戸惑いなど、ユーザビリティに関する情報を迅速に検知し、顧客サポート品質向上に努める

リアルタイムデータ可視化事例 – Air レジ

8

• Spark Streaming を使用してウインドウ集計を実施

• 定期的に直近のユーザ行動ログを集計し、宿ページごとの UU 数をリアルタイムに算出

ストリームデータ処理事例 1 – じゃらん

• Spark Streaming を使用してログを定期的に集計• 処理時間が特定のしきい値を超えるログの件数を

URL ごとに集計し、結果をサービス運用者へ通知

ストリームデータ処理事例 2 – サービス共通

CET – Capture EveryThingサービス サービス運用者

ELB Cloud Pub/Sub

Cloud DataprocApache Spark

9

Amazon SNS

AWS Lambda

メール

Slack

10

• 1 回の Publish で送信できるメッセージ数の上限が1,000 件まで– 公式ドキュメントに記載あり– サポートに問い合わせたが、この上限を緩和するの

は難しいらしい– Fluentd から Cloud Pub/Sub へデータを送信する際、

1,000 件ずつ分割して送信するようにした

Cloud Pub/Sub について 1/3

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

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

13

• コスト観点で Amazon DynamoDB と比較し、 Cloud Bigtable を使用することを決定

• TTL （ Time To Live ）機能に頼ることができない– 公式ドキュメントに TTL 機能の記載あり– 実際に使用してみたが、指定した TTL の時間を過ぎ

てもデータが消えない– サポート問い合わせの結果、 Bigtable の TTL は最低

データ残存期間を規定するものであり、いつデータが消去されるかは不定であることが判明（ Bigtableの GC のタイミングで消去されるとのこと）

– Bigtable からデータを取得する API側で、 TTL を考慮した実装とした

Cloud Bigtable について

14

• 在庫変動データに基づいた、在庫売り切れ予測• リアルタイム異常検知

今後対応を検討していること

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

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