ブルーグリーンデプロイメント

私と私の同僚が顧客に強く勧める目標の一つは、完全に自動化されたデプロイメントプロセスです。デプロイメントの自動化は、ソフトウェアが「完成」してからその価値を実現するまでの間に発生する摩擦や遅延を削減するのに役立ちます。Dave FarleyとJez Humbleはこのトピックに関する著書「継続的デリバリー」を執筆中です。これは、継続的インテグレーションに一般的に関連付けられている多くのアイデアに基づいており、ソフトウェアを迅速に本番環境に投入して何かを実行できるようにすることを目指しています。彼らのブルーグリーンデプロイメントに関するセクションは、あまり活用されていないテクニックの一つとして私の目に留まったので、ここで簡単に概要を説明したいと思います。

デプロイメントの自動化における課題の一つは、テストの最終段階から本番環境への切り替えそのものです。ダウンタイムを最小限に抑えるために、通常はこれを迅速に行う必要があります。ブルーグリーンデプロイメントのアプローチでは、可能な限り同一の2つの本番環境を用意することでこれを実現します。常にどちらか一方、この例ではブルーとしましょう、が稼働しています。ソフトウェアの新しいリリースを準備する際には、グリーン環境で最終段階のテストを行います。ソフトウェアがグリーン環境で動作するようになったら、すべての受信リクエストがグリーン環境に送られるようにルーターを切り替えます。ブルー環境はアイドル状態になります。

ブルーグリーンデプロイメントは、迅速なロールバック方法も提供します。何か問題が発生した場合は、ルーターをブルー環境に戻します。グリーン環境が稼働している間に発生したトランザクションの欠落に対処する問題は依然としてありますが、設計によっては、ブルー環境をグリーン環境が稼働している間のバックアップとして維持するために、両方の環境にトランザクションを供給できる場合があります。または、カットオーバー前にアプリケーションを読み取り専用モードにして、しばらく読み取り専用モードで実行してから、読み取り/書き込みモードに切り替えることもできます。これは、多くの未解決の問題を洗い出すのに十分かもしれません。

2つの環境は異なる必要がありますが、可能な限り同一である必要があります。状況によっては、異なるハードウェアにすることも、同じ（または異なる）ハードウェア上で実行されている異なる仮想マシンにすることもできます。また、2つのスライスに別々のIPアドレスを持つ別々のゾーンに分割された単一のオペレーティング環境にすることもできます。

グリーン環境を稼働させて、その安定性に満足したら、ブルー環境を次のデプロイメントの最終テストステップのステージング環境として使用します。次のリリースの準備ができたら、以前ブルーからグリーンに切り替えたのと同じ方法で、グリーンからブルーに切り替えます。このようにして、グリーン環境とブルー環境は、稼働、以前のバージョン（ロールバック用）、次のバージョンのステージングの間で定期的に切り替わります。

このアプローチの利点は、ホットスタンバイを機能させるために必要な基本的なメカニズムと同じであることです。したがって、これにより、すべてのリリースで災害復旧手順をテストできます。（災害が発生するよりも頻繁にリリースすることを願っています。）

基本的な考え方は、簡単に切り替え可能な2つの環境を用意することですが、詳細を変更する方法はたくさんあります。あるプロジェクトでは、ルーターで作業するのではなく、Webサーバーを再起動することで切り替えを行いました。別のバリエーションとしては、同じデータベースを使用し、Web層とドメイン層のブルーグリーン切り替えを行うことが考えられます。

データベースは、特にソフトウェアの新しいバージョンをサポートするためにスキーマを変更する必要がある場合、この手法では課題となることがよくあります。コツは、スキーマ変更のデプロイとアプリケーションのアップグレードを分離することです。そのため、最初にデータベースリファクタリングを適用して、新旧両方のバージョンのアプリケーションをサポートするようにスキーマを変更し、それをデプロイし、すべてが正常に機能していることを確認してロールバックポイントを作成してから、新しいバージョンのアプリケーションをデプロイします。（そして、アップグレードが完了したら、古いバージョンのデータベースサポートを削除します。）

この手法は長い間「存在」していましたが、私はそれが本来あるべきほど頻繁に使用されているのを見ていません。Daniel Terhorst-NorthとJez Humbleがこの名前を思いついたのは、何とも不思議な組み合わせです。