Downloaded 70 times
Uploaded byAtsushi Kurumada
リクルートライフスタイルの考える ストリームデータの活かし方(Hadoop Spark Conference2016)
リクルートライフスタイルの考える ストリームデータの活かし方 ～AWS + Kafka + Spark Streaming～
![[INSIGHT OUT 2011] b21 ひとつのデータベース技術では生き残れない part2 no sql, hadoop](https://cdn.slidesharecdn.com/ss_thumbnails/insightout2011b21part2nosqlhadoop-111114020909-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
リクルートライフスタイルの考える ストリームデータの活かし方(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.
- 5. 堤 崇行 (つつみたかゆき) • 所属 – 株式会社ＮＴＴデータ • 経歴 – 2011年 Webアプリ開発者 – 2012年 データ活用（分析基盤、サーバーサイド開発） • 最近使っている技術 – Apache Spark, Ansible, Scala, Python, Haskell(趣味) 自己紹介4
- 6.
- 7.
- 8.
- 9. • 容量(Volume) – データ量の制限なく保存できる •集約(Variety) – 多様なデータが1箇所に集まっている • 鮮度(Velocity) – 保存データをすぐに利用できる • 活用 – データを活用できなかったら意味が無い ビッグデータにおける普遍的テーマ8
- 10. • 容量 – 日々増加し続けるデータ量 (数十TB規模に増加、行動ログは1,000億レコード規模) •集約 – RDB/ファイル等にデータが点在している • 鮮度 – 集計処理に時間がかかる • 活用 – あまり活用できていない… リクルートライフスタイルの過去9
- 11.
- 12.
- 13.
- 14.
- 15.
- 16. • 集約 – レガシーなリソースからもデータが取得できる –過去〜直近のデータも一様に取得できる – データハブ基盤が必要！ • 鮮度 – リアルタイムにデータを集計・利用したい – ストリーム処理基盤が必要！ Waterプロジェクトを立ち上げ！ 乗り越えるべき課題15
- 17. • 「蛇口をひねれば新鮮な水が出てくる」 • Kafkaを使用したデータハブ基盤の構築 •Sparkを使用したストリーム処理基盤の構築 • 「データから創出できるサービス」を検討し、 エンジニアがビジネスに貢献する！ Waterプロジェクトとは16
- 18.
- 19.
- 20. vs ☆ (MLlib等)コンポーネントが多い！ ☆ 今後の展開を見据えてSparkStreaming 検討したもの(ストリーム処理基盤)19
- 21.
- 22.
- 23.
- 24.
- 25. • 鮮度の高いデータを活用することで創出できる サービス案を検討してみた – 「みんなが注目している」商品を知りたい！ –売り切れてしまう前に手に入れたい！ – 興味を持っている(商品を見ている)人に伝えたい！ ポンパレモール(ECサイト)上で 「xx人が見ています」をテストケースとして構築！ ビジネス要件24
- 26.
- 27.
- 28.
- 29.
- 30. 技術詳細 & Tips DynamoDBLambda API Gateway Kafka on-premises Grafana 2. 入力 3. ストリーム処理 4. 出力 5. モニタリング 1. アーキテクチャ
- 31. アーキテクチャ DynamoDB Lambda API Gateway Kafka WebServer Grafana on-premise Customers Cloud 30 入力 処理 データ ストア 出力
- 32.
- 33. オンプレからクラウドへデータ連携 Spark Streamingを活かす入力 Secure Forward Web Server Kafka On-premisesCloud 32 KafkaDirect API
- 34.
- 35.
- 36. on-premise Customers Cloud ストリーム処理 Lambda API Gateway WebServer Configuration Management Monitoring Grafana 35 DynamoDBKafka
- 37. パーティション数 36 Spark StreamingTips Kafka スループット確保 • Sparkからみると 多いことも 各パーティションで扱う データ量調整 • 集計処理に合わせて リパーティション
- 38. ログ設定 37 Spark StreamingTips 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
- 42.
- 43.
- 44. ストリーム処理と出力の独立性 Spark Streamingを活かす出力 データストア WebAPI アクセス 不可状態 処理停止 API 停止 アクセス 不可状態 高負荷 による停止 正常稼動 正常稼動 API 停止 正常稼動処理停止 正常稼動 正常稼動 43
- 45. アーキテクチャのメリット / デメリット 44Spark 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 APIGateway 他データストア対応 APIの柔軟性向上 Web Application データストア データアクセス
- 48. on-premise Customers Cloud 運用設計（モニタリング） DynamoDB LambdaAPI Gateway Kafka Web Server Configuration Management 47 Monitoring Grafana
- 49. 時系列DBを利用した性能の観測・可視化 運用設計48 Grafana Dashboards AWSCloudWatch Dashboards DynamoDB Lambda API Gateway Kafka
- 50.
- 51. 振り返り • 少人数で機動力持って出来た！ – 検証を重ねるべき部分は時間をかけつつ、短期で作り上げた •「なかったら作る」の姿勢 – プロダクトとプロダクトの隙間は自分で埋める • OSSに対する取り組み – コアテクノロジーはOSSを使い、とことん性能検証 • AWSを選んだ理由 – 「AWSを使いこなす」はゴールではない – スケーラブルなインフラ＆汎用的なサービスは使っていく • 性能観測についての取り組み – OSSを選択した以上、性能に対する取り組みは非常に重要 – 各種メトリクスを利用していく事で改善に取り組んだ 50
- 52. • まだ道は半ばです！ • やってみたいこと –データソースを増やしてハブ化を推進！ – 横展開 – 新しいサービスを作りたい！ – 基盤を使ってサービス完成までの時間を短縮したい！ • エンジニアがビジネスを創出する環境を作る！ これから51
- 53.
- 54.
Editor's Notes
- #8 それでは、リクルートライフスタイルが、どのようなミッションを持って事業を行っているか、をお伝えしたいと思います。 「ちょっとした毎日を提供し、ひとりひとりの生活を豊かにする。 それが、リクルートライフスタイルの願いです」 私たちデータ基盤チームは、ビッグデータで支えるべく、日々改善に取り組んでいます。