AWS再入門ブログリレー AWS Batch編

暑さにも湿気にも弱いので、日本での生活の1/4くらいはパフォーマンスが落ちている気がします。 強く進化したいなと考える今日この頃です。

▲ 大学生協にあった蒲焼きのタレごはんが恋しいです

こんにちは、AWS事業本部のShirotaです。 今日は秘伝のウナギのタレのように読み継ぎたい、AWS再入門ブログを書かせて頂きたいと思います。

当エントリの趣旨

当エントリは弊社コンサルティング部による『 AWS再入門ブログリレー 2019 』の12日目のエントリです。

昨日はしばたによる『 AWS Backup 』でした。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

本日12日目のテーマは『 AWS Batch 』です。

前提

当エントリは、2019年7月17日現在の各サービスの状況を元に作成しております。 また、英語コンソールでの作業時のスクリーンショットを掲載しております。

目次

• AWS Batchとは
• 「バッチ処理」の定義付け
• AWS Batchの構成
• AWS Batchの特徴
• 利用可能・不可能なリージョン
• 利用料金
• AWS Batchの基礎用語
• ジョブ(Jobs)
• ジョブ定義(Job Definitions)
• ジョブキュー(Job Queues)
• コンピューティング環境(Compute Environments)
• 実際にAWS Batchを使う
• AWS Batchのユースケース
• 参考資料
• さいごに

AWS Batchとは

AWS Batchを端的に説明すると、 フルマネージド型のバッチ処理実行サービス です。 より具体的に「フルマネージド型」に関して説明しますと、

• 最適なコンピューティングリソースの動的プロビジョニングが出来る
• 「ジョブ」という概念を定義しておき多岐に渡る処理を管理・実行出来る

と言ったように、インフラストラクチャからバッチソフトウェアまで幅広くAWSが管理してくれます。 結果、バッチを実行する側はAWS Batchを使用する事で、バッチでやりたい事やバッチ実行で得られた結果の分析に注力する事が出来るようになるサービスです。

「バッチ処理」の定義付け

このサービスで出てくる「バッチ処理」について一つ補足します。 バッチ処理とは、以下のような処理の事を指しています。

• 対話処理やリアルタイム処理と逆で、予め定義しておいた一連の動作を実行させるもの

コンピュータのリソースを効率良く使い、作業を実行する際に実行者が張り付く事無く実行する事を可能とする為のものです。 「バッチ処理」の定義としては大きく2種類が考えられます。

• システム管理者が使用するバッチ処理
• システム利用者が使用するバッチ処理

AWS Batchで想定されているバッチ処理は「 システム利用者が使用するバッチ処理 」です。 具体的には、バッチ処理を実行させる為にシステムを利用したい人が「ジョブ」を定義して、任意に投入して実行させる処理を指しています。 具体例でいうと、大量の画像解析を行う処理などが、これに当てはまります。

逆に「システム管理者が使用するバッチ処理」というと、システムを正常に運営する為の業務を行う「システム管理者」が、システムを管理する為の「ジョブ」を定義して実行させる処理を指します。具体例でいうと、夜間にシステムのアップデートを行う処理などが、これに当てはまります。

AWS Batchの構成

AWS Batchの構成は以下のようになっています。

▲ キュー+ECSをラッピングしたようなサービスです

事前に定義したジョブ定義や作成しておいたDockerイメージ等を用いて、実行させたい処理をキューで管理・Auto ScalingするECS環境で分散処理・処理されたデータをアウトプットするまで一気通貫でやってくれます。 ちなみにサービスの歴史としては、

• 2016年12月: re:InventにてAWS Batchが発表される
• 2017年01月: AWS Batchの一般提供(General Availability)開始
• 2017年06月: 東京リージョンでAWS Batchが使用可能に

となっている為、AWS Batchが提供される以前にバッチ処理の構成を考えるとしたらAmazon SQS + EC2(Auto Scaling)といった構成が考えられたかと思います。

AWS Batchの特徴

AWSの公式ページにAWS Batchの特徴が載っていますが、その中からいくつか特徴的なものを抜粋して解説します。 公式ページは以下からどうぞ。

AWS Batchの特徴

フルマネージド型のサービスである

「AWS Batchとは」で説明したように、AWS Batchはジョブを実行する人が実行する内容や実行した結果の解析に注力出来る環境を整える為に主にインフラ面でのフルマネージドを謳っています。

依存関係のあるジョブ実行が可能

