リクルートライフスタイルの考えるストリームデータの活かし方(Hadoop Spark Conference2016)

リクルートライフスタイルの考えるストリームデータの活かし方～ AWS + Kafka + Spark Streaming ～

車田　篤史　ネットビジネス本部アーキテクト 1グループデータ基盤チーム

堤　崇行　ITサービス・ペイメント事業本部放送・情報サービス事業部情報ビジネス統括部

1. リクルートスタイルにおけるビッグデータとは

2. ビッグデータの過去・現在・未来3. Water プロジェクトとは4. ポンパレモールでの利用例5. 技術詳細＆ストリーム処理 Tips6. まとめ

アジェンダ2

• 車田　篤史 ( くるまだあつし )• 1999 年信号機メーカーで回路設計とか組込み Linux やってまし

た• 2011 年広告配信系のインフラ (Hadoop とか DWH) をやってま

した• 2015 年リクルートライフスタイル入社• データ基盤チームでビッグデータと日々向かい合っています

• 趣味：カメラ、時計・万年筆・英国靴・オーディオ機器

https://www.facebook.com/atsushi.kurumada

自己紹介3






会社紹介4

堤　崇行 ( つつみたかゆき )• 所属

– 株式会社ＮＴＴデータ

• 経歴– 2011 年 Web アプリ開発者– 2012 年データ活用（分析基盤、サーバーサイド開発）

• 最近使っている技術– Apache Spark, Ansible, Scala, Python, Haskell( 趣味 )

自己紹介5

リクルートライフスタイル様のビジネスパートナーとしてデータの価値創出や戦略を共に考えデータ活用の世界観を共に描いていけるようサポートしています。

会社紹介6

リクルートライフスタイルのミッション7

データ基盤チームの役割

Engineeringfor data

Businesswith data

エンジニアがビジネスを推進す

る

安定したインフラ基盤継続的な開発+

8

• 容量 (Volume)– データ量の制限なく保存できる

• 集約 (Variety)– 多様なデータが 1 箇所に集まっている

• 鮮度 (Velocity)– 保存データをすぐに利用できる

• 活用– データを活用できなかったら意味が無い

ビッグデータにおける普遍的テーマ9

• 容量

– 日々増加し続けるデータ量( 数十 TB 規模に増加、行動ログは 1,000 億レコード規模 )

• 集約– RDB/ ファイル等にデータが点在している

• 鮮度– 集計処理に時間がかかる

• 活用– あまり活用できていない…

リクルートライフスタイルの過去10

現在の共通分析基盤

約 300 人の分析者

データサイエンティスト

IBM Netezza

Amazon Redshift

TreasureData

ETL フレームワーク

11

容量： DWH を導入！



IBM Netezza

Amazon Redshift

TreasureData


12

集約：自作 ETL フレームワーク！



IBM Netezza

Amazon Redshift

TreasureData


13

活用：統計ツール /BI ツールの導入



IBM Netezza

Amazon Redshift

TreasureData


14

☆ まだまだ課題はたくさん…

15

• 集約– レガシーなリソースからもデータが取得できる– 過去〜直近のデータも一様に取得できる– 　データハブ基盤が必要！

• 鮮度– リアルタイムにデータを集計・利用したい– 　ストリーム処理基盤が必要！

　　 Water プロジェクトを立ち上げ！

乗り越えるべき課題16

• 「蛇口をひねれば新鮮な水が出てくる」• Kafka を使用したデータハブ基盤の構築• Spark を使用したストリーム処理基盤の構築

• 「データから創出できるサービス」を検討し、　エンジニアがビジネスに貢献する！

Water プロジェクトとは17

vs 　

☆検証→開発→運用環境を即座に構築できる！ ☆キャパシティ設計可能なサービスは便利！ (DynamoDB/API Gateway 等 )

検討したもの ( クラウド or オンプレミス )18

vs 　

☆ コアテクノロジーについては OSS を採用 ☆汎用性の高いハブ基盤を目指した！

検討したもの ( データハブ基盤 )19

　　　　　　　　　 vs 　

☆ (MLlib 等 ) コンポーネントが多い！ ☆ 今後の展開を見据えて Spark Streaming

検討したもの ( ストリーム処理基盤 )20

Grand Design

DynamoDB Lambda APIGateway

Kafka

on-premises

ConfigurationManagement

Monitoring

Grafana

21

データハブ基盤


on-premises


Monitoring

Grafana

22

Kafka

ストリーム処理基盤

Lambda APIGateway

on-premises


Monitoring

Grafana

23

Kafka DynamoDB

データ提供部分 (API)

Kafka

on-premises


Monitoring

Grafana

24


• 鮮度の高いデータを活用することで創出できるサービス案を検討してみた

– 「みんなが注目している」商品を知りたい！– 売り切れてしまう前に手に入れたい！– 興味を持っている (商品を見ている ) 人に伝えたい！

　　ポンパレモール (EC サイト ) 上で「 xx 人が見ています」をテストケースとして構築！

ビジネス要件25

ポンパレモールでの利用例26

ポンパレモールでの利用例27

ウインドウ期間を設定可能！

ちなみに効果は？

• A/B テストの結果、

　

☆104%( スマホ )☆115%(PC)

28

☆ 技術詳細＆ストリーム処理 Tips ！

29

技術詳細 & Tips


Kafka

on-premises

Grafana

2. 入力 3. ストリーム処理 4. 出力

5. モニタリング

1. アーキテクチャ

