こんにちは。アプリケーションサービス部の兼安です。
今回は、デプロイ戦略の中の一つ、Blue-Green デプロイのメリットについて掘り下げて書きたいと思います。
記事中では、デプロイは、リリース作業の一環で新しいコードを本番環境に反映させる手法を指しているとします。
デプロイ戦略の概要
Blue-Green デプロイの話をする前に、デプロイ戦略全体の話をします。
DevOpsやCI/CDにおいて、サーバーへのソースコードの展開（＝デプロイ）する手法にはいくつかのパターンがあります。
これらの各パターンをデプロイ戦略、またはデプロイポリシーと呼びます。
各デプロイ戦略は特徴を持っており、それぞれにメリット・デメリットがあります。
デプロイ戦略の比較表
| デプロイ戦略 | ダウンタイム | ロールバックの容易性 | ユーザーへの影響度 | 複雑性 | コスト |
|---|---|---|---|---|---|
| Blue-Green デプロイ | なし | 高 | 中 | 高 | 高 |
| Immutable デプロイ | なし | 高 | 中 | 高 | 中 |
| Rolling デプロイ | 部分的 | 中 | 高 | 中 | 中 |
| In-place デプロイ | あり | 低 | 高 | 低 | 低 |
| Canary デプロイ | なし | 高 | 低 | 高 | 中 |
各デプロイ戦略の概要
Blue-Green デプロイ
Blue-Green デプロイは、2つの環境を用意し、それらを切り替えることでデプロイを行います。
こちらが本記事で取り上げるデプロイ戦略です。
詳細は後述します。
Immutable デプロイ
Immutable デプロイは、新しいリリースのために新しいインスタンスを作成し、古いインスタンスを削除します。
これにより、デプロイの一貫性と可逆性が保証されます。
Blue-Green デプロイとよく似ていますが、Immutable デプロイは、何か問題が発生した場合は古いインスタンスを作り直します。
都度インスタンスを作り直すため、必然的に手順を固めて自動化することになります。
Rolling デプロイ
Rolling デプロイは、新しいバージョンを段階的にリリースします。
一部のインスタンスを停止、新しいバージョンをデプロイし、その後にそのインスタンスを再起動します。
これを全インスタンスに対して繰り返します。
いずれかのインスタンスが常に稼働しているため、ダウンタイムを回避できます。
In-place デプロイ
In-place デプロイは、新しいバージョンを既存のインスタンスに直接デプロイします。
これは一番シンプルな方法ですが、デプロイ中はシステムが停止します。
Canary デプロイ
Canary デプロイは、新しいバージョンのアプリケーションを少数のユーザーに提供します。
利用者の反応や負荷・エラーの状況見ながら徐々に新機能に移行する方法です。
問題が発生した場合、すぐにロールバックすることが可能です。
影響を受けるユーザーを最小限に抑えることができます。
Blue-Green デプロイとは
Blue-Green デプロイは、デプロイ戦略の一つです。
以下のような特徴があります。
- デプロイの成功率が高い
- ダウンタイムが少ない
- ロールバックが容易
Blue-Green デプロイは、2つの環境を用意し、それらを切り替えることでデプロイを行います。
Blueで現行が動いているとしたら、Greenに新しいバージョンのコードをデプロイします。
Greenへのデプロイとテストが完了したら、BlueからGreenへのトラフィックを切り替えます。
次のリリースの時は、逆の作業を行います。
こうすることにより、デプロイの成功率を高め、ダウンタイムを極めて少なくすることができます。
また、切り替える前の環境が残っているので、何かあった時はGreenからBlueに再度切り替えることでロールバックが容易にできます。
ちなみに、本記事では取り上げていませんが、DBサーバー（RDS）もBlue-Green デプロイが可能です。
デプロイの成功率を高めるとは何のことを言っているのか？
そもそも、デプロイが失敗するとはどういうことなのでしょうか？
手順の誤りなら手順書の整備や、自動化で解決できるように思えます。
デプロイが失敗する理由はいくつかありますが、私が経験した中で遭遇したケースに、「ファイルがロックされていて上書きできない」があります。
稼働中のシステムがモジュールや一時ファイルをロックしてしまい、デプロイ時に上書きができないというものです。
これらは手順書の整備や自動化で解決するのは難しいです。
もちろん、完全にシステムを停止してデプロイすれば成功しますが、そうするとダウンタイムが発生します。
ダウンタイムを発生させず、かつデプロイの成功率を上げる。
これを実現するために、稼働中の環境とは別の環境で安全にデプロイしてから切り替える。
これが、Blue-Green デプロイの考え方です。
ダウンタイムの影響は思ったより大きい
ダウンタイムは、ダウンタイムそのものの数字以上に影響力を持ちます。
ダウンタイムがあるということは、事前告知とメンテナンス画面が必要になります。
関係者に連絡し、ダウンタイム中の操作を避けるよう調整してもらう必要があるはずです。
メールや電話でのやりとりだけでなく、チャットや掲示板での告知も必要になるでしょう。
Webサービスならサイト上での告知も必要になります。
告知作業と関係者とのやりとり、関係者が業務調整の時間を考えると、気が重くなりますね。
また、ダウンタイム中はメンテナンス画面が必要になるでしょう。
再度私の経験の話をしてしまいますが、メンテナンス画面は人・現場によって実装がまちまちで、リリースのトラブルの原因になることがあります。
メンテナンス画面を出さなくて済むなら、それに越したことはないと思います。
以上のように、ダウンタイムをなくすということは、単純に稼働率を上げる以上のメリットがあります。
開発者視点だと、ダウンタイムに伴う雑多な手間をなくし、工数の削減とトラブルの防止にも繋がります。
利用者視点だと、作業が中断されないことによる効率性の維持、システムが中断されないことによる機会損失の防止に繋がります。
ロールバックの容易性の価値
リリース後にロールバックを行うケースで、私がすぐに思いつくのは、リリース後にバグが見つかるケースです。
バグフィックスのリリースを待てないのなら、ロールバックするしかありません。
このロールバック作業は、リリースよりも更に気を使わなければなりません。
Blue-Green デプロイなどを使わず、リリースにダウンタイムが発生する構成だとしたら、リリースでダウンタイムが起きたばかりなのに、ロールバックでまたダウンタイムを発生させることになります。
・・・印象が悪いですね。
ロールバック作業に失敗し、二次被害が起きると、更に印象が悪くなります。
これを繰り返すと利用者との信頼関係が崩れてしまうでしょう。
Blue-Green デプロイで、リリース前の環境を残しておけば、少なくともソースコードのロールバックは安全かつ迅速にできます。1
安全に戻せる方法を確保しておくことは、余裕を持ったリリースを行うことにもつながります。
最後に
今回は、Blue-Green デプロイのメリットについてできるだけ掘り下げてみました。
リリース作業の改善を考えている方の、参考になれば幸いです。
サーバーワークスでは、Blue-Green デプロイをはじめとする開発プロセスを最適化する技術を用いたDevOpsの導入支援を行っています。
- ソースコードではなく、データの中身については簡単にロールバックしてよいとはならないでしょう。 これについては別の機会に書きたいと思います。↩
