Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Blue/Greenデプロイの導入による 運用フローの改善
Search
daichi
April 09, 2024
Programming
1
990
Blue/Greenデプロイの導入による 運用フローの改善
https://cybozu.connpass.com/event/311067/
Engineering Productivity Meetup #2 in 大阪 での発表資料
daichi
April 09, 2024
Tweet
Share
More Decks by daichi
See All by daichi
テストライブラリによってコンポーネントテストの実行時間はどう変わるか / component-test-performance-by-library
kudoas
0
74
自作OSSで仕事を楽にする
kudoas
0
51
自作ツールを作って分かった Go を使うことのメリット
kudoas
0
54
ライブラリのアップデートをスムーズに楽しく進める工夫
kudoas
0
29
Other Decks in Programming
See All in Programming
Is Xcode slowly dying out in 2025?
uetyo
1
190
『自分のデータだけ見せたい!』を叶える──Laravel × Casbin で複雑権限をスッキリ解きほぐす 25 分
akitotsukahara
1
490
「ElixirでIoT!!」のこれまでとこれから
takasehideki
0
370
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
470
Bytecode Manipulation 으로 생산성 높이기
bigstark
2
370
Deep Dive into ~/.claude/projects
hiragram
7
1.3k
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
260
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
110
DroidKnights 2025 - 다양한 스크롤 뷰에서의 영상 재생
gaeun5744
3
310
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
1
110
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
340
Effect の双対、Coeffect
yukikurage
5
1.4k
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
930
Raft: Consensus for Rubyists
vanstee
140
7k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Side Projects
sachag
455
42k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Scaling GitHub
holman
459
140k
Six Lessons from altMBA
skipperchong
28
3.8k
Navigating Team Friction
lara
187
15k
Transcript
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 をどうするか