最終更新:
ブルーグリーンデプロイの仕組み ― 停止時間を抑えて本番を切り替える方法
新版を確認して通信先を切替
ブルーグリーンデプロイって何なの?色の名前がついてて不思議なんだけど…
へえ!もし新しいバージョンにバグがあったらどうするの?
カナリアリリースやローリングアップデートとは何が違うの?
AWSとかKubernetesだと具体的にどうやって実現するの?
AWSのALBなら新旧のターゲットグループを用意し、リスナールールで転送先を変更する方法があるよ。Kubernetesなら新旧のPod群を用意し、Serviceのselectorで対象を変更する構成が考えられる。ただし新版の準備完了や接続の終了を確認する必要があり、アプリ側の対応が一切不要という意味ではないよ。
データベースも2つ用意するの?
共有DBを使う構成もあるよ。その場合は新旧両方で使える変更を先に入れ、新版へ移した後、旧版へ戻す必要がなくなってから不要な項目を削るのが基本だね。カラム追加も、旧版が追加項目を扱えなければ壊れることがある。『追加なら必ず安全』ではなく、新旧両方で動作を確認するんだ。
環境を2つ維持するってことは、コストも2倍になるんじゃない?
切り替えの瞬間にユーザーのセッションが切れたりしないの?
小さいチームでも使えるの?
注文画面を新版へ切り替える場面で考える
今の注文画面を動かしたまま、別の環境で新しい画面を確認する。準備ができたら、利用者のアクセス先を切り替える。これがブルーグリーンデプロイの入口です。新旧2つの環境を用意することと、すべての問題を切替だけで解決できることは同じではありません。
たとえば新版がDBの項目を削除し、旧版がその項目を必要としていたら、通信を戻すだけでは復旧できません。また、注文処理の途中で旧環境を止めれば、処理中の利用者に影響する可能性があります。
まずテスト環境で「新しい注文を受け付ける」「処理途中の注文を終える」「旧版へ戻してデータを読む」の3場面を書き出してみましょう。どこまで戻せるかを決めると、図の切替先と共有DBの役割がつながります。少しずつ公開する違いはカナリアリリース、入れ替え方はローリングアップデートで確認できます。
参考資料
- Martin Fowler — Blue Green Deployment
- AWS — Blue/Green Deployments on AWS
- AWS — データ同期とスキーマ変更
- AWS CodeDeploy — Deployment configurations
- AWS ALB — Listener rule actions
- AWS ALB — Deregistration delay
- Kubernetes — Service
- Kubernetes — Deployments
- Google Cloud Run — Rollbacks, gradual rollouts, and traffic migration
- Google Cloud Run — Session affinity