[アップデート]ゼロキャパシティからのバッチ処理に最適!AWS Batch で AWS Fargate が利用可能になりました! #reinvent
本日のアップデートで AWS Batch で AWS Fargate の利用が可能になりました!
AWS Batch for AWS Fargate
AWS Batch はジョブをキューイングすると、定義された内容に従い自動的にコンピューティングリソースを起動し、計算処理を実行するバッチコンピューティングのサービスです。バックグラウンドでは Amazon ECS が動いているのですが、ユーザーは ECS を意識することがないようにラッピングされています。
従来はいわゆる ECS on EC2 がサポートされていましたので、ラッピングされてるとはいえ EC2 ホストの存在は少なからずとも意識する必要がありました。加えてゼロキャパシティからスケールする際は、キューイングしてから処理が実行されるまでの時間はそれなりに待たされるので、ショートサイクルなバッチジョブでは最小 vCPU 数を指定し、インスタンスを待機させている環境が多いと思います。
ゼロキャパシティからのスケール
今回のアップデートで AWS Fargate/AWS Fargate Spot が利用可能となりユーザーは、よりサーバーレスな環境でバッチコンピューティングが可能となりました。ゼロキャパシティからのキューイングも非常にスムーズに処理が開始されるので、ショートサイクルなバッチジョブにおいても無駄な待機コストを削減できることでしょう!
対応リージョン
AWS Fargate および AWS Batch が提供されているすべてのリージョンで利用可能です!
価格
AWS Batch そのものに課金は発生しません。AWS Batch により起動される EC2、Fargate に対して通常の起動料金が発生します。
制限事項
- ジョブキュー内で EC2 と Fargate のコンピューティング環境を混在することは出来ません
- その他、一般的な Fargate の制限をご確認ください(GPU 非対応など)
やってみる
今回の検証環境は東京リージョンを利用しています。コンテナイメージなどは、こちらの公式ガイドの配列ジョブ環境でのチュートリアルを参考に事前作成しています。
コンピューティング環境の作成
AWS Batch 管理コンソールを開き、[コンピューティング環境] - [作成] を開きます。コンピューティング環境設定では マネージド型
を選択し、任意のコンピューティング環境名を入力します。その他はデフォルトのまま進みます。(インスタンスロール、EC2 キーペアは後続の選択で表示されなくなりますので指定不要です)
インスタンスの設定メニューに Fargate
、Fargate Spot
が追加されていますのでいずれかを選択し、最大の vCPU 数を入力します。今回は Fargate Spot
を使ってみましょう。
ちなみに Fargate Spot は re:Invent 2019 で発表されましたね。最大 70% OFF で Fargate が利用できます。同スペックの EC2 に比べると Fargate の時間あたりの単価は割高になりますので、個人的には Spot をうまく利用されることをオススメします。
ちなみに EC2 の場合、最小 vCPU を指定することで常時待機しておく vCPU 数を指定できるのですが、Fargate の場合は最大 vCPU のみです。つまり、ゼロキャパシティからのスケールが前提となるようですね。
ネットワーキングの設定で Fargate を起動する VPC、サブネットおよびアタッチするセキュリティグループを指定し、最後に コンピューティング環境の作成
をクリックします。
今回はパブリックサブネットを使用していますが、プライベートサブネットをご利用の場合はコンテナイメージが取得できるように NAT ゲートウェイまたは ECR であれば VPC エンドポイントが必要となります。
ジョブキューの作成
AWS Batch 管理コンソールに戻り、[ジョブキュー] - [作成] を開きます。任意のジョブキュー名を入力します。
コンピューティング環境を選択の欄から、先程作成した Fargate のコンピューティング環境を指定います。冒頭、お伝えしたとおり EC2 と Fargate のコンピューティング環境を混在することは出来ません。
ジョブ定義の作成
AWS Batch 管理コンソールに戻り、[ジョブ定義] - [作成] を開きます。任意のジョブ定義名を入力し、プラットフォームでは新たに追加されている Fargate
を選択します。ここでは再試行戦略なども指定できますが、今回はデフォルトのまま進みます。
コンテナのプロパティでコンテナイメージを指定します。今回は事前に準備していた ECR からイメージを取得しています。
コンテナに割当てる vCPU、メモリ、タスクの実行ロールを指定します。今回はパブリックサブネットを選択していたので EIP の割り当てにチェックします。プライベートサブネットの場合、NAT ゲートウェイや適切な VPC エンドポイントが設定されている必要があります。
その他の設定では、ボリューム、マウントポイント、環境変数、シークレット、ログドライバーなどなど、コンテナの詳細なパラメータ指定が可能ですが、今回はデフォルトのまま進み 作成
します。
ジョブをキューイングしてみる
今回は AWS CLI から入力用の JSON ファイル print-color-job.json
を渡してジョブを実行します。print-color-job.json
では先程作成した、ジョブキュー名、ジョブ定義を指定しています。また、今回は配列ジョブを使用しますので、arrayProperties
を指定しています。
{ "jobName": "print-color", "jobQueue": "first-run-job-queue", "arrayProperties": { "size": 7 }, "jobDefinition": "print-color" }
以下のコマンドでジョブをキューイングします。
$ aws batch submit-job --cli-input-json file://print-color-job.json jobId: e8ecb35e-b45c-4eb2-a7fc-754f77dbe433 jobName: print-color
ジョブをキューイングすると直ぐに Fargate でコンテナがデプロイされて動いてますね! EC2 の場合、ゼロキャパシティでジョブをキューイングすると AMI から EC2 を起動するところで、それなりに待たされるのですがさすが Fargate ですね。はやい!
今回は配列ジョブで実行しましたので、7つの Fargate コンテナが起動して実行されていますね。
CloudWatch ログもしっかりログが出力されているので、正常に処理されていることがわかります。
すべてのジョブが実行完了すると、Fargate はゼロキャパシティに戻っています。経済的です。
検証は以上です!
さいごに
ついに来ましたね AWS Batch での Fargate 対応!
EC2 の場合、どうしてもゼロキャパシティだとインスタンス起動に時間が掛かりますので、ショートサイクルのバッチジョブを考えると常時幾つかの vCPU は待機させておきたいと思いますが、コスト最適の面で考えると待機は無駄なコストになってしまいます。
Fargate の場合、ゼロキャパシティが基本となっているようですが、ジョブキューイングから処理の開始まで本当に速いですね!もちろんイメージサイズで変わってきますが、それでも EC2 のゼロキャパシティより断然速い。
Fargate では GPU が使えないなどの制約がありますが、そういった Fargate の制限に掛からないのであればとても良い選択だと思います。常時ジョブがキューイングされてくるような環境であれば、Fargate のほうが割高になる可能性が出てきますので、その場合は EC2/EC2 スポットのほうが良いかもしれません。このあたりはジョブの特性に応じてうまく使い分けていただく必要があるかと思います!
まずは是非、一度お試しください!
以上!大阪オフィスの丸毛(@marumo1981)でした!