AWS Batch の特徴

AWS Batch は、商用およびオープンソースのワークフローエンジン (Pegasus WMS、Luigi、Nextflow、Metaflow、Apache Airflow、AWS Step Functions など) と統合できるため、使い慣れたワークフロー言語を使用して、バッチコンピューティングパイプラインをモデル化できます。

AWS Batch が EC2 起動テンプレートをサポートするようになったため、コンピューティングリソース用にカスタマイズされたテンプレートを作成しながら、Batch は要件に合わせてインスタンスをスケールできます。EC2 起動テンプレートで指定できる機能には、ストレージボリュームの追加、ネットワークインターフェイスの選択、権限の設定といったものがあります。EC2 起動テンプレートを使用すると、1 つのリソース内で起動パラメータが取得されるため、Batch 環境の構成に必要なステップの数が削減されます。

AWS Batch により、バッチジョブの主要なオペレーションメトリクスが AWS マネジメントコンソールに表示されます。コンピューティング性能に関連するメトリクスや、実行中、保留中、および完了済みのジョブのメトリクスを表示できます。ジョブ (STDERR、STDOUT など) のログはコンソールに表示され、Amazon CloudWatch Logs にも書き込まれます。

AWS Batch では、IAM を使用して、ジョブからアクセスできる AWS リソース (Amazon DynamoDB テーブルなど) を制御およびモニタリングします。IAM を使用して、組織内の異なるユーザーに対するポリシーを定義することもできます。例えば、管理者には AWS Batch の API オペレーションに対する完全なアクセス権限を付与し、開発者にはコンピューティング環境の設定とジョブの登録に関連する限定されたアクセス権限を付与し、エンドユーザーはジョブの送信と削除に必要なアクセス権限に制限することができます。

AWS Batch は、既存の Amazon EKS クラスターでバッチジョブを実行できます。コンテナに必要な vCPU、メモリ、GPU の要件を指定し、それらを EKS クラスター対応のコンピューティング環境に接続されたキューに送信します。AWS Batch は、Kubernetes ノードのスケーリングとノード内のポッドの配置の両方を管理します。さらに、AWS Batch はキューイング、依存関係の追跡、ジョブの再試行、優先順位付け、ポッドの送信を管理し、Amazon Elastic Compute Cloud (EC2) のオンデマンドインスタンスとスポットインスタンスもサポートします。また AWS Batch は EKS クラスターと個別のネームスペースで統合されているため、バッチジョブが既存のプロセスに干渉する心配はありません。最後に、AWS Batch はお客様に代わってキャパシティーを管理します。これには、ノードのウォームプールの維持、一定量の vCPU でのキャパシティーの上限設定、ノードのスケール、1 つのクラスター内または複数のクラスターにわたるジョブの実行が含まれます。

AWS Batch で Fargate リソースを使用することで、バッチジョブのための完全なサーバーレスアーキテクチャを実現できます。Fargate を使用すれば、すべてのジョブに対し、要求する正確な量の CPU とメモリが (許可された Fargate SKU 内で) 割り当てられるため、リソースのために無駄な時間を費やしたり EC2 インスタンスの起動を待ったりする必要がありません。

さらに、現在の AWS Batch ユーザーの場合、Fargate では EC2 インスタンスからさらに分離させることもできます。Amazon マシンイメージ (AMI) を管理したり、パッチを適用したりする必要はありません。Fargate 互換ジョブを Batch に送信する場合でも、一部のワークロードを Amazon EC2 と Fargate の両方で実行していれば、2 つの異なるサービスの保守について心配する必要はありません。

AWS では、マネージド型キューに加えて、優先順位、ジョブの再試行、依存関係、タイムアウトその他に関する設定機能を完備した、クラウドベースのスケジューラをご提供しています。Fargate への送信や、ジョブのライフサイクルは、お客様に代わりすべて AWS Batch が管理します。

また Fargate では、追加的な労力 (SOX および PCI コンプライアンスなど) はまったく必要なく、セキュリティ上のメリットを享受できます。さらに、すべてのジョブでコンピューティングリソース間を分離できます。