後述しますが、AWS Batchは配列ジョブというジョブ定義・コンピュート環境等を共有して複数の子ジョブを実行させる事が出来ます。 これを用いる事で、各子ジョブに依存関係を持たせて処理の制御を行う事が出来ます。

ジョブキューに優先度を持たせ、利用リソースの最適化を図れる

こちらも後述しますが、ジョブキューと言うAWS Batchで利用しているキューに10段階の優先度を持たせることが出来ます。 これを用いて、優先的に実行するジョブを定義したり、ジョブを実行するリソースを無駄なく利用する事が出来ます。

利用可能・不可能なリージョン

AWS Batchは現在殆どのリージョンで利用出来ます。 利用出来ないリージョンは特殊なリージョンのみとなっています。 具体的には、

• AWS GovCloud
• 中国リージョン
• 大阪ローカルリージョン

ではAWS Batchが利用出来ません。

利用料金

AWS Batch自体の利用に料金は発生しません。 AWS Batch利用時に実行されたAWSリソースにのみ料金が発生します 。

先程のAWS Batchの構成図を見ながら、AWS Batchを利用する際最低限利用する事になるサービスを確認して、料金が発生し得るポイントについて考えていきましょう。

▲ 料金が発生する可能性のあるサービスを囲ってみました

Amazon ECR

AWS Batchでは、Dockerイメージの保存で使われています。 ECRの料金は、

• リポジトリに保存するデータ
• インターネットに転送するデータの量

で料金が発生します。 今回の利用例だとリポジトリに保存するデータで料金が発生しそうですが、 AWSアカウント開設から12ヶ月間の無料利用枠 があり、月500MBのストレージが12ヶ月間は無料で利用出来ます。

Amazon ECS

ECSのEC2起動タイプモデルは、アプリケーションの保存や実行のために作成したAWSリソース (EC2インスタンス、EBSボリュームなど) に対してのみ料金が発生します。 また、AWS Batchで起動するEC2インスタンスでは無料枠が存在しているT系インスタンスが選択出来ない為、ここでは 確定で料金が発生してきます 。 ただ、後述しますがスポットインスタンスの使用も選択出来ます。 利用用途に応じてですが、柔軟に料金の最適化が出来るようになっています。

Cloudwatch Logs

ログの取り込みおよびアーカイブに料金が発生します。 ただし、こちらは 常に無料となる無料利用枠 があり、5GBのログデータの取り込みおよび5 GBのログデータのアーカイブに関しては常時無料です。 無料利用枠に収まる範囲での利用が可能なら料金は発生しないでしょう。

ジョブキュー

もし、AWS Batchで利用されているキューがAmazon SQSと同様のサービスであったらと 仮定します。 Amazon SQSはキューの種類およびリクエスト数による従量課金となっております。 ただし、こちらも 常に無料となる無料利用枠 があり、100万リクエスト/月は常時無料です。 こちらもCloudwatch Logsと同じく、無料利用枠に収まる範囲での利用が可能なら料金は発生しないでしょう。

AWS Batchの基礎用語

ここでは、AWS Batchを使用する上で知っておく必要のある基礎用語の概要を纏めていきます。 以下用語は、AWS Batchを利用する際に左カラムで初めて目にする事になるかと思います。

▲ 日本語コンソール/英語コンソールでの左カラム

ジョブ(Jobs)

AWS Batchで実行される作業の単位です。 AWS Batchでは、ECSクラスターのAmazon ECSコンテナインスタンスでコンテナ化されたアプリケーションを実施しています。 その為、ジョブを実行する際には後述説明するものを含め以下の定義をしてあげる必要があります。 様々なオプションがありますが、今回はひとまずジョブ実行に必須な項目について列挙します。

• ジョブ名
• ジョブ定義(後述)
• ジョブキュー(後述)
• ジョブタイプ
• 1つのジョブだけを実行する場合: 単一(Single)
• 共通パラメータ(ジョブ定義・コンピュート環境等)を共有し複数のジョブを実行する場合: 配列(Array)

AWS Batchの利点のところでも少し話しましたが、AWS Batchで扱うジョブを見ると「マルチノードの並列ジョブ」「配列ジョブ」という二種類のジョブの話がよく出てきます。これらについて簡単に解説します。 (ここは複雑で膨大な処理をさせる時に考慮する必要が発生してくるものなので、軽く読み流して頂いて構いません。俗に言う応用コンテンツです)

「マルチノードの並列ジョブ」と「配列ジョブ」

