バッチシステムをクラウドネイティブにするために考えたこと

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© DMM 今日話すこと • クラウドネイティブ時代のバッチシステム設計時に重要な視点 • VMベースのバッチシステムをECS Fargate + Step Functions に移行させた事例 • 本セッションで扱う”バッチシステム” • 従来はLinuxのcronで動かしていたような比較的小規模なバッチジョブを対象 • データサイエンス、機械学習、HPCといった領域の大規模なバッチジョブシステムは対象外 8

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© DMM 10 クラウドネイティブクラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 CNCF Cloud Native Definition v1.0 (2018)

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© DMM 14 視点3 実行ロギング・ステータスの通知が可能か ● ジョブ実行履歴のログを残せる ○ ジョブが終わった後何も残らない場合、デバッグが困難になる ● アプリケーションのログを外部に送信できる ○ 古いcronではログを/dev/nullに捨てがち... ● ジョブ実行のステータスを外部に通知できる ○ 成功率・実行時間を収集できる ○ 通知をトリガーにして、リトライなどが実行できる可観測性

Slide 15

Slide 15 text

© DMM 15 視点4 バッチ実行基盤の運用効率が良いか ● バッチ実行基盤として何を使うか？ ○ マネージド・サーバーレスなクラウドサービスを組み合わせる ■ ほぼ管理作業が発生しない ○ ジョブ管理システムの導入 ■ 例: jenkins, Rundeckなど ■ バージョンアップ作業、ユーザ管理作業などが発生する ■ OSSのものはコードを調査できる、議論に参加できる ● 組織によって最も効率の良いものを選ぶ管理性

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© DMM 背景 19 • システム全体をクラウドネイティブに刷新するプロジェクトが始動 • 先行してWebサーバのインフラが ECS Fargateに変更 • バッチに関してはEC2を脱却することで以下の課題の解決を目指した • 耐障害性がない • エラー発生を検出できない • 全てのジョブプロセスが同居するのでリソースを奪い合う • crontabファイルの編集によるスケジュール設定変更が常態化 Aurora Aurora

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© DMM 23 ECS Scheduled Task + EventBridge + Kinesis Data Firehose ✅ ジョブは互いに影響を及ぼさない ✅ マネージドかつサーバレスな実行基盤 ✅ 構成がシンプル ✅ 実行ログをEventBridgeとFirehose 経由で保存できる（ECS単体では一定時間で消滅してしまう） ❌ 単体での自動/手動リトライは不可能シンプルな構成で、cron on EC2脱却の1歩目に適すると判断自動リトライなどはこの時点では不要だと考えていた（後述）視点3: 実行ロギング・ステータスの通知が可能か

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© DMM バッチジョブが稀に実行されない • ECS Fargateのタスク起動時にプロビジョニングエラーが発生 • サポートに問い合わせた結果、どうしても低確率で発生するもの • 自動的なリトライが必要 26 ● Timeout waiting for network interface provisioning to complete ● ResourceInitializationError: failed to configure ENI: failed to setup regular eni: context deadline exceeded ● ResourceInitializationError: failed to configure ENI: failed to setup regular eni: netplugin failed with no error message ECSタスクのStoppedReasonとしてよく見るもの視点2: 自動・手動のリトライが容易か

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© DMM EventBridgeがターゲットを複数回呼び出す • EventBridgeは稀にターゲット（ECSタスク）を複数回呼び出すことがある（docsに記載あり） • 重複呼び出しされると不具合に繋がるジョブが少数ながら存在していた • 歴史的な背景からアプリケーションレベルでの冪等性は備わっていなかった • バッチシステム側で重複起動されないような仕組みが欲しい 28 Amazon EventBridge Rule 通常時 Amazon EventBridge Rule 複数回呼出時（稀）

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© DMM Rule Amazon EventBridge AWS Lambda 改善実装 v2 31 AWS Step Functions RunTask: ECSタスクを同期実行失敗時はParseCauseへ ParseCause: タスクの終了原因をJSON へパース ErrorChoice: 終了原因が指定した理由にマッチする場合はRunTaskへ遷移 "Choices": [ { "Next": "RunTask", "Or": [ { "StringMatches": "Timeout waiting for network interface provisioning to complete*", "Variable": "$.ParsedCause.StoppedReason" }, { "StringMatches": "ResourceInitializationError: failed to configure ENI: failed to setup regular eni: context deadline exceeded", "Variable": "$.ParsedCause.StoppedReason" }, { "StringMatches": "ResourceInitializationError: failed to configure ENI: failed to setup regular eni: netplugin failed with no error message", "Variable": "$.ParsedCause.StoppedReason" } ] } ], … ]

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© DMM Step Functionsに移行して • タスク実行失敗、重複起動リスクは回避 • AWSコンソールで実行履歴が見やすい、手動によるリトライが簡単といった副次的メリットも生まれた 34 • 余談 • AWS Batchは検討しなかったのか? • SFNのような冪等応答の機能がない • 重複起動の件はDynamoDBなどで排他制御することでも解決できそうか？ • ジョブが1分以内で完了した場合、1個目のタスク終了後に2個目のタスクが起動することがある模様... • cf. https://qiita.com/aosho235/items/87cc5f6104392f5fcdc6