【ぶるーぐりーんでぷろい】
ブルーグリーンデプロイ とは?
最終更新:
💡 新版を別環境で準備し、通信先を切り替える配信方法
現行版と新版の環境を用意し、確認した新版へ利用者のトラフィックを切り替える手法。停止時間の軽減と、データ互換性・切り戻し条件の確認を解説します。
📌 このページのポイント
- 現行版と新版の環境を用意して切り替える
- 新版を確認してから本番の通信を向ける
- 停止時間ゼロや即時の切り戻しを保証するものではない
- 古い版でも扱えるデータや外部連携かを確認する
青と緑で、何を切り替えるの?
現行版を提供する環境とは別に、新版を準備する。新版の動作を確認してから、利用者の通信をそちらへ向ける。青と緑は区別の名前で、図は切り替え前と後の状態を分けているよ。
サービスは、絶対に止まらない?
停止時間を抑えるための手法だけど、保証ではない。通信先を変える仕組みや、処理中の通信、データへの接続なども考える必要がある。環境を二つ用意しただけで、切り替えが成功するわけではないよ。
問題があれば、元に戻せばいい?
古い環境を残すと通信を戻しやすい。ただし、新版が変更したデータや外部への処理も、古い版で扱えるか確認が必要だ。通信先を戻すことと、データや副作用が元に戻ることは別なんだ。
DBの変更は、どう考えるの?
アプリの切り替えと、DBの構造変更を分けて考える方法がある。まず新旧のアプリで扱える変更を行い、古い版が不要になってから削除などを行う。列の追加でも、古いアプリが本当に動くかを検証しよう。
費用は、必ず2倍になる?
総費用が一律2倍になるわけではない。環境を並行して置く時間、共有する資源、検証や運用の作業で変わる。切り戻せる条件を保ちながら、どこまで二つ用意するかを設計するんだ。
もっと詳しく知りたい人へ
古い環境を残せば、古いアプリも使える?
データの構造や内容に互換性がなくなると、古い環境が残っていても動かせない場合があります。AWSのガイドも、不要な項目を削除した後には以前の版が動かなくなる点を説明しています。切り戻しを終える時期と、互換性を失う変更を分けて考えます。
新版を確認したら、すぐ古い環境を消す?
切り替え後の監視や、切り戻しが必要な期間を考えて判断します。新版の確認だけでなく、切り替えと切り戻しの手順、必要なデータへのアクセスも事前に検証します。
まとめ:ざっくりこれだけ覚えればOK!
「ブルーグリーンデプロイ」って出てきたら「新版を別環境で準備し、通信先を切り替える配信方法」と思えばだいたいOK!
📖 おまけ:英語の意味
「Blue-Green Deployment」 = 二つの環境を使うデプロイ手法
💬 青と緑は環境を区別する呼び名です。現行版を提供する環境と、新版を準備する環境を使い分けます。