AWS Batch でコンピューティング環境を更新する - AWS Batch
コンピューティング環境の更新戦略適切な更新戦略の選択

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Batch でコンピューティング環境を更新する

AWS Batch は、コンピューティング環境を更新するための複数の戦略を提供します。各戦略は、特定の更新シナリオと要件に合わせて設計されています。これらのアプローチは、同じ基盤となる更新 API を使用しますが、更新を効果的に管理するためのさまざまな規範的手法を示しています。これらの更新は、AWS Batch コンソールまたは AWS CLI を使用して管理できます。これらの戦略を理解することで、ワークロードの中断を最小限に抑えつつ、ニーズに最適な方法を選択できます。

このトピックでは、利用可能な更新戦略の概要と、各アプローチを使用するタイミングに関するガイダンスについて説明します。詳細な手順については、各更新戦略の個々のセクションを参照してください。

重要

AWS Batch は、Amazon EC2 起動テンプレート、Amazon EC2 Auto Scaling グループ、Amazon EC2 スポットフリート、Amazon ECS クラスターなど、ユーザーに代わってアカウント内で複数の AWS リソースを作成および管理します。これらのマネージドリソースは、最適な AWS Batch オペレーションを確保するために特別に設定されています。これらの AWS Batch マネージドリソースを手動で変更すると、AWS Batch ドキュメントに明示的に記載されていない限り、INVALID コンピューティング環境、最適ではないインスタンススケーリング動作、ワークロード処理の遅延、予期しないコストなど、想定外の動作が発生する可能性があります。これらの手動変更は、AWS Batch サービスで決定的にサポートすることはできません。コンピューティング環境を管理するには、サポートされている AWS Batch API または AWS Batch コンソールを必ず使用してください。

トピック

コンピューティング環境の更新戦略

スケーリングまたはインフラストラクチャの更新を使用すると、コンピューティング環境が更新されます。ブルー/グリーン更新戦略では、新しいコンピューティング環境 (グリーン) を作成し、ワークロードを古いコンピューティング環境 (ブルー) から新しいコンピューティング環境 (グリーン) に移行します。

AWS Batch には、コンピューティング環境の更新に関する 3 つの異なる戦略があります。

スケーリングの更新

スケーリングの更新は、既存のインスタンスを置き換えることなくインスタンスを追加または削除することで、コンピューティング環境の容量を調整します。これは最速の更新シナリオであり、ダウンタイムは必要ありません。容量設定 (vCPUs) を変更する必要がある場合は、スケーリングの更新を使用します。これらの更新は通常、数分で完了します。

Fargate の更新は、スケーリングの更新と同じ手順を使用して実行されます。詳細については、スケーリングの更新を実行する を参照してください。

インフラストラクチャの更新

インフラストラクチャの更新は、コンピューティング環境のインスタンスを、設定が更新された新しいインスタンスに置き換えます。これらの更新には、特定のサービスロールと割り当て戦略の設定が必要ですが、ダウンタイムを最小限に抑えることができ、実行中のジョブが中断される可能性があります。インスタンスタイプ、AMI 設定、ネットワーク設定、サービスロール、環境の状態、またはその他のインフラストラクチャコンポーネントを変更する必要がある場合は、インフラストラクチャの更新を使用します。これらの更新は通常、ジョブの完了にもよりますが 10～30 分で完了します。

詳細については、インフラストラクチャの更新を実行する を参照してください。

ブルー/グリーン更新

ブルー/グリーン更新により、既存の環境とともに新しいコンピューティング環境が作成され、ダウンタイムなしでワークロードを段階的に移行できます。このアプローチは最も安全な更新パスを提供しますが、2 つの環境を一時的に実行する必要があります。ダウンタイムゼロが必要である場合、完全なデプロイ前に変更をテストする場合、クイックロールバック機能が必要な場合、またはインフラストラクチャの更新でサポートされていない設定を使用している場合は、ブルー/グリーン更新を使用します。完了までの時間はさまざまで、ユーザーが制御します。

詳細については、コンピューティング環境のブルー/グリーン更新を実行する を参照してください。

適切な更新戦略の選択

この決定ガイドを使用して、ニーズに最も適した更新戦略を選択します。

次の場合は、スケーリングの更新を選択します。

コンピューティング容量 (vCPUs) を調整するだけで済む場合は、スケーリング更新戦略を選択します。スケーリングの更新は、ダウンタイムなしの迅速な更新が必要で、インフラストラクチャ設定の変更が不要な場合に最適です。

詳細な手順については、スケーリングの更新を実行する を参照してください。

次の場合は、インフラストラクチャの更新を選択します。

インスタンスタイプ、AMI 設定、サービスロール、環境の状態、またはネットワーク設定を変更する必要がある場合は、インフラストラクチャの更新戦略を選択します。環境では、サービスにリンクされたロール [AWSServiceRoleForBatch] と、BEST_FIT_PROGRESSIVE、SPOT_CAPACITY_OPTIMIZED、SPOT_PRICE_CAPACITY_OPTIMIZED の割り当て戦略を使用する必要があります。インフラストラクチャの更新は、更新中にジョブの若干の中断が許容され、最新の Amazon ECS 最適化 AMI の自動更新が必要な場合に適しています。

詳細な手順については、インフラストラクチャの更新を実行する を参照してください。

次の場合は、ブルー/グリーン更新を選択します。

ワークロードのダウンタイムがゼロである必要がある場合、または本番ワークロードの移行前に変更をテストする必要がある場合は、ブルー/グリーン更新戦略を選択します。このアプローチは、クイックロールバック機能が重要である場合、環境が BEST_FIT 配分戦略を使用する場合、または環境においてサービスにリンクされたロール [AWSServiceRoleForBatch] を使用しない場合に不可欠です。ブルー/グリーン更新は、手動更新を必要とするカスタム AMI を使用する場合や、大規模な設定変更を行う必要がある場合にも最適です。

詳細な手順については、コンピューティング環境のブルー/グリーン更新を実行する を参照してください。

AMI 更新に関する考慮事項

AWS Batch は、これらの条件がすべて満たされた場合、インフラストラクチャの更新中に最新の Amazon ECS 最適化 AMI に更新できます。

注記

インフラストラクチャの更新が完了すると、updateToLatestImageVersion が false に設定されます。別の更新を開始するには、updateToLatestImageVersion を true に設定する必要があります。

  • コンピューティング環境は、サービスにリンクされたロール [AWSServiceRoleForBatch] を使用します。

  • 割り当て戦略を BEST_FIT_PROGRESSIVE、SPOT_CAPACITY_OPTIMIZED、SPOT_PRICE_CAPACITY_OPTIMIZED に設定します。

  • imageId、imageIdOverride または起動テンプレートで AMI ID が明示的に指定されていない

  • updateToLatestImageVersion は true に設定されています。

ブルー/グリーンデプロイを使用した AMI の更新

以下のシナリオでは、ブルー/グリーンデプロイを使用して AMI を更新する必要があります。

  • Amazon ECS 最適化 AMI の特定のバージョンを使用する場合

  • AMI ID が次のいずれかで指定されている場合:

    • 起動テンプレート (テンプレートを更新するか、削除する必要があります)

    • imageId パラメータ

    • EC2 設定の imageIdOverride パラメータ

  • BEST_FIT 配分戦略を使用する場合 (インフラストラクチャの更新をサポートしていない)

  • サービスにリンクされたロール [AWSServiceRoleForBatch] を使用していない場合