rights reserved. デプロイまでの流れ（〜2025/07） ECS Code Deploy 3rd party ・・・ • Rolling update • All at Once（B/G） • Canary • Linear デプロイメントツール ECS Service デプロイメントコントローラ
rights reserved. デプロイまでの流れ（2025/07〜2025/10） ECS 3rd party ・・・ • Rolling update • All at Once（B/G） Code Deploy • All at Once（B/G） • Canary • Linear ECS Service デプロイメントツール デプロイメントコントローラ
rights reserved. デプロイまでの流れ（2025/10〜） ECS 3rd party ECS Service ・・・ • Rolling update • All at Once（B/G） • Canary • Linear Code Deploy • All at Once（B/G） • Canary • Linear デプロイメントツール デプロイメントコントローラ
rights reserved. Service Connect を利⽤した 柔軟なテスト 通常のトラフィック テストトラフィック x-amzn-ecs-blue- green-test Service Connect Proxy if has_header ("x-amzn- ecs-blue-green-test") → Green BLUE (production) v1.0 / weight = 100% GREEN (test only) v2.0 / test header only ※ ALB を利⽤した場合でも同様のことが可能
rights reserved. ECS デプロイメントコントローラ のメリット その4 Pre Scale Up Post Test Traffic Shift Post Production Traffic Shift Bake Time Clean Up Production Traffic Shift Scale Up Post Scale Up Test Traffic Shift • CodeDeploy では各ライフサイクルフックで1回限りの呼び出しだが、 ECS フックはステータスを⽤いて繰り返し実⾏可能 • また、CodeDeploy ではタイムアウトが1時間だが、ECS フックでは最⼤14⽇まで待機可能
rights reserved. 参考︓これまで ECS 側で⼿動承認を実装したかった場合 Post Test Traffic Shift Production Traffic Shift Test Traffic Shift ① ライフサイクルフック Lambda を呼び出し ② S3 に 承認ファイルがあるか確認 ③ ファイルがない場合、 Lambdaで以下のようにレスポンス return { "hookStatus": "IN_PROGRESS", "callBackDelay": 30, } ④ callBackDelay（30秒）経過後、Lambda を再呼び出し ※ サンプルコードは aws-samples にて公開
rights reserved. Post Test Traffic Shift Production Traffic Shift Test Traffic Shift ③ S3 に 承認ファイルがあることを確認 ④ 承認が完了したためフックステー タス SUCCEEDED でレスポンス ② 定期的に フック Lambda を呼び出し ① 承認を意図するファイルを配置 Post Test Traffic Shift Production Traffic Shift ⑤ 次のステージに遷移 参考︓これまで ECS 側で⼿動承認を実装したかった場合
rights reserved. ローリングアップデートの挙動 「新規タスクを起動し、古いタスクを削除する」という動作を繰り返す a a a a a a a a b b a a a a b b a a b b b b b b b b 1. 3. 4. 5. 6. 旧バージョン 新バージョン b b b b b b 7. a a a a 2.
rights reserved. ローリングアップデートの重要なパラメータ • minimumHealthyPercent - RUNNING 状態で残すタスク数の下限 • maximumPercent - RUNNING または PENDING 状態となるタスク数の上限 a a a a 1. a a a a 2. a a a a b b 3. b b b b b b 4. a a a a 1. a a 2. a a b b 3. b b 4. 5. b b b b b b b b 5. minimumHealthyPercent 100% maximumPercent 200% minimumHealthyPercent 50% maximumPercent 100%
rights reserved. ECS におけるサービスのデプロイメントについて • minimumHealthyPercent - RUNNING 状態で残すタスク数の下限 • maximumPercent - RUNNING または PENDING 状態となるタスク数の上限 a a a a 1. a a a a 2. a a a a b b 3. b b b b b b 4. a a a a 1. a a 2. a a b b 3. b b 4. 5. b b b b b b b b 5. minimumHealthyPercent 100% maximumPercent 200% minimumHealthyPercent 50% maximumPercent 100% • 旧タスクを維持しつつ 新タスクを起動 → 切替 • タスク数が⼀時的に最⼤ 2 倍まで広がる • 可⽤性重視 / コストは⼀時的に増える • 旧タスクを半分削除してから新タスクを起動 • タスク数の合計は⼀定 • コスト重視 / デプロイ時の可⽤性低下に注意
kenicazu
madoxten
khoart
cassininazir
.jpg){kind=avatar}
cargoodrich
codingconduct
scottboms
techseoconnect
jakevdp
quramy
retrage
sarafernandez
