インフラ設計

AWS Batch で実現する大規模バッチ処理 - ジョブキュー設計とコスト最適化

ジョブキューの優先度設計と Fargate・EC2 コンピューティング環境の選定基準を明確にし、配列ジョブとジョブ依存関係で複雑な計算パイプラインを構築する手法を紹介します。

約 1 分で読めます

AWS Batch の仕組みとユースケース

AWS Batch はコンテナベースのバッチ処理を自動的にスケジュール・実行するサービスです。ジョブ定義 (Docker イメージ、vCPU、メモリ、環境変数)、ジョブキュー (優先度付きのキュー)、コンピューティング環境 (Fargate または EC2) の 3 つのコンポーネントで構成されます。ジョブをキューに投入すると、Batch がコンピューティングリソースを自動的にプロビジョニングし、ジョブを実行し、完了後にリソースを解放します。ゲノム解析、金融リスク計算、動画エンコーディング、機械学習のハイパーパラメータチューニングなど、大量の計算リソースを一時的に必要とするワークロードに最適です。

Fargate と EC2 コンピューティング環境の選定

Fargate コンピューティング環境はインスタンスの管理が完全に不要で、ジョブごとに vCPU (最大 16) とメモリ (最大 120 GiB) を指定するだけです。ジョブの起動時間は数十秒で、短時間のジョブや中規模のバッチ処理に適しています。EC2 コンピューティング環境はインスタンスタイプの指定、GPU インスタンスの利用、マルチノード並列ジョブの実行が可能です。大規模な HPC ワークロードや GPU を使用する機械学習推論には EC2 を選択します。EC2 環境ではスポットインスタンスを活用でき、中断耐性のあるジョブであればオンデマンドの最大 90% 引きで実行できます。Batch はスポットの中断時にジョブを自動的にリトライする機能を備えています。

ジョブキュー設計と依存関係

ジョブキューには優先度を設定でき、高優先度のキューのジョブが先にスケジュールされます。本番ジョブ用の高優先度キューと開発・テスト用の低優先度キューを分離し、本番ジョブが常に優先的にリソースを確保できる設計が一般的です。ジョブの依存関係は dependsOn パラメータで定義します。前段のデータ前処理ジョブが完了してから本処理ジョブを実行し、最後に後処理ジョブを実行するといった DAG 構造を構築できます。配列ジョブは同一のジョブ定義を指定した数 (最大 10,000) だけ並列実行する機能で、各タスクには 0 から始まるインデックスが割り当てられます。インデックスを使って入力データを分割し、大規模データセットの並列処理を実現します。 AWS Batch のアーキテクチャを網羅的に学ぶなら、技術書 (Amazon)を参照してください。

AWS Batch の料金

AWS Batch 自体に追加料金は発生しません。コストは使用するコンピューティングリソース (Fargate のタスク料金または EC2 インスタンス料金) のみです。Fargate は vCPU 時間あたり約 0.04048 ドル、メモリ GB 時間あたり約 0.004445 ドルです。EC2 環境ではスポットインスタンスを活用して最大 90% のコスト削減が可能です。ジョブキューに複数のコンピューティング環境を関連付け、スポットを優先、オンデマンドをフォールバックとする構成でコストと可用性のバランスを取ります。

まとめ

AWS Batch はバッチ処理のインフラ管理を自動化し、ジョブの投入に集中できるサービスです。Fargate で手軽に始め、GPU やスポットインスタンスが必要になったら EC2 環境に拡張する段階的なアプローチが有効です。ジョブの依存関係と配列ジョブを組み合わせることで、複雑な計算パイプラインを効率的に実行できます。

関連するサービス

AWS Batchバッチコンピューティングジョブを効率的にスケジューリング・実行するマネージドサービスAWS Fargateサーバーを意識せずにコンテナを実行できるサーバーレスコンピューティングエンジンAmazon EC2クラウド上で仮想サーバーを提供するコンピュートサービス

関連する記事

