Successfully reported this slideshow.
Your SlideShare is downloading. ×

Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤

Ad

Step FunctionsとAWS Batch
でオーケストレートするイベン
トドリブンな機械学習基盤
Serverless Conf 2017
11/03 2017
山田 雄
ネットビジネス本部
データ基盤チーム
堤 崇行
ITサービス・ペ...

Ad

■山田 雄(ヤマダ ユウ)
株式会社 リクルートライフスタイル
ネットビジネス本部
データ基盤T
Twitter:@nii_yan
GitHub:https://github.com/yu-yamada
・以前はメールマーケティング用基盤の作成...

Ad

会社紹介

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Check these out next

1 of 54 Ad
1 of 54 Ad

Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤

Download to read offline

リクルートライフスタイルでは機械学習を用いたサービスの展開もしています。サービスが増え続ける中で素早く市場に対応するためには、いかに簡単に基盤を作り、運用を減らせていくかが重要になってきます。

上記の課題を踏まえパワーが必要な機械学習処理のためのサーバレス基盤を構築しました。
なぜserverlessを選択したのか?
構築にあたり使用したStep FunctionsやAWS Batchの注意点と共に機械学習基盤を紹介します。
山田 雄(株式会社リクルートライフスタイル)

リクルートライフスタイルでは機械学習を用いたサービスの展開もしています。サービスが増え続ける中で素早く市場に対応するためには、いかに簡単に基盤を作り、運用を減らせていくかが重要になってきます。

上記の課題を踏まえパワーが必要な機械学習処理のためのサーバレス基盤を構築しました。
なぜserverlessを選択したのか?
構築にあたり使用したStep FunctionsやAWS Batchの注意点と共に機械学習基盤を紹介します。
山田 雄(株式会社リクルートライフスタイル)

Advertisement
Advertisement

More Related Content

Slideshows for you (19)

Advertisement

Similar to Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤 (20)

