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

Atsushi Kurumada
Atsushi Kurumadaマイクロアド(MicroAd,Inc.)
リクルートライフスタイルの考える
ストリームデータの活かし方
~AWS + Kafka + Spark Streaming~
車田 篤史
ネットビジネス本部
アーキテクト1グループ
データ基盤チーム
堤 崇行
ITサービス・ペイメント事業本部
放送・情報サービス事業部
情報ビジネス統括部
1. リクルートスタイルにおけるビッグデータとは
2. ビッグデータの過去・現在・未来
3. Waterプロジェクトとは
4. ポンパレモールでの利用例
5. 技術詳細&ストリーム処理Tips
6. まとめ
アジェンダ1
• 車田 篤史(くるまだ あつし)
• 1999年 信号機メーカーで回路設計とか組込みLinuxやってました
• 2011年 広告配信系のインフラ(HadoopとかDWH)をやってました
• 2015年 リクルートライフスタイル入社
• データ基盤チームでビッグデータと日々向かい合っています
• 趣味:カメラ、時計・万年筆・英国靴・オーディオ機器
https://www.facebook.com/atsushi.kurumada
自己紹介2
会社紹介3
堤 崇行 (つつみ たかゆき)
• 所属
– 株式会社NTTデータ
• 経歴
– 2011年 Webアプリ開発者
– 2012年 データ活用(分析基盤、サーバーサイド開発)
• 最近使っている技術
– Apache Spark, Ansible, Scala, Python, Haskell(趣味)
自己紹介4
リクルートライフスタイル様の
ビジネスパートナーとして
データの価値創出や戦略を共に考え
データ活用の世界観を共に描いていけるよう
サポートしています。
会社紹介5
リクルートライフスタイルのミッション6
データ基盤チームの役割
Engineering
for data
Business
with data
エンジニアが
ビジネスを推進する
安定したインフラ基盤 継続的な開発+
7
• 容量(Volume)
– データ量の制限なく保存できる
• 集約(Variety)
– 多様なデータが1箇所に集まっている
• 鮮度(Velocity)
– 保存データをすぐに利用できる
• 活用
– データを活用できなかったら意味が無い
ビッグデータにおける普遍的テーマ8
• 容量
– 日々増加し続けるデータ量
(数十TB規模に増加、行動ログは1,000億レコード規模)
• 集約
– RDB/ファイル等にデータが点在している
• 鮮度
– 集計処理に時間がかかる
• 活用
– あまり活用できていない…
リクルートライフスタイルの過去9
現在の共通分析基盤
約300人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETLフレームワーク
10
容量:DWHを導入!
約300人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETLフレームワーク
11
集約:自作ETLフレームワーク!
約300人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETLフレームワーク
12
活用:統計ツール/BIツールの導入
約300人の分析者
データサイエンティスト
IBM Netezza
Amazon Redshift
TreasureData
ETLフレームワーク
13
☆まだまだ課題はたくさん…
14
• 集約
– レガシーなリソースからもデータが取得できる
– 過去〜直近のデータも一様に取得できる
– データハブ基盤が必要!
• 鮮度
– リアルタイムにデータを集計・利用したい
– ストリーム処理基盤が必要!
Waterプロジェクトを立ち上げ!
乗り越えるべき課題15
• 「蛇口をひねれば新鮮な水が出てくる」
• Kafkaを使用したデータハブ基盤の構築
• Sparkを使用したストリーム処理基盤の構築
• 「データから創出できるサービス」を検討し、
エンジニアがビジネスに貢献する!
Waterプロジェクトとは16
vs
☆検証→開発→運用環境を即座に構築できる!
☆キャパシティ設計可能なサービスは便利!
(DynamoDB/API Gateway等)
検討したもの(クラウド or オンプレミス)17
vs
☆コアテクノロジーについてはOSSを採用
☆汎用性の高いハブ基盤を目指した!
検討したもの(データハブ基盤)18
vs
☆ (MLlib等)コンポーネントが多い!
☆ 今後の展開を見据えてSpark Streaming
検討したもの(ストリーム処理基盤)19
Grand Design
DynamoDB Lambda
API
Gateway
Kafka
on-premises
Configuration
Management
Monitoring
Grafana
20
データハブ基盤
DynamoDB Lambda
API
Gateway
on-premises
Configuration
Management
Monitoring
Grafana
21
Kafka
ストリーム処理基盤
Lambda
API
Gateway
on-premises
Configuration
Management
Monitoring
Grafana
22
Kafka DynamoDB
データ提供部分(API)
Kafka
on-premises
Configuration
Management
Monitoring
Grafana
23
DynamoDB Lambda
API
Gateway
• 鮮度の高いデータを活用することで創出できる
サービス案を検討してみた
– 「みんなが注目している」商品を知りたい!
– 売り切れてしまう前に手に入れたい!
– 興味を持っている(商品を見ている)人に伝えたい!
ポンパレモール(ECサイト)上で
「xx人が見ています」をテストケースとして構築!
ビジネス要件24
ポンパレモールでの利用例25
ポンパレモールでの利用例26
ウインドウ期間を設定可能!
ちなみに効果は?
• A/Bテストの結果、
☆104%(スマホ)
☆115%(PC)
27
☆技術詳細&ストリーム処理Tips!
28
技術詳細 & Tips
DynamoDB Lambda
API
Gateway
Kafka
on-premises
Grafana
2. 入力 3. ストリーム処理 4. 出力
5. モニタリング
1. アーキテクチャ
アーキテクチャ
DynamoDB Lambda API
Gateway
Kafka
Web Server
Grafana
on-premise Customers
Cloud
30
入力 処理 データ
ストア 出力
Cloud
Customerson-premise
入力
DynamoDB Lambda API
Gateway
Configuration
Management
Monitoring
Grafana
31
Kafka
Web Server
オンプレからクラウドへデータ連携
Spark Streamingを活かす入力
Secure
Forward
Web Server
Kafka
On-premises Cloud
32
KafkaDirect
API
fluentd-Kafka連携のチューニングポイント
Spark Streamingを活かす入力
Web Server
Kafka
33
要チューニング
今後
よりシンプルなアーキテクチャ
Spark Streamingを活かす入力
Web Server
Kafka
Version UP
34
on-premise Customers
Cloud
ストリーム処理
Lambda API
Gateway
Web Server
Configuration
Management
Monitoring
Grafana
35
DynamoDBKafka
パーティション数
36 Spark Streaming Tips
Kafka
スループット確保
• Sparkからみると
多いことも
各パーティションで扱う
データ量調整
• 集計処理に合わせて
リパーティション
ログ設定
37 Spark Streaming Tips
Log
Log
ログ出力の定常的なチューニングが必要
• ローテーション
• パージタイミング
• エラーレベル
記憶域を
圧迫
とは要求レベルが異なるので別管理
新 詳細に残す
古
捨てる
メトリクスは別途残す
• Spark Streamingアプリの開発
– 理想
• 開発者のPCで実装・デバッグができる
• テスト環境で本番同様に実行できる
– 現実
• スペック不足による停止か環境問題か判別が難しい
• 本番相当のテストまで問題を回収しきれない
– 対策
• ロジックテストとシステムテストを切り分ける
– ロジック部のテストができるよう関数化する
– システムテストはAWSで本番同等の環境を用意する
Spark Streaming活用時のポイント38
• ストリーム処理を動かし続けるポイント
– 理想
• ストリーム処理は止まらず稼働を続ける
– 現実
• Spark外の入出力部分起因のエラーも発生
• 1つ1つのエラーに対応すると
処理が終わらなくなり全体が停止する
– 対策
• ストリーム処理向けエラーハンドリング
– 握りつぶすエラーと
対応するエラーを選別する
Spark Streaming活用時のポイント39
1224 h +
1111 Jobs !
• 動き続けるストリーム処理の定義
– 理想
• ストリーム処理は止まらず稼働を続ける
– 現実
• 停止は発生する
• ストリーム処理の停止とシステム全体の停止は異なる
– 対策
• ビジネス要件を満たす稼働状況を定義し
影響を小さくするアーキテクチャにする
– 情報鮮度の許容範囲を定める
– ストリーム処理停止を出力部の停止に伝搬させない
Spark Streaming活用時のポイント40
今後
バッチタイプとの統合
Spark Streaming活用41
バッチ
ストリーム
Data Store
on-premise Customers
Cloud
出力
Kafka
Web Server
Configuration
Management
Monitoring
Grafana
42
DynamoDB Lambda API
Gateway
ストリーム処理と出力の独立性
Spark Streamingを活かす出力
データストア Web API
アクセス
不可状態
処理停止
API
停止
アクセス
不可状態
高負荷
による停止
正常稼動 正常稼動
API
停止
正常稼動処理停止 正常稼動 正常稼動
43
アーキテクチャのメリット / デメリット
44 Spark Streamingを活かす出力
DynamoDB Lambda API Gateway
メリット
シームレスなスケーリング
データストア〜APIで透過的にインスタンスがなく運用が楽
低コスト(特にLambda + API Gateway)
デメリット
テスト環境の作りにくさ
多様な形式・フォーマットへの対応の難しさ
• データストアとしてDynamoDBを選んだ理由
– データをUpdateする実装のため
書き込みと呼び出し常時発生
– Web APIのレスポンスを考慮すると
一貫性よりもスループットを重視
• 工夫点
– DynamoDBは平準的な
アクセスが得意
• 書き込み量に耐え切れない時
エラーは握りつぶして次へ
• 動的にDynamoDBの
キャパシティを設定
Spark Streamingを活かす出力
DynamoDB
45
動的にキャパシティを変更
書き込み失敗
Update
その後
書き込みは成功
今後
Spark Streamingを活かす出力
DynamoDB
46
Lambda API Gateway
他データストア対応 APIの柔軟性向上
Web Application
データストア データアクセス
on-premise Customers
Cloud
運用設計(モニタリング)
DynamoDB Lambda API
Gateway
Kafka
Web Server
Configuration
Management
47
Monitoring
Grafana
時系列DBを利用した性能の観測・可視化
運用設計48
Grafana Dashboards AWS CloudWatch Dashboards
DynamoDB Lambda API Gateway
Kafka
今後
運用設計49
Grafana
DynamoDB
Lambda
API Gateway
Kafka
メトリクスの集約 観測・予測によるオートスケール
Cluster
Cluster
振り返り
• 少人数で機動力持って出来た!
– 検証を重ねるべき部分は時間をかけつつ、短期で作り上げた
• 「なかったら作る」の姿勢
– プロダクトとプロダクトの隙間は自分で埋める
• OSSに対する取り組み
– コアテクノロジーはOSSを使い、とことん性能検証
• AWSを選んだ理由
– 「AWSを使いこなす」はゴールではない
– スケーラブルなインフラ&汎用的なサービスは使っていく
• 性能観測についての取り組み
– OSSを選択した以上、性能に対する取り組みは非常に重要
– 各種メトリクスを利用していく事で改善に取り組んだ
50
• まだ道は半ばです!
• やってみたいこと
– データソースを増やしてハブ化を推進!
– 横展開
– 新しいサービスを作りたい!
– 基盤を使ってサービス完成までの時間を短縮したい!
• エンジニアがビジネスを創出する環境を作る!
これから51
WE ARE HIRING!52
ご清聴ありがとうございました
53
1 of 54

