Step functionsとaws batchて?オーケストレートするイヘ?ントト?リフ?ンな機械学習基盤
Download as PPTX, PDF6 likes8,949 views
リクルートライフスタイルでは機械学習を用いたサービスの展開もしています。サービスが増え続ける中で素早く市場に対応するためには、いかに簡単に基盤を作り、運用を減らせていくかが重要になってきます。 上記の課題を踏まえパワーが必要な機械学習処理のためのサーバレス基盤を構築しました。 なぜserverlessを選択したのか？ 構築にあたり使用したStep FunctionsやAWS Batchの注意点と共に機械学習基盤を紹介します。 山田 雄（株式会社リクルートライフスタイル）
![[db tech showcase Tokyo 2017] E21: InfluxDB+αで時系列データの異常検知を可視化してみた by 株式会社インサイ...](https://cdn.slidesharecdn.com/ss_thumbnails/e21-170912082211-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Viewers also liked (14)
![[Black Belt Online Seminar] AWS上でのログ管理](https://cdn.slidesharecdn.com/ss_thumbnails/aws-log-mgmt-161201043056-thumbnail.jpg?width=560&fit=bounds)
Similar to Step functionsとaws batchて?オーケストレートするイヘ?ントト?リフ?ンな機械学習基盤 (20)
![[de:code 2019 振り返り Night!] Data Platform](https://cdn.slidesharecdn.com/ss_thumbnails/20190610decode2019dataplatformrecap-190610113039-thumbnail.jpg?width=560&fit=bounds)
More from Yu Yamada (9)
Recently uploaded (11)
Step functionsとaws batchて?オーケストレートするイヘ?ントト?リフ?ンな機械学習基盤
- 1. Step FunctionsとAWS Batch でオーケストレートするイベン トドリブンな機械学習基盤 Serverless Conf 2017 11/03 2017 山田 雄 ネットビジネス本部 データ基盤チーム 堤 崇行 ITサービス?ペイメント事業本部 方式基盤技術部
- 2. ■山田 雄（ヤマダ ユウ） 株式会社 リクルートライフスタイル ネットビジネス本部 データ基盤T Twitter:@nii_yan GitHub:https://github.com/yu-yamada ?以前はメールマーケティング用基盤の作成からデータ分析まで関わる 現在はリクルートライフスタイルの共通分析基盤の開発、運用全般を担当 ビックデータ、Ruby、ビール、カップ焼きそばが好き。 自己紹介
- 3. 会社绍介
- 7. 商品概要
- 9. 商品概要 ? 会社が商品として売り出すものである ? 今後長く使われる可能性がある ? 今后机能が追加になる可能性がある
- 10. 机械学习基盘に求められるもの
- 11. Scalability
- 12. Availability
- 13. Maintenability
- 14. Robustness
- 16. Machine learning pipelines on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
- 17. Limited interface on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
- 18. Full managed work flow on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
- 19. Scalable batch on-premises on-premises State control Cloud trail Cloud watch Monitoring Data load Machine learning
- 20. Data load Machine learning Visualize on-premises on-premises Cloud trail Cloud watch Monitoring State control
- 21. State control Data load Machine learning Infrastructure as code on-premises on-premises Cloud trail Cloud watch Monitoring
- 22. State control Data load Machine learning Monitoring on-premises on-premises Cloud trail Cloud watch Monitoring
- 23. ? 2017 NTT DATA Corporation 23 堤 崇行（ツツミ タカユキ） 株式会社ＮＴＴデータ ITサービス?ペイメント事業本部 方式基盤統括部 経歴 ? Webアプリ開発 ? データ基盤開発?運用 / バッチ開発 ? ETL / バッチ処理フレームワーク ? ストリーム処理 利用者/運用者/開発者みんなが気持ちよく使える システムを構築できるよう日々奮闘中 好きなものはチョコレートとビール 自己紹介
- 24. Machine Learning Pipeline on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
- 27. Scheduler or Triggers Scheduled Task Polling Event Trigger
- 28. Interface
- 30. Processing
- 31. Batch Processing with Container Batch On Demand Scalable AWS Batch
- 32. AWS Batch Submit Job Running Succeeded / Failed JobのCPU数 / メモリを指定 Job Containerが稼動 終了 “最適な”EC2 Instanceが起動Runnable
- 33. JobのCPU数 / メモリを指定 “最適な”EC2 Instanceが起動 Job CPU数 メモリ EC2 CPU数 メモリ CPU: 8 メモリ: 24GiB Type: m4.2xlarge CPU: 8 メモリ: 32GiB CPU: 8 メモリ: 500GiB Type: r4.16xlarge? CPU: 64 メモリ: 488GiB
- 36. AWS Step Functions & Batch State Machine Submit Get Status Loop
- 38. Micro State Machine Pre- processing (Data Load) Processing (Machine Learning)
- 39. Relay Step Functions Batch Results BatchStep Functions BatchStep Functions
- 40. Event Driven with Lambda ExecutionTrigger S3 Eventで Lambdaを実行 起動成功 起動失敗 多重起動
- 41. Event Driven with Lambda Failures & Solutions SolutionsFailuresTrigger S3 Eventで Lambdaを実行 起動失敗 再実行 多重起動 多重起動の阻止 多重起動OK
- 42. Retry when Execution Failed Polling DLQ DLQによる確実なLambdaの実行 Cloud Watch Events Event
- 43. Preventing Multiple Starts DynamoDBでステート管理 Conditional Put Item Update Item Batch Status State Control DB Start Execution DON’T Start CAN’T Put
- 44. Support Idempotent Batch べき等性のあるBatch Jobを実装 多重起動しても正常を保つ Upsert Unique Object name Get Latest Object
- 45. Monitoring
- 46. Monitoring: Alerts Cloud Watch Logs Log監視 Lambdaをフィルタで振分け ERRORログを検知 Subscription Filter Info Alert
- 47. Monitoring: Alerts Batch Status監視 長時間Runnableを検知 Submit Running Succeeded / Failed Job Containerが稼動 “最適な” EC2 Instanceが起動Runnable
- 48. Monitoring: Alerts Step Functionの起動監視 一定の時間以上起動していないを検知 BatchStep FunctionsLambdaS3Data
- 49. Monitoring: Visualize Batch Status DynamoDB Streams ES
- 50. Machine Learning Pipeline Cloud trail Cloud watch Monitoring BatchStep Functions S3 LambdaObjects DynamoDB
- 51. Monitoring Machine Learning Pipeline on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch
- 52. 最后に
Editor's Notes
- #2: 音声を外部出力にするの忘れない
- #5: 生まれる前から棺桶までのデータを持っている 今回はこの中でじゃらんの商品についての話です
- #6: 運用に８０％も割いているのは幸せな状況ではない 開発にもっと割きたい 例えばgoogleは運用は50%までと制限を入れているらしい
- #7: 理想は開発７ 運用２ その他１ ぐらいかな そんな考えがありながら基盤の設計をしました
- #9: 返答はリアルタイムだが、学習はバッチで日次処理で行っている Webページ上でチャットを行う
- #10: 来春リリース予定 12月から一部の宿で開始予定 じゃらんの全宿が使っても耐えられる設計である
- #11: 商品概要のところと纽付けて话せると良い
- #12: Scalability データ量がどれだけ増えるかわからない。 スパイクするかもしれない。 単純にスケール出来る基盤というだけでなく、オートスケール出来る基盤が理想。
- #13: Availability 可用性 継続性 SPOFを作ってはいけない サーバを立てなければいい 再実行の自動化 エラーの検知だけではなく再実行まで行う
- #14: Maintenability 運用コストがかからないこと Infrastructure as code. ログの自動収集
- #15: robustness セキュリティ的に安全である 保守性 変化に強い 機能追加
- #16: Low cost もちろんコストは出来るだけ抑えたい 基盤のコストだけではなく、運用コストも
- #17: 脳みその日次バッチの部分ですよを冒頭に 前述のscalability,availability,maitenability,robustness,costを考えこのような構成にしました。 メインのバッチは２つあります。 まずはETL部分のバッチそして機械学習のバッチです。 それぞれAWS Batchを使用しています。
- #18: オンプレとのインターフェースをs3に限定することで、セキュリティの担保を行いやすくしています。 クレデンシャルの発行もここのみに限定している もちろんIP制限も行っている
- #19: バケットにオブジェクトを置かれた際にevent drivenでlambdaを呼び出し、そこからstep functionsを起動しています。 ワークフローエンジンを使わずにEvent drivenにすることにより、運用コストを下げています。 ワークフローエンジンを使うと、再実行などの手動運用が必要になってくる。 フルマネージド使うことで。ワークフローエンジンのSPOFなども気にせずにすむ。
- #20: AWS Batchを使用することにより、スケールに耐えられつつ、コストを抑えられる構成になってます
- #21: Event drivenの基盤を作った際にはどの処理がどこまで動いているのかが追いにくくなります。 そこで、stateをdynamo入れ、elastic->kibanaに連携することで今現在どの状態にいるのかを可視化しています。
- #22: Infrastructure
- #23: 動かなかったことの検知をしないといけない 次にそれぞれの部分を細かく見ていきたいと思います
- #25: 紹介されたアーキテクチャ 一度抽象化
- #26: パイプラインの要素 Scheduler or Triggers Scheduled Task Polling Event Trigger 等 詳細ではProcessingについて掘り下げる Interface Input / Output Processing Batch処理 プリプロセス DBへのロード ML
- #28: Scheduled Task Polling Event Trigger 単品でみると複雑になるが 可能であれば入力データを受取次第、稼働し、リソースも最低限ですむイベントトリガーを選ぶと ローコスト＆スケーラブル
- #30: 外の世界と触れる部分 セキュリティ面は前述の通り 分析系バッチは得てしてSLAは外の方が高い 可用性の高いものをIFにすることで障害波及の分離もできる
- #32: バッチを何で動かすか 常駐サービスではなくバッチなのでオンデマンドがよい スケーラブル 処理が動いていない時間は節約し、パワーが必要な時はスケールする コンテナを動かせる → AWS Batch
- #33: AWS Batchの概要 AWS Batch JobにはCPUとメモリを設定 事前/Submit時 最適なインスタンス Job動く 終わり
- #34: AWS Batchや使う上での注意点 JobにはCPUとメモリを設定 １コンテナは１インスタンス →ジョブの指定リソースより大きいスペックのインスタンスが起動しないといけない。 受け止められるインスタンスタイプが起動できる設定になっていないとRunnableで停止 結果、Batchを使うにあたり、EC2インスタンスタイプのスペックに詳しくなった。
- #35: BatchのSubmitとSubmitから終了までのステータス管理する必要がある。 Workflowの部分を何でやるか。 イベントドリブンで マネージドで スケールする → Step Functions 余談：いつのまにかBatch処理のポーリングをするステートマシンがBlueprintにも追加された
- #36: イベントトリガーにするには InterfaceであるS3へのデータ配置からLambdaが実行され Step Functionsが実行される 次：Step Functions + Batch構成
- #37: Step Functions（ステートマシン） LambdaからBatchをSubmit Lambdaでステータスを取得 終了ステータスになるまで繰り返し
- #38: １つのステートマシンの粒度はどうするか問題 バッチ２つのあとに１つのバッチがある例 複数のバッチ処理があるが１つのステートマシンにするべきか、分けるとしたらどれくらいで分けるのか １つだとWorkflow全体が１つのステートマシンになり 全体をみたい時はわかりやすい
- #39: 機能追加には対応しやすくしたい Don't repeat yourselfでいたい → ロード(Pre-processing)とML(Processing)で分けた ロードを共通化することでDRYを保つ MLのInputが複雑になっても対応できる 次、StepfunctionsからStepfunctionsへの連携はどうするか
- #40: StepfunctionsからStepfunctionsへの連携はどうするか Batchの結果をS3にPutして次のStep Functionsがイベントドリブンで動き出す
- #41: 現状S3のイベントトリガーでLambdaを実行する時 成功だけじゃなく重複も失敗もある
- #42: 可用性を高めるため 再実行の強化 多重起動を防止 多重起動しても問題ないようにする
- #43: DLQによる確実なlambdaの実行 イベントドリブンだけだと失敗を拾えないので ポーリングモデルで再実行もしている
- #44: 多重起動させない 同じS3 Pathからは実行されないように S3パスをキーとして重複の検知 バッチの状態から実行可否を判定可 Batch Statusの記録もできる →後述の可視化へ DynamoDBを選んだ理由 S3パスを重複キーとして使えるKVS バッチの状態を見て実行するか否かを判定できる 今は同じパスのアイテムがあるかどうかだけ ステートの記録もできる →後述の可視化へ
- #45: 今回のパターン RedshiftへのロードはUpsert （構成による→） 出力ファイルにも一意性を持たせて上書きしない 受け取る側は最新のオブジェクトを取得
- #47: アラート ログ監視 CloudWatchとLambdaサブスクリプションフィルタ ERRORを検知 特定INFOをSlackに送ることもしている
- #48: Rannableの監視 AWS Batchを使う場合とても大事
- #49: そもそも尝补尘产诲补が起动しなかった时
- #50: Batchの状態可視化 今どのステートにいるのか＆履歴がわかりにくい DynamoDB StreamsとElasticsearch Serviceで可視化 すべて横軸は時間 上がStep Functionsの実行毎 下３つはBatchのステータス Runnable→Running→Success
- #51: 後半のストーリー順に見る Batch on Container → AWS Batch Batchのworkflow → Step Functions イベントドリブン → S3イベントからLambdaが起動してStep Functionsをキック Step FunctionsからStepfunctionへは結果をS3にPutして次のイベントへ 起動失敗や多重起動の対応はDynamoDB 監視もCloudWatchとDatadogでサーバーレスに BatchのステータスはKibanaで可視化
- #52: そしてパイプラインが完成
- #55: サーバレスって正常系だけ作ると簡単だけど、異常系も考えて作ると開発が結構大変です。 ラムダも非常に多くなります。 なので、サーバレスで作る際は構成管理やモニタリングを最初から考えないと辛いかなと思います。 でもサーバレスの開発は楽しいです。 インフラレイヤーを意識せずにアプリ開発に集中できます。 運用工数も開発工数に回すことが出来ます。 開発工数かかるけど、運用するより楽しいかなと。