CyberAgentがECSのEXTERNALからECSネイティブへ移行 Terraform管理で無停止に近づける工夫
公開日：2026年10月1日
3行解説
- CyberAgentが、ECSのEXTERNAL制御からECSネイティブ制御へ移す方法を公開した。
- Terraformではdeployment_controller.typeがForceNewで、単純変更だと再作成扱いになる。
- 本番通信中のサービスで、再作成によるリクエスト欠損をどう避けるかが焦点だった。
ニュースの概要
CyberAgent Developers Blogは2026年9月29日、ECS Fargateサービスのデプロイ方式を、PipeCDが使っていたEXTERNAL controllerから、GitHub ActionsとECSのネイティブcontrollerへ切り替えた経緯を公開した。対象はApplication Load Balancer配下で稼働する本番サービスで、移行の背景には社内の継続的デリバリー基盤をより薄いGitHub Actions workflowへ寄せる方針がある。記事では、Terraform管理下での切り替えが再作成を伴う点と、通信中サービスへの影響をどう抑えたかを説明している。
何が新しいのか
新しい点は、ECSの制御方式変更そのものではなく、Terraform管理のまま本番影響を抑えて切り替えるという実務の整理にある。AWS自体はサービスをcontroller間でインプレース移行できる一方、記事の環境ではTerraform AWS provider v5.80.0の制約により、deployment_controller.typeの変更がForceNewとなり、単純な差分適用ではサービス再作成になってしまう。そこで、PipeCDが担っていたデプロイ責任をGitHub ActionsとECSネイティブのrolling updateへ移し、deployment circuit breakerで失敗時の戻しを効かせる構成に変えた。
外部オーケストレーターが担っていた役割を、ECS標準のデプロイ制御へ寄せる流れを示している。
グリットアーツ編集部の分析
この事例で重要なのは、デプロイ方式の変更が「ツールの入れ替え」では終わらない点です。PipeCDはTaskSetを使ってcanaryやblue/greenを回していましたが、移行後はECSのrolling updateとdeployment circuit breakerが中心になります。つまり、デプロイの責任範囲が外部ツールからAWS標準機能へ移るため、運用は簡素化しやすい一方、細かなトラフィック制御の自由度は設計し直しになる可能性があります。TerraformのForceNew制約がある環境では、IaCの都合が本番可用性に直結するため、変更手順を先に固める価値が高いです。
日本の現場で考えると
日本企業の本番環境では、ECSのcontroller切り替えは「いつでも戻せる」前提で進めるべきです。特にALB配下で常時リクエストを受ける業務システムでは、サービス再作成が一瞬でも入ると、短時間でも欠損やエラーが出る可能性があります。向いているのは、GitHub Actionsでの標準化を進めたいチームや、デプロイ責任を一本化したい運用です。一方で、canary比率を細かく制御したい、あるいは既存の外部CD基盤に強く依存している環境では、いきなり全面移行せず段階切り替えが無難です。
導入・検討時に確認したいこと
- Terraformでの変更が再作成になるか、既存バージョンで事前確認すること。
- ALB配下でcontrollerを切り替えた際、リクエスト欠損が出ないか検証すること。
- deployment circuit breakerが失敗時にどこまで自動復旧するか確認すること。
- GitHub Actions側がどこまでデプロイ責任を持ち、何をECSに任せるか整理すること。
- 切り戻し時に、旧controllerへ戻す手順と停止時間を明文化すること。
現時点で分かっていないこと
記事からは、切り替え時の具体的な停止時間や、実際のリクエスト欠損の有無は分からない。また、どの程度の規模のサービス群を対象にしたのか、Terraformのどの設定で再作成を回避したのかも本文途中では明示されていない。
ECSの制御方式変更は、IaCの制約と本番停止リスクが重なりやすい領域です。自社のサーバー室やクラウド運用でも、切り替え時の影響をどう抑えるかを先に整理しておく価値があります。
ITインフラの構築・保守をご検討の方へ
「自社の環境にはどんな構成・保守体制が合うのか」お悩みではありませんか。貴社の現場課題に合わせたご提案をいたします。まずはご相談からお気軽にどうぞ。