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

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

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

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

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

重要

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

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

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

Blue/Green デプロイを使用した AMI 更新

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

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

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

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

    • imageId パラメータ

    • EC2 設定の imageIdOverrideパラメータ

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

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