Blue/Greenデプロイの導入による 運用フローの改善 Engineering Productivity Meetup #2 2024-04-09 @Cybous, Inc in Osaka

daichi（だいち） Company: Job: SWE ( 2022 ~ ) : @da1chi24

● Blue/Green デプロイとは ● 導入に至った背景・課題 ● 導入プロセス ● 導入した効果 ● 今後の展望 話すこと

● 本番環境に既存のバージョン (Blue)と並行して新しいバー ジョン(Green)を準備し、テスト を行った後、トラフィックを新しい バージョンに切り替えるデプロイ 方式 ● Blueのタスクが残存している条 件下では瞬時に前のバージョンに 切り戻すことができる Blue/Green デプロイとは ECSを運用する際のイメージ

● ローリングアップデートとは、 既存の環境で稼働しているコンテナを順次新しいバージョンに置き 換える方式（ECSのデフォルト） ● circuit breaker や CloudWatch Alarm など異常を検知し て、自動で切り戻す方法もあるが、開発者の判断で切り戻す必要が ある場面も多い ● 前のバージョンに戻したい場合は、切り戻し前のタスクのリビジョン を再度デプロイする 以前は ECS + ローリングアップデートを採用

1. デプロイする前に現在のタスクのリビジョンをメモする 2. CI でデプロイジョブを発火させる 3. リビジョンが全て切り替わったことを確認する 4. 新しいバージョンで動作確認やQA検証を行う 5. （切り戻す場合）リリース前のリビジョンで再度リリースする 切り戻しを想定したリリース手順

● 開発者がデプロイする際にリビジョンを把握するという余計な 作業が発生する ○ 1リリースで3分消費、週1リリースだと1年で 150 分のロス ● 切り戻しのデプロイ作業やデプロイ自体の時間がかかる ● 切り戻し作業の手順が多い ○ 切り戻したいサービスから、前のリビジョンを選択して、サービ スをデプロイするという手順が必要 ○ 逼迫している状況ではミスにも繋がる 運用上の課題

● 緊急時にどの開発者でも簡潔な手順で素早く切り戻す ことができる ○ 切り戻したい状況では何かしらインシデントが発生している ので、逼迫していてもできるぐらい簡単な手順が好ましい ● 通常のリリースで切り戻す手順を意識する必要がない ○ 問題なくリリースされることの方が圧倒的に多いので、 常に切り戻しを想定した手順を入れるのは非効率 求めていたリリース手順

導入プロセス

● ECS サービス定義のデプロイコントローラーを変更 ○ ローリングアップデートからCodeDeployに変更 ● Blue/Green 用のターゲットグループの作成 ● CodeDeploy のリソースの作成 ● CI の設定 ● ドキュメントの整備 Blue/Green デプロイの導入プロセス

● サービス作成時に設定したデプロイコントローラーは途 中で変更できない ● そのため CodeDeploy を選択した ECSを新たに作 成し、元のサービスから CodeDeploy用のサービス自 体を切り替える必要があった ○ 初期に想定していたよりも大規模工事 ECS のデプロイコントローラーを変更できない

加重ルーティングで少しずつトラフィックを流す

導入した効果

● 緊急時にどの開発者でも簡潔な手順で素早く切り戻す ことができる ○ 切り戻したい状況では何かしらインシデントが発生している ので、逼迫していてもできるぐらいの簡単な手順が好ましい ● 通常のリリースで切り戻す手順を意識する必要がない ○ 問題なくリリースされることの方が圧倒的に多いので、 常に切り戻しを想定した手順を入れるのは非効率 求めていたリリース手順（再掲）

● どの開発者でも簡潔な 手順で素早く切り戻すこ とができる ● 通常のリリース時には 切り戻す手順を意識する 必要がない ワンクリックで容易に切り戻しができる

1. デプロイジョブを発火させる 2. CI ログの CodeDeploy のURLから実行結果を確認する 3. タスクの Replacement 100% になっていることを確認する 4. 新しいバージョンで動作確認やQA検証を行う 5. （切り戻す場合）CodeDeployの実行結果から切り戻す Blue/Green デプロイ導入後の運用フロー 切り戻しを想定してリビジョンを把握する手間が削減された

● Blueタスクが終了した場合は切り戻しができない ○ 残存期間を長すぎるとコストの増加など別の問題が発生 ● 直前のバージョンの切り戻しにしか対応していない ○ 2つ前のバージョンに戻すとかはできない ● アプリケーション単体に閉じている場合でしか切り戻し が有効にならない ○ RDS などの別サービスに関連している場合は効果がない CodeDeployの制約

● Blue/Green デプロイの導入で切り戻しが容易になり、デプロイ 時の安心材料が増えた ● デプロイ時の開発者の負担が軽減された ● デプロイまでのステップをいかに短くするかにボトルネックが シフトしたので注力していきたい ○ テスト・ビルド時間の短縮 ○ デプロイフローの整備 ○ タスク着手から PR が Approveされるまでのリードタイム まとめ・今後の展望

Appendix

● CodeDeployの Blue/Green デプロイにおいて、 Blue（前のバージョン）のタスクを terminate するまでの時間 ● 長くするメリット ○ 残存期間が長くするほど、瞬時に切り戻す時間を長くできる ○ 切り戻しの判断を遅らせることができる ● デメリット ○ BlueとGreenにタスクが残ることでコストが増える ○ デプロイ完了までの時間が長くなる termination_wait_time_in_minutes をどうするか