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