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 KUDO
April 09, 2024
Programming
1
1.1k
Blue/Greenデプロイの導入による 運用フローの改善
https://cybozu.connpass.com/event/311067/
Engineering Productivity Meetup #2 in 大阪 での発表資料
Daichi KUDO
April 09, 2024
Tweet
Share
More Decks by Daichi KUDO
See All by Daichi KUDO
登壇は dynamic! な営みである / speech is dynamic
da1chi
0
360
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
3.1k
Hotwireで簡単に非同期処理のユーザー通知を作る / broadcast using Turbo
da1chi
1
160
テストライブラリによってコンポーネントテストの実行時間はどう変わるか / component-test-performance-by-library
da1chi
0
94
Other Decks in Programming
See All in Programming
Leading Effective Engineering Teams in the AI Era
addyosmani
7
650
スマホから Youtube Shortsを見られないようにする
lemolatoon
27
34k
テーブル定義書の構造化抽出して、生成AIでDWH分析を試してみた / devio2025tokyo
kasacchiful
0
320
Introduce Hono CLI
yusukebe
6
3.1k
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
1.2k
「ちょっと古いから」って避けてた技術書、今だからこそ読もう
mottyzzz
12
7.2k
品質ワークショップをやってみた
nealle
0
650
CSC509 Lecture 06
javiergs
PRO
0
270
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
530
AI 駆動開発におけるコミュニティと AWS CDK の価値
konokenj
5
280
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
650
ALL CODE BASE ARE BELONG TO STUDY
uzulla
28
6.8k
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
55
9.1k
The Cult of Friendly URLs
andyhume
79
6.6k
How to train your dragon (web standard)
notwaldorf
97
6.3k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
Documentation Writing (for coders)
carmenintech
75
5.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
2.9k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
Leading Effective Engineering Teams in the AI Era
addyosmani
7
650
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
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 をどうするか