AWS Batch を使用する理由
AWS Batch では、バッチジョブのコードをパッケージ化し、その依存関係を指定でき、AWS マネジメントコンソール、CLI、または SDK を使用してバッチジョブを送信できます。実行パラメータとジョブ依存関係を指定すると、AWS Batch はバッチコンピューティングワークフローでよく使用されるさまざまなエンジンや言語 (Pegasus WMS、Luigi、Nextflow、Metaflow、Apache Airflow、AWS Step Functions など) との統合を簡単に行うことができます。AWS Batch は、Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service (EKS)、AWS Fargate のコンピューティングリソースを効率的かつ動的にプロビジョニングおよびスケールし、ジョブの要件に基づいてオンデマンドインスタンスかスポットインスタンスを使用するオプションが用意されています。AWS Batch にはデフォルトのジョブキューとコンピューティング環境定義が用意されているため、すぐに使用を開始できます。
ジョブの定義
マルチコンテナジョブ
マルチコンテナジョブは、自動運転車やロボット工学で使用されるような複雑なシステムをテストする場合に、大規模なシミュレーションをより簡単かつ迅速に実行できるようにする機能です。1 つのジョブで複数のコンテナを実行できるため、システムを複雑なモノリシックコンテナに再構築しなくても、AWS Batch の高度なスケーリング、スケジューリング、コスト最適化機能を活用できます。代わりに、それぞれ 3D 仮想環境、ロボット認識センサー、データログ記録サイドカーなど、さまざまなシステムコンポーネントを表す複数の小さなモジュール式コンテナを引き続き使用できます。マルチコンテナジョブは、ジョブの準備手順を減らすことで開発時間を短縮し、追加の社内ツールを構築する必要がなくなります。複数のコンテナでシミュレーションジョブを実行すると、コンポーネントの責任を定義することで、ソフトウェア開発 (開発) と IT 運用 (運用) も簡素化されます。これにより、さまざまなチームが他のチームのコンポーネントに気を取られることなく、自チームのコンポーネントのエラーを見つけて修正できます。
密結合 HPC ワークロードのサポート
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 上でジョブをコンテナ化されたアプリケーションとして実行します。 また、異なるジョブ間の依存関係を定義することもできます。例えば、リソース要件が 3 つの別個の処理ステージでバッチジョブを構成できます。依存関係により、後続の各ジョブが先行のジョブに依存する、リソース要件の異なる 3 つのジョブを作成できます。
統合
よく使用されるワークフローエンジンのサポート
AWS Batch は、商用およびオープンソースのワークフローエンジン (Pegasus WMS、Luigi、Nextflow、Metaflow、Apache Airflow、AWS Step Functions など) と統合できるため、使い慣れたワークフロー言語を使用して、バッチコンピューティングパイプラインをモデル化できます。
EC2 起動テンプレートとの統合
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 オペレーションに対する完全なアクセス権限を付与し、開発者にはコンピューティング環境の設定とジョブの登録に関連する限定されたアクセス権限を付与し、エンドユーザーはジョブの送信と削除に必要なアクセス権限に制限することができます。
コンピューティング環境
Amazon EKS 上の AWS Batch
AWS Batch は、既存の Amazon EKS クラスターでバッチジョブを実行できます。コンテナに必要な vCPU、メモリ、GPU の要件を指定し、それらを EKS クラスター対応のコンピューティング環境に接続されたキューに送信します。AWS Batch は、Kubernetes ノードのスケーリングとノード内のポッドの配置の両方を管理します。さらに、AWS Batch はキューイング、依存関係の追跡、ジョブの再試行、優先順位付け、ポッドの送信を管理し、Amazon Elastic Compute Cloud (EC2) のオンデマンドインスタンスとスポットインスタンスもサポートします。また AWS Batch は EKS クラスターと個別のネームスペースで統合されているため、バッチジョブが既存のプロセスに干渉する心配はありません。最後に、AWS Batch はお客様に代わってキャパシティーを管理します。これには、ノードのウォームプールの維持、一定量の vCPU でのキャパシティーの上限設定、ノードのスケール、1 つのクラスター内または複数のクラスターにわたるジョブの実行が含まれます。
Fargate を使用する AWS Batch
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 スケジューリングのサポート
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 つ以上のインスタンスタイプを選択します。中断される可能性が低いインスタンスタイプを優先して選択します。この割り当て戦略は、スポットインスタンスのコンピューティングリソースのみで利用可能です。