AWSのコンテナサービスであるAmazon ECSを使ったシステム運用において、ローリングアップデートは最も基本的なデプロイ手法です。
「ECSでのローリングアップデートはどう設定するのか」「タスク定義とサービスの関係はどうなっているのか」という疑問に答えます。
本記事では、Amazon ECSでのローリングアップデートの仕組み・設定方法・タスク定義・サービス更新・ダウンタイムゼロの実現方法を詳しく解説していきます。
AWSを使ったインフラ運用に携わるエンジニア・DevOpsエンジニア・クラウドエンジニアの方にぜひ参考にしていただける内容です。
ECSのデプロイメント設定を正しく理解することで、安全で効率的なコンテナ更新が実現します。
実際の設定パラメータと手順を具体的に解説しますので、現場での実装に役立てていただければ幸いです。
Amazon ECSのローリングアップデートの基本：タスク定義とサービスの関係
それではまず、Amazon ECSのローリングアップデートの基本的な仕組みとタスク定義・サービスの関係について解説していきます。
ECSでのローリングアップデートを理解するためには、まずECSの基本的な概念を把握することが重要です。
【Amazon ECSの基本概念】
タスク定義（Task Definition）
コンテナの設定を定義したテンプレートです。使用するDockerイメージ・CPUとメモリの割り当て・環境変数・ポートマッピングなどを記述します。バージョン管理され、更新のたびに新しいリビジョンが作成されます。
タスク（Task）
タスク定義に基づいて実際に起動するコンテナの実行単位です。
サービス（Service）
指定した数のタスクを常に稼働させ続ける管理単位です。タスクが停止したときに自動で再起動し、ロードバランサーとの統合・デプロイメント管理を行います。
クラスター（Cluster）
タスクやサービスを実行するインフラのグループです。EC2またはFargateを選択できます。
ローリングアップデートの流れは次の通りです。
①新しいDockerイメージをECR（Elastic Container Registry）にプッシュする → ②新しいタスク定義リビジョンを作成する → ③ECSサービスを新しいタスク定義に更新する → ④ECSが自動でローリングアップデートを実行する、という流れです。
ECSのサービス更新時にローリングアップデートが自動で実行される点が、ECSを使ったコンテナ運用の大きなメリットです。
ECSローリングアップデートの設定パラメータ：minimumHealthyPercentとmaximumPercent
続いては、ECSローリングアップデートの重要な設定パラメータについて確認していきます。
ECSのデプロイメント設定における最も重要なパラメータが「minimumHealthyPercent」と「maximumPercent」です。
【デプロイメント設定パラメータの意味】
minimumHealthyPercent（デフォルト：100）
デプロイ中に維持するべき正常タスクの最小割合です。
例：タスク数4台でminimumHealthyPercent=50の場合、最低2台が正常稼働していれば更新を進められます。
maximumPercent（デフォルト：200）
デプロイ中に一時的に稼働できるタスクの最大割合です。
例：タスク数4台でmaximumPercent=200の場合、最大8台まで一時的に稼働できます。
【ゼロダウンタイムのための設定】
minimumHealthyPercent = 100（常に指定台数を維持する）
maximumPercent = 200（新旧タスクを一時的に2倍まで起動できる）
→ 新タスクが起動して正常確認されてから旧タスクを停止するため、常に指定台数が稼働し続ける
minimumHealthyPercent=100・maximumPercent=200がダウンタイムゼロのローリングアップデートの標準設定です。
コスト削減を優先する場合はminimumHealthyPercent=50にすることで一時的なリソース使用を抑えられますが、その間は稼働タスク数が半分になるためトラフィックが多い本番環境では注意が必要です。
ECSサービスのデプロイメント実行手順：コンソールとCLIの操作方法
続いては、ECSサービスのデプロイメント実行手順についてAWSコンソールとCLIの両方から確認していきます。
【AWS CLIを使ったECSローリングアップデートの手順】
ステップ①：新しいタスク定義を登録する
aws ecs register-task-definition \
–family my-task \
–container-definitions ‘[{“name”:”my-container”,”image”:”123456789.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v2.0″,…}]’
ステップ②：ECSサービスを新しいタスク定義に更新する
aws ecs update-service \
–cluster my-cluster \
–service my-service \
–task-definition my-task:2 \ （新リビジョン番号を指定）
–deployment-configuration “minimumHealthyPercent=100,maximumPercent=200”
ステップ③：デプロイメントの進行状況を確認する
aws ecs describe-services \
–cluster my-cluster \
–services my-service \
–query ‘services[0].deployments’
AWSコンソールからの操作では、ECS→クラスター→サービス→「サービスの更新」からタスク定義のリビジョンを変更してデプロイを実行できます。
「describe-services」コマンドのdeployments配列を確認することで、PRIMARY（新バージョン）とACTIVE（旧バージョン）のタスク数を追跡できます。
デプロイ完了の確認はPRIMARYのrunningCountが目標のdesiredCountと一致し、ACTIVEのrunningCountが0になった時点です。
ECSローリングアップデートのトラブルシューティングと運用のポイント
続いては、ECSローリングアップデートのトラブルシューティングと運用のポイントについて確認していきます。
| よくある問題 | 原因 | 対処法 |
|---|---|---|
| デプロイが進まない | 新タスクのヘルスチェックが失敗している | タスクのログ確認・ヘルスチェック設定を見直す |
| タスクがCRASHING状態になる | コンテナが起動直後に終了している | CloudWatch Logsでエラーログを確認する |
| 旧タスクがなかなか停止しない | 接続中のリクエストのドレイニングが長い | ALBのderegistration_delay設定を調整する |
| ロールバックしたい | 新バージョンに問題が発見された | 前のタスク定義リビジョンでupdate-serviceを再実行する |
ECSのサービス更新では、ALB（Application Load Balancer）のターゲットグループへの登録・解除と連動したコネクションドレイニングが重要です。
旧タスクを停止する前にALBからの切り離しと既存接続の処理完了（ドレイニング）を待つことで、リクエストが失われないゼロダウンタイムのデプロイが実現します。
CI/CDパイプライン（CodePipeline・GitHub Actions等）にECSデプロイを組み込むことで、コードのプッシュから自動デプロイまでの継続的デリバリーが実現し、手動操作ミスのリスクが大幅に削減されます。
まとめ
Amazon ECSのローリングアップデートは、新しいタスク定義を作成してECSサービスを更新することで自動的に段階的なコンテナ更新が実行される仕組みです。
minimumHealthyPercent=100・maximumPercent=200がダウンタイムゼロのための標準設定であり、常に指定台数のタスクが稼働し続けます。
AWS CLIまたはコンソールからupdate-serviceコマンドでデプロイを実行し、describe-servicesで進行状況を確認できます。
ALBのコネクションドレイニングとCI/CDパイプラインとの統合が、実践的なECSローリングアップデート運用のポイントです。
本記事の設定方法と手順を参考に、ダウンタイムゼロの安全なコンテナ更新を実現してみてください。
