データ分析基盤におけるOpsのためのDev with event driven + serverless

1. データ分析基盤におけるOpsのためのDev
with event driven + Serverless
白鳥 昇治
ネットビジネス本部
データマネジメントグループ
データプラットフォームチーム
@DevOpsDays Tokyo 2018
2018.04.25

2. 2 今日お話すること
• サーバーレスアーキテクチャでデータ分析基盤
を構築し、運用負荷の低減と機能開発への集中
を行った事例

3. 3 自己紹介
• 白鳥 昇治 / @irotoris
データエンジニア@リクルートライフスタイル
2013.04〜 SIer
• インフラエンジニアとしてプライベートクラウドの開発・運用
• 開発ツールの社内ホスティングサービス開発・運用
2017.07〜 リクルートライフスタイル
• データエンジニアとして社内データ分析基盤/データパイプライン
の開発・運用
興味/関心事
• Docker / Kubernetes / IaC / CD/CI / Serverless

4. 4 リクルートライフスタイルとは

5. 5 データドリブンビジネス

6. 6 データ利活用の３大要素「入力・処理・出力」
入力 出力処理

7. 7 リクルートライフスタイルのデータ分析基盤
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
Redshift (mirror)
BigQuery
Cloud Storage
アクセスログ
アプリログ Treasure Data
ORACLE
Exadata

8. 8 リクルートライフスタイルのデータ分析基盤
HPB HPG
JLN
事業データ
CSV
外部データ
S3
Redshift
Redshift (mirror)
BigQuery
Cloud Storage
アクセスログ
アプリログ Treasure Data
ORACLE
Exadata
入力 出力処理

9. 9 データ分析基盤で提供したい価値
• データ分析基盤は使ってもらってなんぼ
• たくさん分析してもらって事業成果を上げてもらう
• たくさん分析してもらうには
 基盤を提供し続ける
 パフォーマンスを上げる
 データ品質を上げる
 新しいデータ連携の追加
 データ鮮度を保つ&上げる

10. 10 データ分析基盤チーム
Dev Team
• より効率的なデータ連携・集計の仕組みの開発
• ビッグデータ系の新しい技術・サービスの検証・導入
Ops Team
• 日々のデータ連携・集計バッチのモニタリング・エラー対応
• 新しいデータソース連携や集計バッチの追加対応
• インフラ・ミドルウェアの管理と整備
みんなで
• データをどう効率的・安定的に処理・提供するか考える
• データを使って何かしたい人たちの相談に乗る
• 大規模なエラー対応

11. 11 データ分析基盤チームがやりたいこと
Dev Team
• より効率的なデータ連携・集計の仕組みの開発
• ビッグデータ系の新しい技術・サービスの検証・導入
Ops Team
• 日々のデータ連携・集計バッチのモニタリング・エラー対応
• 新しいデータソース連携や集計バッチの追加対応
• インフラ・ミドルウェアの管理と整備
みんなで
• データをどう効率的・安定的に処理・提供するか考える
• データを使って何かしたい人たちの相談に乗る
• 大規模なエラー対応
価値を増幅させ、素早く届けるための活動
その活動のための時間を創出する

12. ここから事例の話

13. 13 ある日…
「機械学習基盤つくって。サービス
に組み込むやつ。」
「やりましょう。」
メンバー

14. 結果
14 トリップAIコンシェルジュ
入力 出力処理
問い合わせに対する回答の精度を
高めるための機械学習基盤
フロントエンド
（チャット）
学習結果をAIへ反映
バックエンド
（AI）

15. 15 なにする基盤?
有効な学習データ
分類済み質問データ
学習済みデータ
質問データ
分類不可質問データ
入力 出力処理
Active Learning
最適化/並列処理
Text Clustering
Powered by データサイエンティスト

16. 16
さあつくろう、でもちょっとまって

17. 17 いままでの分析基盤開発・運用を振り返る
• データロード・集計処理・データ転送は、バッチサーバー
（オンプレ）やEC2インスタンス上で行っている
 ジョブのキックはジョブスケジューラ（JP1）を採用
• 問題点
 サーバー、ジョブスケジューラがSPOF
 トラブル発生時の対応が大量に発生
 スケールしない
 1サーバーに複数のランタイムがインストール
 影響範囲がわからない
 OS、ミドルウェアの管理が必要
 定期的なメンテナンスコストが無視できない
つらみ

18. 18 新しい基盤を作る上で考えたこと
サーバーをなくせばいいじゃない。
マネージドサービス使えば急な
データスパイクにも楽にスケール
対応できそう。

19. 19 新しい基盤を作る上で考えたこと
• スケーラビリティ：データ量の増加、スパイクに耐えられるスケー
ラビリティ。
• 可用性：プロダクション環境なのでSPOF（単一障害点）は作りた
くない。エラー時のリトライ処理を組んでおく。
• メンテナンス性：運用コストのかからない設計。機能開発のために
工数を割けるように。
• 堅牢性：セキュアな設計、将来的な機能追加にもすぐ対応できる変
化に強い基盤が必要。
• コスト：基盤のコストだけでなく、運用コストも下げれるように。
ちゃんと考えました。

20. よろしい、ならばサーバーレスだ

21. Machine learning pipelines
on-premises
Data load
Machine
learning
on-premises
State control
Cloud trail
Cloud watch
Monitoring

22. 22 よろしい、ならばサーバーレスだ
https://www.slideshare.net/RecruitLifestyle/step-functionsaws-batch-81700778
詳しくはServerlessconfの登壇資料をチェック！