• マルチノードの並列ジョブ: 複数のEC2インスタンスにまたがり(マルチノード)処理する 単一のジョブ
• 配列ジョブ: 並列ジョブを大量に処理するのに有効な、実行時に依存関係が存在している 複数の子ジョブを持つジョブ

ややこしいと思うので、各ジョブのイメージを考えてみました。

• マルチノードの並列ジョブの例: 「1000人分のカレーを作る為の具材を切る」

上記ジョブに関して、EC2インスタンス(マルチノード)を複数の人間として考えると

• Aさんは1000人分のカレーに必要な人参を切る
• Bさんは1000人分のカレーに必要なジャガイモを切る
• Cさんは1000人分のカレーに必要な肉を切る

と言ったジョブが考えられます。 蓋を開ければ、ここで実行されているのは「具材を切る」という単一のジョブであり、それぞれのジョブに依存関係はありません。三人は同時に上記のジョブを実行出来ます。

• 配列ジョブの例: 「1000人分のカレーを作る」

上記ジョブに対して、今度は以下のように考えます。

• ジョブ1: 「Aさんはカレーの具材を切る」
• ジョブ2: 「Aさんはカレーの具材を炒める」

Aさん大忙しです。ここで一つ考慮しないといけない事は、「 カレーの具材を切り終わらないとカレーの具材が炒められない 」事です。 「カレーの具材を切る」「カレーの具材を炒める」これらの子ジョブには インデックス が振られ(上記で言う1,2)、子ジョブ2は子ジョブ1が完了するまで開始できません。 上記のような依存関係を SEQUENTIALタイプの依存関係 と呼びます。

また、以下のように考えてみます。

• ジョブ1: 「Aさんはカレーの具材を切る」
• ジョブ1-a: 人参を切る
• ジョブ1-b: ジャガイモを切る
• ジョブ1-c: 肉を切る

• ジョブ2: 「Bさんはカレーの具材を炒める」

• ジョブ2-a: 人参を炒める
• ジョブ2-b: ジャガイモを炒める
• ジョブ2-c: 肉を炒める

AさんとBさんの目の前に複数まな板やフライパンが用意されています。 Aさんが人参を切ろうがジャガイモを切ろうが、はたまた三種類を同時に切ろうが自由ですしBさんがどれを炒めるかも自由です。 ただし、上記の場合には各ジョブ内のインデックス(上記で言うa,b)に依存関係があります。 Aさんが人参を切り終わらない限り、Bさんは人参を炒められません。 上記のような依存関係を N_TO_Nタイプの依存関係 と呼びます。

因みに、 マルチノードの並列ジョブを配列ジョブにする事は出来ません 。 上記に記載がある通り、マルチノードの並列ジョブは 単一ジョブ である為です。

• Aさんは1000人分のカレーに必要な人参を切る
• Bさんは1000人分のカレーに必要なジャガイモを切る
• Cさんは1000人分のカレーに必要な肉を切る

と

• Aさんは1000人分のカレーに必要な人参を炒める
• Bさんは1000人分のカレーに必要なジャガイモを炒める
• Cさんは1000人分のカレーに必要な肉を炒める

に依存関係を持たせて配列ジョブとして扱う事は出来ないと言うイメージです。

ジョブ定義(Job Definitions)

ジョブの実行方法を定義する、ジョブの雛形となるテンプレートのようなものです。 単一ジョブとマルチノードの並列ジョブではジョブ定義作成のプロセスが若干違います。 各プロセス共に、必須な項目について列挙していきます。

単一ジョブのジョブ定義作成に必要な要素

• ジョブ定義名
• コンテナイメージ(ジョブ実行に使用するDockerイメージ)
• コンテナに渡すコマンド(コマンド形式/JSON形式)
• コンテナ用に用意するvCPUの数
• ジョブのコンテナに適用されるメモリのハード制限

マルチノードの並列ジョブのジョブ定義作成に必要な要素

• ジョブ定義名
• 複数ノード設定が必要なジョブ(要チェック)
• ノード数(デフォルト: 1)
• 主要ノードで使用するノードインデックス(デフォルト: 0)
• 各ノードグループのプロパティ
• (複数ノードグループがある場合)ノードグループの範囲
• コンテナイメージ(ジョブ実行に使用するDockerイメージ)
• コンテナに渡すコマンド(コマンド形式/JSON形式)
• コンテナ用に用意するvCPUの数
• ジョブのコンテナに適用されるメモリのハード制限

ジョブキュー(Job Queues)