アーキテクチャ

DynamoDB Lambda APIGatewayKafka

Web Server

Grafana

on-premise Customers

Cloud

31

入力処理データストア出力

Cloud

Customerson-premise

入力


Configuration

Management

Monitoring

Grafana

32

Kafka

Web Server

オンプレからクラウドへデータ連携

Spark Streaming を活かす入力

Secure Forward

Web Server

Kafka

On-premises Cloud

33

KafkaDirectAPI

fluentd-Kafka連携のチューニングポイント


Web Server

Kafka

34

要チューニング

今後よりシンプルなアーキテクチャ


Web Server

Kafka

Version UP

35


Cloud

ストリーム処理

Lambda APIGateway

Web Server

Configuration

Management

Monitoring

Grafana

36

DynamoDBKafka

パーティション数

37 Spark Streaming Tips

Kafka

スループット確保• Spark からみると

多いことも

各パーティションで扱うデータ量調整• 集計処理に合わせて

リパーティション

ログ設定

38 Spark Streaming Tips

LogLog

ログ出力の定常的なチューニングが必要• ローテーション• パージタイミング• エラーレベル

記憶域を圧迫

とは要求レベルが異なるので別管理

新詳細に残す

古捨てるメトリクスは別途残す

• Spark Streaming アプリの開発– 理想

• 開発者の PC で実装・デバッグができる• テスト環境で本番同様に実行できる

– 現実• スペック不足による停止か環境問題か判別が難しい• 本番相当のテストまで問題を回収しきれない

– 対策• ロジックテストとシステムテストを切り分ける

– ロジック部のテストができるよう関数化する– システムテストは AWS で本番同等の環境を用意する

Spark Streaming 活用時のポイント39

• ストリーム処理を動かし続けるポイント– 理想

• ストリーム処理は止まらず稼働を続ける

– 現実• Spark外の入出力部分起因のエラーも発生• 1 つ 1 つのエラーに対応すると

処理が終わらなくなり全体が停止する

– 対策• ストリーム処理向けエラーハンドリング

– 握りつぶすエラーと対応するエラーを選別する


1224 h +

1111 Jobs !

• 動き続けるストリーム処理の定義– 理想

• ストリーム処理は止まらず稼働を続ける

– 現実• 停止は発生する• ストリーム処理の停止とシステム全体の停止は異なる

– 対策• ビジネス要件を満たす稼働状況を定義し影響を小さくするアーキテクチャにする

– 情報鮮度の許容範囲を定める– ストリーム処理停止を出力部の停止に伝搬させない


今後バッチタイプとの統合

Spark Streaming 活用42

バッチ

ストリーム

Data Store


Cloud

出力

Kafka

Web Server

Configuration

Management

Monitoring

Grafana

43


ストリーム処理と出力の独立性

Spark Streaming を活かす出力

データストア Web API

アクセス不可状態処理停止 API

停止アクセス不可状態

高負荷による停止

正常稼動正常稼動 API停止

正常稼動処理停止正常稼動正常稼動

44

アーキテクチャのメリット / デメリット

45 Spark Streaming を活かす出力

DynamoDB Lambda API Gateway

メリット

シームレスなスケーリング

データストア～ API で透過的にインスタンスがなく運用が楽

低コスト（特に Lambda + API Gateway ）

デメリット

テスト環境の作りにくさ

多様な形式・フォーマットへの対応の難しさ

• データストアとして DynamoDB を選んだ理由– データを Update する実装のため書き込みと呼び出し常時発生

– Web API のレスポンスを考慮すると一貫性よりもスループットを重視

• 工夫点– DynamoDB は平準的な

アクセスが得意• 書き込み量に耐え切れない時

エラーは握りつぶして次へ• 動的に DynamoDB のキャパシティを設定


DynamoDB

46

動的にキャパシティを変更

書き込み失敗

Update

その後書き込みは成功

今後


DynamoDB

47

Lambda API Gateway

他データストア対応 API の柔軟性向上

Web Application

データストアデータアクセス


Cloud

運用設計（モニタリング）

DynamoDB Lambda APIGatewayKafka

Web Server

Configuration

Management

48

Monitoring

Grafana

時系列 DB を利用した性能の観測・可視化

運用設計49

Grafana Dashboards AWS CloudWatch Dashboards

DynamoDB Lambda API Gateway

Kafka

今後

運用設計50

Grafana

DynamoDB

Lambda

API Gateway

Kafka

メトリクスの集約観測・予測によるオートスケール

Cluster Cluster

振り返り

• 少人数で機動力持って出来た！– 検証を重ねるべき部分は時間をかけつつ、短期で作り上げた

• 「なかったら作る」の姿勢– プロダクトとプロダクトの隙間は自分で埋める

• OSS に対する取り組み– コアテクノロジーは OSS を使い、とことん性能検証

• AWS を選んだ理由– 「 AWS を使いこなす」はゴールではない– スケーラブルなインフラ＆汎用的なサービスは使っていく

• 性能観測についての取り組み– OSS を選択した以上、性能に対する取り組みは非常に重要– 各種メトリクスを利用していく事で改善に取り組んだ

51

• まだ道は半ばです！• やってみたいこと

– データソースを増やしてハブ化を推進！– 横展開– 新しいサービスを作りたい！– 基盤を使ってサービス完成までの時間を短縮した

い！

• エンジニアがビジネスを創出する環境を作る！

これから52

WE ARE HIRING!53

ご清聴ありがとうございました

54