More Related Content

What's hot(20)

Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)
Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)
Yahoo!デベロッパーネットワーク21.9K views
Hadoop -NameNode HAの仕組み-Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-
Yuki Gonda4.1K views
Ceph アーキテクチャ概説Ceph アーキテクチャ概説
Ceph アーキテクチャ概説
Emma Haruka Iwao30.4K views
KafkaとAWS Kinesisの比較KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較
Yoshiyasu SAEKI14.8K views
AWSで作る分析基盤AWSで作る分析基盤
AWSで作る分析基盤
Yu Otsubo7.3K views

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

「Data Infrastructure at Scale 」#yjdsw4「Data Infrastructure at Scale 」#yjdsw4
「Data Infrastructure at Scale 」#yjdsw4
Yahoo!デベロッパーネットワーク584 views
Hueによる分析業務の改善事例Hueによる分析業務の改善事例
Hueによる分析業務の改善事例
Masahiro Kiura2.9K views
MonotaRO のデータ活用と基盤の過去、現在、未来 MonotaRO のデータ活用と基盤の過去、現在、未来
MonotaRO のデータ活用と基盤の過去、現在、未来
株式会社MonotaRO Tech Team13.3K views
情報爆発シンポジウム infoplosion情報爆発シンポジウム infoplosion
情報爆発シンポジウム infoplosion
Rakuten Group, Inc.1.4K views
データ分析基盤を支えるエンジニアリングデータ分析基盤を支えるエンジニアリング
データ分析基盤を支えるエンジニアリング
Recruit Lifestyle Co., Ltd.9.8K views
クラウド座談会資料クラウド座談会資料
クラウド座談会資料
知礼 八子2.2K views

Recently uploaded(7)

robotics42.pptxrobotics42.pptx
robotics42.pptx
Natsutani Minoru165 views
SSH超入門SSH超入門
SSH超入門
Toru Miyahara12 views
lt.pptxlt.pptx
lt.pptx
tomochamarika39 views
図解で理解するvetKD図解で理解するvetKD
図解で理解するvetKD
ryoo toku84 views

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

Editor's Notes

  1. それでは、リクルートライフスタイルが、どのようなミッションを持って事業を行っているか、をお伝えしたいと思います。 「ちょっとした毎日を提供し、ひとりひとりの生活を豊かにする。 それが、リクルートライフスタイルの願いです」 私たちデータ基盤チームは、ビッグデータで支えるべく、日々改善に取り組んでいます。