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
400
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
自作OSSで仕事を楽にする
kudoas
0
25
自作ツールを作って分かった Go を使うことのメリット
kudoas
0
20
ライブラリのアップデートをスムーズに楽しく進める工夫
kudoas
0
20
Other Decks in Programming
See All in Programming
Build Apps for iOS, Android & Desktop in 100% Kotlin With Compose Multiplatform (mDevCamp 2024)
zsmb
0
440
Git Lint
bkuhlmann
4
760
CREってこういうこと? 体験入社 - 提案資料 - / what-is-cre-trial-employment
shinden
1
510
try! Swift Tokyo 2024 参加報告 / try! Swift Tokyo 2024 Report
hironytic
0
220
GraphQLサーバの構成要素を整理する #ハッカー鮨 #tsukijigraphql / graphql server technology selection
izumin5210
4
900
Apache Hive 4 on Treasure Data
ryukobayashi
1
420
Introducing Kotlin Multiplatform in an existing mobile app - Workshop Edition | AndroidMakers Paris
prof18
0
150
CA.swift19 恋するAIアプリ開発の裏側
oskmr
0
380
障害対応を起点としたもっといい開発と運用のサイクル作りのためにできること / Hatena Enginner Seminar #29
polamjag
0
380
Ruby GitHub Packages
bkuhlmann
0
640
『Railsオワコン』と言われる時代に、なぜブルーモ証券はRailsを選ぶのか
free_world21
1
360
PostmanでAPIの動作確認が楽になった話
h455h1
0
180
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
126
32k
Music & Morning Musume
bryan
41
5.6k
For a Future-Friendly Web
brad_frost
172
9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
20
1.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
Building an army of robots
kneath
300
41k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Thoughts on Productivity
jonyablonski
60
3.9k
Designing for Performance
lara
601
67k
jQuery: Nuts, Bolts and Bling
dougneiner
59
7.2k
Designing with Data
zakiwarfel
96
4.8k
From Idea to $5000 a Month in 5 Months
shpigford
378
45k
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 をどうするか