AWS Batch の特徴

AWS Batch on EKS は、Kubernetes ノードのスケーリングとノード内のポッドの配置の両方を管理します。これは、Amazon EKS が他のワークロードやサービスに対して提供する管理およびオーケストレーションを保持しながら行われます。AWS Batch は、既存の EKS クラスター内で Kubernetes ポッドとして安全にジョブを実行できます。必要なのは、コンテナが必要とする vCPU、メモリ、あらゆる GPU 要件を指定し、EKS クラスター対応のコンピューティング環境に接続したキューにそれらを送信するだけです。AWS Batch は、ジョブキューのキューイング、依存関係の追跡、リトライ、優先度、ポッドの送信を管理します。また、EC2 や EC2 Spot のコンピューティングリソースを使用しているかどうかにかかわらず、EKS 環境でのコンピューティングリソースのプロビジョニングを管理します。Batch は EKS クラスターと個別のネームスペースで統合されているため、AWS Batch ジョブが既存のプロセスに干渉する心配はありません。Batch は、ノードのウォームプールを維持する機能、一定の vCPU で容量を制限する機能、ノードをスケールして多くの異なるクラスターでジョブを実行する機能、または単純に単一のクラスターですべてのジョブを実行する機能を含む、容量を管理します。Batch は、独立したポッドを作業の中心単位としてサポートしますが、アレイを使用してジョブを集約してスケジューリングすることも可能です。

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

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

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

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

さらに、現在の Batch ユーザーの場合には、Fargate により EC2 からの分離機能も提供されます。AMI に関する管理やパッチ修正の必要はありません。Fargate 互換ジョブを Batch に送信する場合でも、ワークロードを EC2 と Fargate の両方で実行していれば、2 つの異なるサービスの保守について心配する必要はありません。

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

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

AWS Batch ではマルチノードの並列ジョブがサポートされているため、複数の EC2 インスタンスにまたがる単一のジョブを実行できます。この機能により、AWS Batch を使用して、大規模で密結合されたハイパフォーマンスコンピューティング (HPC) アプリケーションや分散 GPU モデルトレーニングなどのワークロードを簡単かつ効率的に実行できます。AWS Batch はまた、Elastic Fabric Adapter もサポートしています。これは、AWS 上での大規模なノード間通信を高いレベルで必要とするようなアプリケーションの実行を可能にする、ネットワークインターフェイスです。 

AWS Batch を使用すると、vCPU やメモリといったリソース要件、AWS Identity and Access Management (IAM) ロール、ボリュームのマウントポイント、コンテナのプロパティ、および環境変数を指定して、ジョブの実行方法を定義できます。AWS Batch では、Amazon ECS で実行されるコンテナ化されたアプリケーションとしてジョブが実行されます。Batch を使用して、異なるジョブ間の依存関係を定義することもできます。例えば、リソース要件が異なる 3 つの別個の処理ステージでバッチジョブを構成できます。依存関係を使用すると、後続の各ジョブが先行のジョブに依存する、リソース要件の異なる 3 つのジョブを作成できます。

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

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

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

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

AWS Batch を使用すると、コンピューティングリソースを割り当てる方法を 3 つの中から選択することができます。これらの方法により、AWS Batch がお客様に代わってインスタンスをスケールする方法を決定する際に、スループットと料金を考慮することができます。

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

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

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

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

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