Advertisement

Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤

  1. 1. Step FunctionsとAWS Batch でオーケストレートするイベン トドリブンな機械学習基盤 Serverless Conf 2017 11/03 2017 山田 雄 ネットビジネス本部 データ基盤チーム 堤 崇行 ITサービス・ペイメント事業本部 方式基盤技術部
  2. 2. ■山田 雄(ヤマダ ユウ) 株式会社 リクルートライフスタイル ネットビジネス本部 データ基盤T Twitter:@nii_yan GitHub:https://github.com/yu-yamada ・以前はメールマーケティング用基盤の作成からデータ分析まで関わる 現在はリクルートライフスタイルの共通分析基盤の開発、運用全般を担当 ビックデータ、Ruby、ビール、カップ焼きそばが好き。 自己紹介
  3. 3. 会社紹介
  4. 4. リクルートライフスタイルの持つサービス
  5. 5. 80% 基盤エンジニアが運用に割いている割合
  6. 6. 開発: 運用: その他: 理想の割合 70% 20% 10%
  7. 7. 商品概要
  8. 8. トリップAIコンシェルジュ システム概要図
  9. 9. 商品概要 • 会社が商品として売り出すものである • 今後長く使われる可能性がある • 今後機能が追加になる可能性がある
  10. 10. 機械学習基盤に求められるもの
  11. 11. Scalability
  12. 12. Availability
  13. 13. Maintenability
  14. 14. Robustness
  15. 15. Machine learning pipelines on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
  16. 16. Limited interface on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
  17. 17. Full managed work flow on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
  18. 18. Scalable batch on-premises on-premises State control Cloud trail Cloud watch Monitoring Data load Machine learning
  19. 19. Data load Machine learning Visualize on-premises on-premises Cloud trail Cloud watch Monitoring State control
  20. 20. State control Data load Machine learning Infrastructure as code on-premises on-premises Cloud trail Cloud watch Monitoring
  21. 21. State control Data load Machine learning Monitoring on-premises on-premises Cloud trail Cloud watch Monitoring
  22. 22. © 2017 NTT DATA Corporation 23 堤 崇行(ツツミ タカユキ) 株式会社NTTデータ ITサービス・ペイメント事業本部 方式基盤統括部 経歴 • Webアプリ開発 • データ基盤開発・運用 / バッチ開発 • ETL / バッチ処理フレームワーク • ストリーム処理 利用者/運用者/開発者みんなが気持ちよく使える システムを構築できるよう日々奮闘中 好きなものはチョコレートとビール 自己紹介
  23. 23. Machine Learning Pipeline on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch Monitoring
  24. 24. Components of Pipelines Interface
  25. 25. Scheduler Triggers
  26. 26. Scheduler or Triggers Scheduled Task Polling Event Trigger
  27. 27. Interface
  28. 28. Interface Interface Processing Interface
  29. 29. Processing
  30. 30. Batch Processing with Container Batch On Demand Scalable AWS Batch
  31. 31. AWS Batch Submit Job Running Succeeded / Failed JobのCPU数 / メモリを指定 Job Containerが稼動 終了 “最適な”EC2 Instanceが起動Runnable
  32. 32. 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
  33. 33. Step Functions Workflow Scalable Managed Event Driven Control AWS Batch
  34. 34. Event Driven BatchStep FunctionsLambdaS3 Data
  35. 35. AWS Step Functions & Batch State Machine Submit Get Status Loop
  36. 36. Monolithic or Micro?
  37. 37. Micro State Machine Pre- processing (Data Load) Processing (Machine Learning)
  38. 38. Relay Step Functions Batch Results BatchStep Functions BatchStep Functions
  39. 39. Event Driven with Lambda ExecutionTrigger S3 Eventで Lambdaを実行 起動成功 起動失敗 多重起動
  40. 40. Event Driven with Lambda Failures & Solutions SolutionsFailuresTrigger S3 Eventで Lambdaを実行 起動失敗 再実行 多重起動 多重起動の阻止 多重起動OK
  41. 41. Retry when Execution Failed Polling DLQ DLQによる確実なLambdaの実行 Cloud Watch Events Event
  42. 42. Preventing Multiple Starts DynamoDBでステート管理 Conditional Put Item Update Item Batch Status State Control DB Start Execution DON’T Start CAN’T Put
  43. 43. Support Idempotent Batch べき等性のあるBatch Jobを実装 多重起動しても正常を保つ Upsert Unique Object name Get Latest Object
  44. 44. Monitoring
  45. 45. Monitoring: Alerts Cloud Watch Logs Log監視 Lambdaをフィルタで振分け ERRORログを検知 Subscription Filter Info Alert
  46. 46. Monitoring: Alerts Batch Status監視 長時間Runnableを検知 Submit Running Succeeded / Failed Job Containerが稼動 “最適な” EC2 Instanceが起動Runnable
  47. 47. Monitoring: Alerts Step Functionの起動監視 一定の時間以上起動していないを検知 BatchStep FunctionsLambdaS3Data
  48. 48. Monitoring: Visualize Batch Status DynamoDB Streams ES
  49. 49. Machine Learning Pipeline Cloud trail Cloud watch Monitoring BatchStep Functions S3 LambdaObjects DynamoDB
  50. 50. Monitoring Machine Learning Pipeline on-premises Data load Machine learning on-premises State control Cloud trail Cloud watch
  51. 51. 最後に
  52. 52. 一緒に基盤作ってくれる人募集中!!! http://engineer.recruit-lifestyle.co.jp/recruiting/
  53. 53. Happy serverless development!!