AWS Batch を使用すると、優先度の異なる複数のクエリを設定できます。バッチジョブは、コンピューティングリソースがジョブを実行できるようになるまで、キューに保存されます。AWS Batch スケジューラでは、各ジョブのリソース要件に基づいて、キューに送信されたジョブを実行するタイミング、場所、および方法が評価されます。スケジューラでは、ジョブに未処理の依存関係がなければ、各キューの優先順位が評価され、最適なコンピューティングリソース (例えば、メモリ最適化と CPU 最適化を比較して) で優先順位に基づいてジョブが実行されます。

GPU スケジューリングは、ジョブが必要とするアクセラレーターの数とタイプを AWS Batch のジョブ定義入力変数として指定することを可能にします。AWS Batch は次に、GPU の必要数に基づいてジョブに適したインスタンスがスケールアップするとともに、各ジョブのニーズに応じてアクセラレーターが隔離されるため、それらには適切なコンテナしかアクセスできなくなります。

AWS Batch とともに AWS Fargate もしくは Fargate Spot を使用した場合、Batch に対し設定が必要となるのは少数のコンセプト (コンピューティング環境、ジョブキュー、ジョブ定義) のみです。そのままで、完全なキューやスケジューラー、さらにコンピューティングアーキテクチャが利用可能になります。コンピューティング用のインフラストラクチャを、一切管理する必要はありません。

AWS Batch では、EC2 インスタンスを所望するユーザーに対し、マネージド型のコンピューティング環境が提供されます。送信されたジョブのボリュームとリソース要件に基づいて、コンピューティングリソースが動的にプロビジョニングおよびスケーリングされます。マネージド型コンピューティング環境には、EC2 インスタンスのタイプ、VPC サブネットの構成、すべてのインスタンスにわたる vCPU の最小数/最大数/望ましい数などの要件が設定できます。また、スポットインスタンスに支払う意思のある金額を、オンデマンドインスタンス料金に対する割合 (%) として設定することもできます。

または、AWS Batch のマネージド型コンピューティング環境で用意されているものとは異なる設定 (より大きな EBS ボリューム、異なるオペレーティングシステムなど) を EC2 インスタンスで使用する必要がある場合は、アンマネージド型コンピューティング環境内で独自のコンピューティングリソースをプロビジョニングして管理することもできます。ユーザーが必要な操作は、Amazon ECS エージェントを含む EC2 インスタンスをプロビジョニングし、サポートされているバージョンの Linux と Docker を実行することのみです。その後は、AWS Batch により、ユーザーがプロビジョニングする EC2 インスタンスでバッチジョブが実行されます。

AWS Batch では、コンピューティングリソースを割り当てる方法を 3 つ選択できます。これらの戦略により、AWS Batch によるインスタンスのスケール方法を決定する際に、スループットと料金を考慮に入れることができます。

最適: AWS Batch がジョブのニーズに最適なインスタンスタイプを選択する際、コストが最も低くなるインスタンスタイプを優先して選択します。選択したインスタンスタイプの追加インスタンスが利用できない場合、AWS Batch は追加インスタンスが利用可能になるまで待機します。十分なインスタンスが利用できない場合、またはユーザーが Amazon EC2 サービスの制限に達した場合、現在実行中のジョブが完了するまで追加のジョブは実行されません。この割り当て戦略によりコストは低減されますが、スケーリングが制限されることがあります。

最適な進歩: AWS Batch が、キュー内にあるジョブの要件を満たせるサイズの追加のインスタンスタイプを選択します。単位 vCPU あたりのコストが低いインスタンスタイプを優先して選択します。以前に選択したインスタンスタイプの追加インスタンスが利用できない場合、AWS Batch は新しいインスタンスタイプを選択します。

スポットキャパシティーの最適化: AWS Batch が、キュー内にあるジョブの要件を満たせるサイズの 1 つ以上のインスタンスタイプを選択します。中断される可能性が低いインスタンスタイプを優先して選択します。この割り当て戦略は、スポットインスタンスのコンピューティングリソースのみで利用可能です。