リクルートライフスタイルの考えるストリームデータの活かし方~ 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
堤 崇行 ( つつみ たかゆき )• 所属
– 株式会社NTTデータ
• 経歴– 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 を導入!
約 300 人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETL フレームワーク
12
集約:自作 ETL フレームワーク!
約 300 人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETL フレームワーク
13
活用:統計ツール /BI ツールの導入
約 300 人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETL フレームワーク
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
データハブ基盤
DynamoDB Lambda APIGateway
on-premises
ConfigurationManagement
Monitoring
Grafana
22
Kafka
ストリーム処理基盤
Lambda APIGateway
on-premises
ConfigurationManagement
Monitoring
Grafana
23
Kafka DynamoDB
データ提供部分 (API)
Kafka
on-premises
ConfigurationManagement
Monitoring
Grafana
24
DynamoDB Lambda APIGateway
• 鮮度の高いデータを活用することで創出できるサービス案を検討してみた
– 「みんなが注目している」商品を知りたい!– 売り切れてしまう前に手に入れたい!– 興味を持っている (商品を見ている ) 人に伝えたい!
ポンパレモール (EC サイト ) 上で「 xx 人が見ています」をテストケースとして構築!
ビジネス要件25
ポンパレモールでの利用例26
ポンパレモールでの利用例27
ウインドウ期間を設定可能!
ちなみに効果は?
• A/B テストの結果、
☆104%( スマホ )☆115%(PC)
28
☆ 技術詳細&ストリーム処理 Tips !
29
技術詳細 & Tips
DynamoDB Lambda APIGateway
Kafka
on-premises
Grafana
2. 入力 3. ストリーム処理 4. 出力
5. モニタリング
1. アーキテクチャ
アーキテクチャ
DynamoDB Lambda APIGatewayKafka
Web Server
Grafana
on-premise Customers
Cloud
31
入力 処理 データストア 出力
Cloud
Customerson-premise
入力
DynamoDB Lambda APIGateway
Configuration
Management
Monitoring
Grafana
32
Kafka
Web Server
オンプレからクラウドへデータ連携
Spark Streaming を活かす入力
Secure Forward
Web Server
Kafka
On-premises Cloud
33
KafkaDirectAPI
fluentd-Kafka連携のチューニングポイント
Spark Streaming を活かす入力
Web Server
Kafka
34
要チューニング
今後よりシンプルなアーキテクチャ
Spark Streaming を活かす入力
Web Server
Kafka
Version UP
35
on-premise Customers
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 つのエラーに対応すると
処理が終わらなくなり全体が停止する
– 対策• ストリーム処理向けエラーハンドリング
– 握りつぶすエラーと対応するエラーを選別する
Spark Streaming 活用時のポイント40
1224 h +
1111 Jobs !
• 動き続けるストリーム処理の定義– 理想
• ストリーム処理は止まらず稼働を続ける
– 現実• 停止は発生する• ストリーム処理の停止とシステム全体の停止は異なる
– 対策• ビジネス要件を満たす稼働状況を定義し影響を小さくするアーキテクチャにする
– 情報鮮度の許容範囲を定める– ストリーム処理停止を出力部の停止に伝搬させない
Spark Streaming 活用時のポイント41
今後バッチタイプとの統合
Spark Streaming 活用42
バッチ
ストリーム
Data Store
on-premise Customers
Cloud
出力
Kafka
Web Server
Configuration
Management
Monitoring
Grafana
43
DynamoDB Lambda APIGateway
ストリーム処理と出力の独立性
Spark Streaming を活かす出力
データストア Web API
アクセス不可状態処理停止 API
停止アクセス不可状態
高負荷による停止
正常稼動 正常稼動 API停止
正常稼動処理停止 正常稼動 正常稼動
44
アーキテクチャのメリット / デメリット
45 Spark Streaming を活かす出力
DynamoDB Lambda API Gateway
メリット
シームレスなスケーリング
データストア~ API で透過的にインスタンスがなく運用が楽
低コスト(特に Lambda + API Gateway )
デメリット
テスト環境の作りにくさ
多様な形式・フォーマットへの対応の難しさ
• データストアとして DynamoDB を選んだ理由– データを Update する実装のため書き込みと呼び出し常時発生
– Web API のレスポンスを考慮すると一貫性よりもスループットを重視
• 工夫点– DynamoDB は平準的な
アクセスが得意• 書き込み量に耐え切れない時
エラーは握りつぶして次へ• 動的に DynamoDB のキャパシティを設定
Spark Streaming を活かす出力
DynamoDB
46
動的にキャパシティを変更
書き込み失敗
Update
その後書き込みは成功
今後
Spark Streaming を活かす出力
DynamoDB
47
Lambda API Gateway
他データストア対応 API の柔軟性向上
Web Application
データストア データアクセス
on-premise Customers
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