23. 23 この基盤の運用をなるべく減らすためのDev
• event driven + Serverless
 イベント（ファイル連携）発生時のみパイプラインが起動
 AWS Batchによりオンデマンドに実行環境が起動
 バッチはコンテナでまとめる
• 自動リトライ
 各処理ですべてにリトライ処理を実装する
 処理はべき等にしておく
retry×3retry×3retry×3

24. 24 この基盤の運用をなるべく減らすためのDev
• ロギング、モニタリング
 ERRORログ、特定のINFOログはSlackへ通知
 INFOログはバッチの実行状態を把握するため
 基盤のモニタリングはDatadogに集約
 パイプラインの状態可視化：バッチのステータスを
DynamoDB→Elasticsearch+Kibanaで可視化

25. 25 この基盤の運用をなるべく減らすためのDev
• CD/CI、Infrastructure as a Code(IaC)
 基盤構成はすべてTerraform、Ansibleでコード化
 バッチの単体テスト、パイプラインのE2Eテストを自動化
 テストとデプロイはJenkinsパイプラインを構築
Dev
Stg1
Prd
機械学習パイプライン
コンテナの単体テスト
E2Eテスト
デプロイ

26. 26 ServerlessでDevOpsプラクティスがどう変わったか
• Infrastructure as Code
• CD/CI
• ロギング、モニタリング
• 協業/コミュニケーション

27. 27 ServerlessでDevOpsプラクティスがどう変わったか
Infrastructure as a Code
• よかったこと
 コード量：Terraform >> Ansible
 IaCデプロイパイプラインの構築難易度：Terraform >> Ansible
 サーバーのチューニング項目やミドルウェアなどの独自に検
証・設計しなければいけないものが減った。
• 課題
 Terraform職人爆誕→ボトルネック
 教育？or採用？

28. 28 ServerlessでDevOpsプラクティスがどう変わったか
CD/CI
• よかったこと
 バッチはコンテナで動かしているので、デプロイ／ロールバッ
クが簡単に。イメージ差替だけ。
 テストパスすればいつでもデプロイ可能な状態に。
 コンピュートリソースは独立しているので、いろんな変更を並
列テストできる。
• 課題
 Lambda／サーバーレス基盤自体のテスト、特に異常系が難しい
 AWS sam-local（AWSリソースのイベントをローカルで再現できる）
 E2Eのテストだけでは心もとない
 機械学習プログラムが5時間かかる→テストがボトルネック
 データ量によってテストステージを分ける

29. 29 ServerlessでDevOpsプラクティスがどう変わったか
ロギング、モニタリング
• よかったこと
 Lambdaで外形監視を組みやすい（パイプライン自体を変更しな
くても良い）
 マネージドサービスAPI→CloudWatch→Datadogでアラート
• 課題
 ログの出力先が個々のマネージドサービスのコンソール、
CWLに吐かれるのでトレースが難しい
Slackに集約しても逆によくわからなくなる
 パイプラインの全体像がわかりにくくなる
Elasticsearch+Kibanaで状態遷移を可視化してもバッチ数が多
いと限界がある
 必要なエラーイベントだけ補足できればOKかも？

30. 30 ServerlessでDevOpsプラクティスがどう変わったか
協業／コミュニケーション
• よかったこと
 サイエンティストとエンジニアがお互い歩み寄って成果を上げた

31. 31 diff データサイエンティスト データエンジニア
データエンジニアデータサイエンティスト
• モデルの予測精度向上
• 学習速度向上
• Edge版ライブラリ
etc.
• エラーハンドリング
• ワークロード最適化
• オートスケール
• Stable版ライブラリ
etc.
興味・志向・軸
お互いの知識ドメインが異なる

32. 32 歩み寄る
データエンジニアデータサイエンティスト
興味・志向・軸
このライブラリ使いたいです。
メモリ1TBとvCPU64使います。
MongoDBも使っていいですか？
Dockerfile書いてくれれば基盤側でな
んとかします。
ロギングとエラーハンドリングだけお
願いします。

33. 33 コミュニケーション
データエンジニアデータサイエンティスト

34. 34 歩み寄った結果
データエンジニアデータサイエンティスト
「72時間かかってたプログラムを5時
間で終わるようにしました。」
「精度も基準値を大幅にクリアしまし
た。」
「データ量に合わせて動的にリソース
が確保できるようにしました。」
「このエラーでたらアラート出るよう
にしました。」

35. 35 歩み寄った結果
データエンジニアデータサイエンティスト
「すごい！」
「すごい！」

36. 36 運用、どうですか？
• 運用期間：2017/12〜現在
• 自動リトライ処理のお陰で、基盤側のエラーはほぼ自動で解
決している。Datadogを眺めているくらい。
• いつでもすぐバッチのデプロイが可能な状態。
• 余裕が出たのでDevSecOpsにもトライ。
– 新しいこと、やりたいことに取り組めている＝いい状態！
機械学習基盤の運用もしつつ、本業のデータ分析基
盤の開発も行えました。

37. 37 まとめ
• 運用を極力減らし、機能開発に集中するためのevent driven +
Serverlessなバッチシステム構成とそのDevOpsプラクティス変化について
紹介しました。
• Serverlessとバッチシステムは相性が良い。
• 次→もっとServerless！
 現状のデータ分析基盤 / データパイプライン / バッチシステム
をサーバーレス構成で順次適用中
 より複雑で並列度の高いバッチシステムをサーバーレスででき
るか？運用減らして価値開発に集中できるか？

38. 38 最後に：リクルートライフスタイルのエンジニア文化

39. 39
THANK YOU!