クライアントからのジョブをキューイングする場所です。 設定に必要な項目について列挙していきます。

• キューの名前
• (同じコンピューティング環境と紐付いている)ジョブキューの優先度
• ジョブキューの有効化(デフォルト: 有効化)
• コンピューティング環境(後述)

コンピューティング環境(Compute Environments)

ジョブを実行するEC2インスタンス環境の事です。 適切なインスタンス選びや環境のスケーリング等をAWSがマネージメントしてくれる マネージド型 と、自分で設定する アンマネージド型 が存在します。 今回は、AWS Batchの利点を最大限享受出来る マネージド型 の設定に必要な項目について列挙していきます。

• コンピューティング環境名
• サービスロール(新規作成する時は必要ロールが自動作成されるので空欄で可)
• インスタンスロール(新規作成する時は必要ロールが自動作成されるので空欄で可)
• EC2キーペア(SSHを使用してインスタンスに接続したい場合)
• コンピューティング環境の有効化(デフォルト: 有効化/変更不可)
• プロビジョニングモデル
• オンデマンドインスタンス
• スポットインスタンス
• スポットフリートロール(要事前作成)
• インスタンスタイプの指定(デフォルト: optimal)
• コンピューティング環境で維持するEC2 vCPUの最小数(デフォルト: 0)
• コンピューティング環境の起動に必要なEC2 vCPUの数(デフォルト: 0)
• コンピューティング環境でスケールアウトできるEC2 vCPUの最大数(デフォルト: 256)
• EC2インスタンスを起動するVPCのID(デフォルト: デフォルトVPC)
• EC2インスタンスを起動するサブネット(デフォルト: デフォルトVPCの全てのサブネット/最低1つは要指定)
• EC2インスタンスに適用するセキュリティグループ(デフォルト: デフォルトVPCのデフォルトセキュリティグループ)

実際にAWS Batchを使う

各基礎用語の解説も済んだところで、AWS Batchを実際に使う際のフローを纏めてみました。

AWS Batch使用前にセットアップを済ませておく必要があるもの

• Amazon EC2
• Amazon ECS

基礎用語の解説で、各設定に必要な項目について列挙しました。 その際、上記サービスで既に使用しているものを選択する必要のある項目がいくつかありました。(VPCやキーペア、コンテナイメージ等) これらをセットアップしておかないと、必須項目で使用したい選択肢が現れない等でAWS Batchの設定が進められない為、事前の準備が必要となっております。 AWS Batchの為の各サービスセットアップについては、以下公式ドキュメントをご参照下さい。

AWS Batch でのセットアップ

AWS Batch使用時の設定フロー

基本的には、以下フローの順番で設定を進めていきます。

• ジョブ定義を作成
• コンピューティング環境を設定
• ジョブキューを作成
• ジョブを作成
• 作成したジョブを実行

今回は、初めてAWS Batchを使用する際に表示される「Get started」を実行してみたものを纏めました。

Get startedをやってみた

AWS Batchを使用した事が無い状態でサービスのトップにアクセスすると、以下のようなページが表示されます。

▲ 他サービスでもよく見られるチュートリアルページへの入り口

このページ、既にAWS Batchを使用していても以下リンクから飛ぶ事が出来ます。

AWS Batch(東京リージョン)のGet startedページ

今回、すぐにジョブ定義・コンピューティング環境およびジョブキューを作成してジョブを送信したかったので[Using Amazon EC2]を選びました。

▲ デフォルトで選択されている筈です

次に、ジョブ定義を設定する為に4つのセクションの設定をします。

Job run-time

デフォルトで、

• 新規ジョブ定義を作成する
• ジョブ定義名

が設定されています。 [Job role]では、オプションとしてAWS APIを使用する権限をジョブのコンテナに付与するIAMロールを指定する事が出来ます。

▲ 今回は全てデフォルトで進めていきます

Container properties

ここで設定する内容はジョブ定義の以下の項目の設定と同じです。

• コンテナイメージ(ジョブ実行に使用するDockerイメージ)
• コンテナに渡すコマンド(コマンド形式/JSON形式)
• コンテナ用に用意するvCPUの数
• ジョブのコンテナに適用されるメモリのハード制限

それに加えて、一番上にはジョブで設定する「ジョブタイプ」の設定があります。

デフォルトでは、

• ジョブタイプ: 単一
• コンテナイメージ: busybox(必要最低限の環境が整えられたDocker Hubの公式リポジトリ)
• コンテナに渡すコマンド: ハローワールド
• コンテナ用に用意するvCPUの数: 2
• ジョブのコンテナに適用されるメモリのハード制限: 2000MiB
• ジョブが失敗した場合に再試行する最大回数: 1

