Weitere ähnliche Inhalte
Ähnlich wie Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤 (20)
Step functionsとaws batchでオーケストレートするイベントドリブンな機械学習基盤
- 2. ■山田 雄(ヤマダ ユウ)
株式会社 リクルートライフスタイル
ネットビジネス本部
データ基盤T
Twitter:@nii_yan
GitHub:https://github.com/yu-yamada
・以前はメールマーケティング用基盤の作成からデータ分析まで関わる
現在はリクルートライフスタイルの共通分析基盤の開発、運用全般を担当
ビックデータ、Ruby、ビール、カップ焼きそばが好き。
自己紹介
- 18. Full managed work flow
on-premises
Data load
Machine
learning
on-premises
State control
Cloud trail
Cloud watch
Monitoring
- 23. © 2017 NTT DATA Corporation 23
堤 崇行(ツツミ タカユキ)
株式会社NTTデータ
ITサービス・ペイメント事業本部
方式基盤統括部
経歴
• Webアプリ開発
• データ基盤開発・運用 / バッチ開発
• ETL / バッチ処理フレームワーク
• ストリーム処理
利用者/運用者/開発者みんなが気持ちよく使える
システムを構築できるよう日々奮闘中
好きなものはチョコレートとビール
自己紹介
- 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
- 41. Event Driven with Lambda
Failures & Solutions
SolutionsFailuresTrigger
S3 Eventで
Lambdaを実行
起動失敗 再実行
多重起動
多重起動の阻止
多重起動OK
Hinweis der Redaktion
- 音声を外部出力にするの忘れない
- 生まれる前から棺桶までのデータを持っている
今回はこの中でじゃらんの商品についての話です
- 運用に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で可視化
- そしてパイプラインが完成
-
サーバレスって正常系だけ作ると簡単だけど、異常系も考えて作ると開発が結構大変です。
ラムダも非常に多くなります。
なので、サーバレスで作る際は構成管理やモニタリングを最初から考えないと辛いかなと思います。
でもサーバレスの開発は楽しいです。
インフラレイヤーを意識せずにアプリ開発に集中できます。
運用工数も開発工数に回すことが出来ます。
開発工数かかるけど、運用するより楽しいかなと。