ブルーグリーンデプロイとカナリアリリースとは ― 違いと切り戻し

ブルーグリーンデプロイは、新旧2つの環境を用意し、利用者の振り分け先を一度に新しい環境へ切り替える方法です。カナリアリリースは、新しい版を一部の利用者だけに先に出し、様子を見ながら広げる方法です。

どちらも、新しい版を出すたびにサービスを止めたり、不具合を利用者の全員に届けたりしないための方法です。方式によって、必要なサーバの台数と、問題が起きたときに前の版へ戻す速さが変わります。前の版へ戻すことを、切り戻しまたはロールバックと呼びます。

こうした新しい版への切り替え方を、デプロイ戦略と呼びます。CI/CDのパイプラインでは、最後の本番の段でどの方式を使うかを決めます。

いちばん単純な出し方は、古い版をすべて止めてから、新しい版で起動し直す方法です。Kubernetesでは、この出し方をRecreateと呼びます。台数は増えませんが、止めてから起動し終わるまで、利用者はサービスを使えません。

新しい版に不具合があると、起動した直後から利用者の全員がその影響を受けます。戻すには古い版を入れ直すことになり、その間もサービスはまた止まります。この2つの弱点を減らす方式として、次の3つがあります。

ローリングアップデートは、動いているサーバを1台ずつ新しい版に置き換えていく方法です。残りのサーバが要求を受け続けるので、サービスは止まりません。ロードバランサなどの振り分けの仕組みは、準備ができていない新しいサーバには要求を送りません。

増やす台数は少しで済みます。Kubernetesの記事で説明したとおり、Kubernetesは初期設定で、この方式でPodを入れ替えます。そのとき、Podの合計はあるべき数の125%までに抑えます。

その代わり、置き換え終わるまでは古い版と新しい版が混ざって動きます。同じ利用者の要求が、続けて違う版に届くこともあります。切り戻すときは、もう一度古い版へ1台ずつ置き換えるので、台数が多いほど時間がかかります。

ブルーグリーンデプロイでは、できるだけ同じ構成の本番環境を2つ持ちます。いま利用者が使っている方をブルー、新しい版を置く方をグリーンとします。グリーンで最後のテストを終えたら、振り分けを切り替えて、すべての要求をグリーンへ送ります。

切り替えたあとも、ブルーは止めずに待機させておきます。問題が見つかったら、振り分けをブルーに戻すだけで切り戻せます。Martin Fowlerは、すぐに戻せることをこの方式の利点に挙げています。

弱点は、本番と同じ構成をもう1つ持つことです。GoogleのSREの文書は、通常の出し方の2倍の資源を使うと書いています。2つの環境を同じ構成で作るには、構成をファイルに書いて作るIaCが役に立ちます。

どちらをブルーと呼ぶかに決まりはありません。Fowlerは本番で動いている方をブルーとして説明し、GoogleのSREの文書は本番の方をグリーンと呼んでいます。どちらの呼び方でも、2つの環境を交互に使います。片方が本番のとき、もう片方は前の版か次の版の置き場になります。

ホットスタンバイは、予備を動かしたまま待機させる方式です。Fowlerは、切り替える仕組みがホットスタンバイと同じなので、リリースのたびに災害復旧の手順を試せるとも書いています。予備の環境を用意して切り替える考え方は、BCPとDRの記事で説明しています。

カナリアリリースでは、まず新しい版を少数のサーバに置きます。この時点では、利用者を送りません。次に、ごく一部の利用者だけをそこへ送り、エラーの数や応答の速さを古い版と比べます。問題がなければ、新しい版のサーバと送る利用者を少しずつ増やします。

先に送る利用者は無作為に選ぶほか、社内の利用者や1つの地域から始めることもあります。名前は、炭鉱に連れて入ったカナリアに由来します。有毒なガスが漏れるとカナリアが人より先に弱るので、坑夫は危険に早く気づけました。

切り戻すときは、新しい版へ送っていた利用者を古い版へ送り直します。不具合の影響を受けるのは、それまで新しい版へ送っていた一部の利用者だけです。GoogleのSREの文書の例では、要求の20%が失敗する版を利用者の5%に出すと、全体の失敗は1%にとどまります。

この差は、エラーバジェットの減り方に表れます。エラーバジェットは、許される失敗の量です。詳しくはSLA・SLO・SLIの記事で説明しています。エラーバジェットの減る量は、不具合のある版に届いた通信の量に比例するからです。弱点は、広げ終わるまで複数の版を同時に動かし、それぞれを見張り続ける手間がかかることです。

3つの方式は、新しい版に届く利用者の割合の変わり方が違います。次の図は、その割合が時間とともにどう増えるかを並べたものです。

ブルーグリーンでは旧新が混ざる期間がなく、割合は0%から100%へ一度に変わります。ローリングとカナリアでは混ざる期間がありますが、カナリアは少数に出した段階でいったん止めて確かめる点が違います。ローリングは、置き換えた台数に応じて自動で割合が増えていきます。

次の図で方式を選ぶと、4台で動くサービスを更新するときの、段階ごとの台数と利用者の行き先を確かめられます。

どの方式も、新しい版の状態を測る仕組みがあってはじめて役に立ちます。ブルーグリーンでは切り替える前のテストと切り替えた直後の監視、カナリアでは古い版との比較が判断の材料です。変えたサービスだけを出し直すマイクロサービスでは、サービスごとに方式を選べます。

どの方式でも、切り替えの途中や切り戻した後は、古い版のアプリもデータベースを使います。新しい版に合わせて列を消したり名前を変えたりすると、古い版が動かなくなり、切り戻せなくなります。そこで、データベースの変更は、新旧どちらの版でも動く形で先に出します。

列の名前を変える場合は、次の順に進めます。

1. 新しい名前の列を足し、古い列も残す。古い版も新しい版も動く形にする
2. 新しい版のアプリを、どれかの方式で出す
3. 古い版のアプリが要らなくなってから、古い列を消す

Danilo Satoは、この進め方をパラレルチェンジと呼んでいます。エキスパンド・アンド・コントラクトとも呼ばれます。互換性のない変更を、広げる・移す・縮めるの3段階に分けて安全に進めます。Fowlerも、ブルーグリーンでは、スキーマ（データベースの表の構造）の変更をアプリの更新と分けて出すよう勧めています。

ブルーグリーンで2つの環境が別々のデータベースを持つ場合は、別の問題も残ります。グリーンが本番だった間に書き込まれたデータは、ブルーに戻すとそのままでは見えません。Fowlerは、両方の環境に取引を送る作りや、切り替えの前に読み取りだけの状態で動かす工夫を挙げています。

• Martin Fowler「BlueGreenDeployment」（2010年3月。2015年6月にデータベースの段落を追記）
• Danilo Sato「CanaryRelease」（2014年6月）
• Danilo Sato「ParallelChange」（2014年5月。エキスパンド・アンド・コントラクト）
• Kubernetes Docs「Deployments」（RecreateとRollingUpdate、ロールバック）
• Google「The Site Reliability Workbook」Chapter 16「Canarying Releases」