が設定されています。

▲ ここでしか見られない、ジョブとジョブ定義のパラメータが混ざった画面

残り2つのセクション(Paramaters,Environment variables)はオプションなので今回は特に設定せず、ジョブ定義の設定を完了します。

次は、コンピューティング環境とジョブキューの設定をします。

ここでも4つのセクションの設定をしていきます。

Set your compute environment type

コンピューティング環境タイプを設定します。 既にマネージド型での設定が用意されており、ここでは以下項目の設定が出来ます。

• コンピューティング環境名
• サービスロール(新規作成する時は必要ロールが自動作成されるので空欄で可)
• インスタンスロール(新規作成する時は必要ロールが自動作成されるので空欄で可)

上記の新規作成時のデフォルトが選択されていました。

▲ Get startedは設定項目が分けられ少なめに見えるのが分かり易くて良いです

Configure your compute resources

コンピューティング環境設定の続きです。 ここでは以下項目の設定が出来ます。

• プロビジョニングモデル
• オンデマンドインスタンス
• スポットインスタンス
• 上限入札価格
• スポットフリートロール(要事前作成)
• インスタンスタイプの指定(デフォルト: optimal)
• コンピューティング環境で維持するEC2 vCPUの最小数(デフォルト: 0)
• コンピューティング環境の起動に必要なEC2 vCPUの数(デフォルト: 0)
• コンピューティング環境でスケールアウトできるEC2 vCPUの最大数(デフォルト: 256)

デフォルトはほぼ、元々のコンピューティング環境設定と変わらないのですが、ここでスポットインスタンスを使用しようと思った場合は元の設定と異なり、 上限入札価格 の設定が必須なようです。

▲ 「optimal」だとM,C,Rファミリーの第4世代からインスタンスを選んでくれる模様

Set up your networking

コンピューティング環境設定の最後です。 ここでは以下項目の設定が出来ます。

• EC2インスタンスを起動するVPCのID(デフォルト: デフォルトVPC)
• EC2インスタンスを起動するサブネット(デフォルト: デフォルトVPCの全てのサブネット/最低1つは要指定)
• EC2インスタンスに適用するセキュリティグループ(デフォルト: デフォルトVPCのデフォルトセキュリティグループ)

▲ オプションでインスタンスにタグを付ける事が出来る

Set up your job queue

ジョブキューの設定です。

こちらが設定を変更できる項目はキューの名前のみとなっています。 上記で設定したコンピューティング環境が自動で選択されるようになっていました。

▲ これで設定は全て完了したので、ジョブを作成します

AWS Batchが作成されるのを確認出来るポップアップが表示されます。 以下のように完了したら、早速ダッシュボードを覗いてみます。

▲ あっという間に完了しました

実行したジョブの結果やログを確認する

ダッシュボードに、先ほど作成・実行したジョブキューがあるので、そこから実行されたジョブの状態を確認出来ます。