AWS Step Functions で設計するワークフローオーケストレーション - 標準と Express の使い分け標準ワークフローと Express ワークフローの選定基準を明確にし、Retry/Catch の宣言的エラーハンドリングと分散マップによる大規模並列処理を紹介します。AWS Batch で実行する GPU ベースの機械学習トレーニング - コスト効率の高い大規模学習既存の Docker コンテナで GPU トレーニングを実行し、スポットインスタンスとチェックポイントでコストを最大 90% 削減する。SageMaker との使い分けも紹介します。AWS ParallelCluster で構築する HPC 環境 - Slurm クラスタの自動構築とスケーリングHPC クラスタを CloudFormation ベースで自動構築し、Slurm スケジューラでジョブを管理する。スポットインスタンスによるコスト最適化も紹介します。

同じテーマの記事

Auto Scaling はなぜスケールアウトは速く、スケールインは慎重なのか - 非対称な判断ロジックの設計意図EC2 Auto Scaling がスケールアウトを即座に実行する一方でスケールインに冷却期間を設ける非対称な設計の理由、フラッピング防止の仕組み、ターゲット追跡スケーリングの内部ロジックを解説します。AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。AWS の障害ドメイン設計 - AZ・リージョン・パーティションの 3 層構造が守る可用性の仕組みAWS のインフラが AZ (障害隔離)、リージョン (地理的分離)、パーティション (政治的分離) の 3 層で設計されている理由と、各層の障害がどこまで波及するかを具体的な事例とともに解説します。AWS 障害から学ぶ分散システムの原則 - 過去の大規模障害が変えたアーキテクチャS3 障害 (2017)、Kinesis 障害 (2020)、us-east-1 の特殊性など、AWS が公開した障害レポートを題材に、Shuffle Sharding、Static Stability、Cell-based Architecture といった設計原則を解説します。AWS はなぜそこにリージョンを建てるのか - データセンター立地選定の知られざる判断基準AWS がリージョンの立地を決定する際に考慮する電力供給、地政学リスク、データ主権法制、ネットワーク接続性、自然災害リスクなどの判断基準を、具体的なリージョンの事例とともに解説します。AWS の Availability Zone ID はなぜアカウントごとに異なるのか - AZ マッピングの設計意図us-east-1a がアカウントごとに異なる物理 AZ を指す仕組み、AZ ID (use1-az1) が導入された背景、キャパシティの均等分散という設計意図、クロスアカウントでの AZ 指定の注意点を解説します。バッチコンピューティング基盤 - AWS Batch で実現する大規模並列処理AWS Batch を活用した大規模バッチ処理の構築方法を解説します。ジョブキュー、コンピューティング環境の自動スケーリング、Spot インスタンスによるコスト最適化など、科学計算や大規模データ処理に最適なバッチ基盤の設計を紹介します。AWS Batch でバッチコンピューティングを自動化 - ジョブキューとコンピューティング環境の設計AWS Batch によるジョブのスケジューリング、Fargate/EC2 コンピューティング環境の使い分け、スポットインスタンスの活用を解説します。

内容が近い記事・サービス

AWS Batch数十万件規模のバッチ処理ジョブを自動的にスケジューリングし、最適なコンピューティングリソースで実行するフルマネージドサービスAWS Batch でバッチコンピューティングを自動化 - ジョブキューとコンピューティング環境の設計AWS Batch によるジョブのスケジューリング、Fargate/EC2 コンピューティング環境の使い分け、スポットインスタンスの活用を解説します。バッチコンピューティング基盤 - AWS Batch で実現する大規模並列処理AWS Batch を活用した大規模バッチ処理の構築方法を解説します。ジョブキュー、コンピューティング環境の自動スケーリング、Spot インスタンスによるコスト最適化など、科学計算や大規模データ処理に最適なバッチ基盤の設計を紹介します。AWS Batch で実行する GPU ベースの機械学習トレーニング - コスト効率の高い大規模学習既存の Docker コンテナで GPU トレーニングを実行し、スポットインスタンスとチェックポイントでコストを最大 90% 削減する。SageMaker との使い分けも紹介します。