Editor's Notes

  • 音声を外部出力にするの忘れない
  • 生まれる前から棺桶までのデータを持っている

    今回はこの中でじゃらんの商品についての話です
  • 運用に80%も割いているのは幸せな状況ではない
    開発にもっと割きたい

    例えばgoogleは運用は50%までと制限を入れているらしい
  • 理想は開発7 運用2 その他1 ぐらいかな

    そんな考えがありながら基盤の設計をしました
  • 返答はリアルタイムだが、学習はバッチで日次処理で行っている

    Webページ上でチャットを行う
  • 来春リリース予定
    12月から一部の宿で開始予定

    じゃらんの全宿が使っても耐えられる設計である


  • 商品概要のところと紐付けて話せると良い

  • Scalability


    データ量がどれだけ増えるかわからない。
    スパイクするかもしれない。

    単純にスケール出来る基盤というだけでなく、オートスケール出来る基盤が理想。

  • Availability

    可用性

    継続性
    SPOFを作ってはいけない
    サーバを立てなければいい
    再実行の自動化
    エラーの検知だけではなく再実行まで行う
  • Maintenability

    運用コストがかからないこと
    Infrastructure as code.
    ログの自動収集
  • robustness


    セキュリティ的に安全である
    保守性
    変化に強い 
    機能追加
  • Low cost

    もちろんコストは出来るだけ抑えたい
    基盤のコストだけではなく、運用コストも
  • 脳みその日次バッチの部分ですよを冒頭に
    前述のscalability,availability,maitenability,robustness,costを考えこのような構成にしました。

    メインのバッチは2つあります。
    まずはETL部分のバッチそして機械学習のバッチです。

    それぞれAWS Batchを使用しています。

  • オンプレとのインターフェースをs3に限定することで、セキュリティの担保を行いやすくしています。

    クレデンシャルの発行もここのみに限定している

    もちろんIP制限も行っている
  • バケットにオブジェクトを置かれた際にevent drivenでlambdaを呼び出し、そこからstep functionsを起動しています。
    ワークフローエンジンを使わずにEvent drivenにすることにより、運用コストを下げています。

    ワークフローエンジンを使うと、再実行などの手動運用が必要になってくる。
    フルマネージド使うことで。ワークフローエンジンのSPOFなども気にせずにすむ。
  • AWS Batchを使用することにより、スケールに耐えられつつ、コストを抑えられる構成になってます

  • Event drivenの基盤を作った際にはどの処理がどこまで動いているのかが追いにくくなります。
    そこで、stateをdynamo入れ、elastic->kibanaに連携することで今現在どの状態にいるのかを可視化しています。
  • Infrastructure
  • 動かなかったことの検知をしないといけない

    次にそれぞれの部分を細かく見ていきたいと思います

  • 紹介されたアーキテクチャ
    一度抽象化
  • パイプラインの要素
    Scheduler or Triggers
    Scheduled Task
    Polling
    Event Trigger


    詳細ではProcessingについて掘り下げる

    Interface
    Input / Output

    Processing
    Batch処理
    プリプロセス
    DBへのロード
    ML
  • Scheduled Task
    Polling
    Event Trigger
    単品でみると複雑になるが
    可能であれば入力データを受取次第、稼働し、リソースも最低限ですむイベントトリガーを選ぶと
    ローコスト&スケーラブル
  • 外の世界と触れる部分
    セキュリティ面は前述の通り
    分析系バッチは得てしてSLAは外の方が高い
    可用性の高いものをIFにすることで障害波及の分離もできる
  • バッチを何で動かすか 常駐サービスではなくバッチなのでオンデマンドがよい
    スケーラブル
    処理が動いていない時間は節約し、パワーが必要な時はスケールする
    コンテナを動かせる
    → AWS Batch
  • AWS Batchの概要
    AWS Batch JobにはCPUとメモリを設定
    事前/Submit時
    最適なインスタンス
    Job動く
    終わり
  • AWS Batchや使う上での注意点
    JobにはCPUとメモリを設定
    1コンテナは1インスタンス
    →ジョブの指定リソースより大きいスペックのインスタンスが起動しないといけない。
    受け止められるインスタンスタイプが起動できる設定になっていないとRunnableで停止
    結果、Batchを使うにあたり、EC2インスタンスタイプのスペックに詳しくなった。
  • BatchのSubmitとSubmitから終了までのステータス管理する必要がある。
    Workflowの部分を何でやるか。

    イベントドリブンで
    マネージドで スケールする
    → Step Functions

    余談:いつのまにかBatch処理のポーリングをするステートマシンがBlueprintにも追加された
  • イベントトリガーにするには
    InterfaceであるS3へのデータ配置からLambdaが実行され
    Step Functionsが実行される
    次:Step Functions + Batch構成
  • Step Functions(ステートマシン)
    LambdaからBatchをSubmit
    Lambdaでステータスを取得
    終了ステータスになるまで繰り返し
  • 1つのステートマシンの粒度はどうするか問題
    バッチ2つのあとに1つのバッチがある例

    複数のバッチ処理があるが1つのステートマシンにするべきか、分けるとしたらどれくらいで分けるのか
    1つだとWorkflow全体が1つのステートマシンになり
    全体をみたい時はわかりやすい
  • 機能追加には対応しやすくしたい
    Don't repeat yourselfでいたい
    → ロード(Pre-processing)とML(Processing)で分けた
    ロードを共通化することでDRYを保つ
    MLのInputが複雑になっても対応できる

    次、StepfunctionsからStepfunctionsへの連携はどうするか
  • StepfunctionsからStepfunctionsへの連携はどうするか
    Batchの結果をS3にPutして次のStep Functionsがイベントドリブンで動き出す
  • 現状S3のイベントトリガーでLambdaを実行する時
    成功だけじゃなく重複も失敗もある
  • 可用性を高めるため
    再実行の強化
    多重起動を防止
    多重起動しても問題ないようにする
  • DLQによる確実なlambdaの実行

    イベントドリブンだけだと失敗を拾えないので
    ポーリングモデルで再実行もしている
  • 多重起動させない
    同じS3 Pathからは実行されないように
    S3パスをキーとして重複の検知
    バッチの状態から実行可否を判定可
    Batch Statusの記録もできる
    →後述の可視化へ

    DynamoDBを選んだ理由
    S3パスを重複キーとして使えるKVS
    バッチの状態を見て実行するか否かを判定できる
    今は同じパスのアイテムがあるかどうかだけ
    ステートの記録もできる
    →後述の可視化へ
  • 今回のパターン
    RedshiftへのロードはUpsert
    (構成による→)
    出力ファイルにも一意性を持たせて上書きしない
    受け取る側は最新のオブジェクトを取得
  • アラート
    ログ監視
    CloudWatchとLambdaサブスクリプションフィルタ
    ERRORを検知
    特定INFOをSlackに送ることもしている
  • Rannableの監視
    AWS Batchを使う場合とても大事
  • そもそもLambdaが起動しなかった時
  • Batchの状態可視化
    今どのステートにいるのか&履歴がわかりにくい
    DynamoDB StreamsとElasticsearch Serviceで可視化
    すべて横軸は時間
    上がStep Functionsの実行毎
    下3つはBatchのステータス
    Runnable→Running→Success
  • 後半のストーリー順に見る
    Batch on Container → AWS Batch
    Batchのworkflow → Step Functions
    イベントドリブン → S3イベントからLambdaが起動してStep Functionsをキック
    Step FunctionsからStepfunctionへは結果をS3にPutして次のイベントへ
    起動失敗や多重起動の対応はDynamoDB
    監視もCloudWatchとDatadogでサーバーレスに
    BatchのステータスはKibanaで可視化
  • そしてパイプラインが完成

  • サーバレスって正常系だけ作ると簡単だけど、異常系も考えて作ると開発が結構大変です。
    ラムダも非常に多くなります。
    なので、サーバレスで作る際は構成管理やモニタリングを最初から考えないと辛いかなと思います。

    でもサーバレスの開発は楽しいです。
    インフラレイヤーを意識せずにアプリ開発に集中できます。
    運用工数も開発工数に回すことが出来ます。
    開発工数かかるけど、運用するより楽しいかなと。


×