• ジョブキューの名前
• 優先度(今回は最低の1が設定されていた
• ジョブの状態
• SUBMITTED: スケジューラによるジョブ評価待ち
• PENDING: 別のジョブとの依存関係により処理待ち
• RUNNABLE: ジョブを実行するリソースが準備完了になり次第開始
• STARTING: コンテナ初期化操作が進行中
• RUNNING: ジョブはコンテナにて実行中
• FAILED: ジョブ実行による全ての試行が失敗
• SUCCEEDED: ジョブは終了コード0で正常に完了

SUCCEEDED/FAILEDのジョブ状態はAWS Batchに24時間保持されます。 デフォルトでは、SUCCEEDED/FAILEDのジョブのログはCloudwatch Logsに保管されます。 各ジョブにログへのリンクがあるのでそこから移動して確認出来ます。

▲ ジョブの実行時間等も確認出来ます

Cloudwatch Logsの

• ロググループ: /aws/batch/job
• ログストリームの名前: ジョブ定義名/default/ECSのTaskID

に、ログがあります。

▲ ECSのコンソールで、実際に上記のタスクIDが確認出来ました

AWS Batchのユースケース

最後に、AWS Batchの利用をより具体的に考えていきます。

AWSが公開しているユースケース

AWS公式ページに、「金融サービス」「ライフサイエンス」「デジタルメディア」と様々な業界でのAWS Batchのユースケースが紹介されています。 以下に、詳細ページのリンクを貼っておきます。

AWS Batchのユースケース

弊社サービス「インサイトウォッチ」でも使われている

弊社が提供している、AWSアカウントの運用をセキュリティ面からチェックしてくれるサービスである「インサイトウォッチ 」も、バッチ処理の管理にAWS Batchを利用しています。

他のバッチ機能との使い分け

他のAWSのマネージドサービスを用いて(組み合わせて)、バッチ処理を実現する事は可能です。 その際、AWS Batchとどう差別化を図っていくのかを考えてみました。

大枠の基準としては、以下を主軸に考えながらサービスを選定すると使い分けが分かり易くなるかと思います。

• どこまでインフラ層の要件を詰めたいか
• どこまでジョブのスケジューリング・実行の制約を考慮するか
• アプリケーションサイドの要件

AWS Batchは上記項目の対応範囲が広く、また細かく要件を詰められる為上記を ゴリッゴリに弄りたい際には有用なサービス です。各ジョブの依存性や優先度を明示的につけられるのも強みの一つです。 ただ、ゴリッゴリの度合いが強い為、取り敢えず動かそうとした際に詰めないといけない要件が結構多いです。インスタンスタイプをよしなに選んでくれる程度ではまだ有り難みを感じ難いのも事実です。 AWS Batchは、ECRをラッピングしたようなサービスなのでどうしてもコンテナベースの考え方を理解している必要があります。 また、ECSの中でもEC2ベースしか対応していない(Fargateが使えない)為、インフラ面に関しても最低限ECS(EC2起動タイプモデル)に関する知識は持っておく必要があります。 前述しましたが、選択できるEC2インスタンスもそれなりのサイズからとなっている為、実行するバッチ処理が軽い場合にはオーバースペックしてしまう可能性もあります。(短時間の処理だけで実行インスタンスが消されたとしても)

最低限、15分程度で動くバッチ処理の実装を考えるのであれば Lambdaベースの構成 を考えるのが楽です。 今ですと、 SQS + Lambda の構成なども考えられます。 弊社大栗の、LambdaがSQSをイベントソースとしてサポートした際のブログに設定が分かり易くまとめてありますのでそちらも併せて読んでみて下さい。

AWS LambdaがSQSをイベントソースとしてサポートしました！

また、Lambdaを組み合わせていくつかのバッチ処理を行う事も可能です。 これには、 Step Functions が使えます。 現在、Lambdaのサポート言語はJava、Go、PowerShell、Node.js、C#、Python、Rubyといった感じです。 併せて、一つの処理がLambdaの実行制限時間の15分に収まるといった条件を満たしている場合はStep Functionsの利用も検討するといいかもしれません。 今回の着眼ポイントとは逆に設定をより作り込んでいく方にはなってしまうのですが、昨年のre:Invent2018で発表された Step Functions + AWS Batch という構成も今なら選択肢には上がってくるのかなと思います。 この発表後すぐに、弊社山下が実際に試した(早い！)際のブログがありますので、そちらも併せて読んでみて下さい。

Step FunctionsからAWS Batchの配列ジョブを実行してみる – パラメータの渡し方 #reinvent

上記に名前が出てきた、 Fargate を利用する事も一つの有用な選択肢として考えられます。 実行時間の制限やLambdaでサポートしていない言語を利用したい、そしてAWS Batchほどゴリゴリのスケジューリングやカスタマイズは必要ない場合にフットワーク軽く、バッチ処理を実装出来ます。

弊社濱田の、Fargateでのバッチ処理の良さについて分かり易くまとめたブログがありますのでそちらも併せて読んでみて下さい。

Fargateがタスクスケジュールをサポートし定期実行処理の幅が超広がりました！

上記で比較として名前を挙げさせてもらったサービスについてのAWS再入門ブログは、以下になります。(追加され次第、リンクを追記します)

AWS再入門ブログリレー AWS Step Functions 編

参考資料

AWS Batch(AWS公式ページ) AWS Batch ドキュメント(日本語版) AWS Black Belt Online Seminar 2017 AWS Batch

さいごに

AWS Batchの基本を再認識しつつ、AWS Batchが兼ね備えている柔軟なバッチ処理への対応力の可能性を感じて頂けましたら幸いです。

以上、『AWS 再入門ブログリレー 2019』の 12日目のエントリ『AWS Batch』編でした。

明日 (7/18) はニシヤマ ユウジ の「Amazon Redshift」の予定です。お楽しみに！!