Blue/Greenデプロイの導入による�運用フローの改善

Engineering Productivity Meetup #2

2024-04-09

@Cybous, Inc in Osaka

daichi（だいち）

Company:

Job: SWE ( 2022 ~ )

: @da1chi24

話すこと

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

Blue/Green デプロイとは

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

ECSを運用する際のイメージ

以前は ECS + ローリングアップデートを採用

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

切り戻しを想定したリリース手順

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

​

運用上の課題

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

求めていたリリース手順

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

導入プロセス

Blue/Green デプロイの導入プロセス

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

ECS のデプロイコントローラーを変更できない

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

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

導入した効果

求めていたリリース手順（再掲）

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

ワンクリックで容易に切り戻しができる

• どの開発者でも簡潔な�手順で素早く切り戻すことができる
• 通常のリリース時には�切り戻す手順を意識する必要がない

Blue/Green デプロイ導入後の運用フロー

1. デプロイジョブを発火させる
2. CI ログの CodeDeploy のURLから実行結果を確認する
3. タスクの Replacement 100% になっていることを確認する
4. 新しいバージョンで動作確認やQA検証を行う
5. （切り戻す場合）CodeDeployの実行結果から切り戻す

切り戻しを想定してリビジョンを把握する手間が削減された

CodeDeployの制約

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

まとめ・今後の展望

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

Appendix

termination_wait_time_in_minutes をどうするか

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