デプロイに伴うダウンタイムが好ましくないのは、クラウドの登場以前も同じでした。 多くの企業は、アプリケーションをホストする従来のデータセンターでローカル ユーザーからのアクセスに制限を設け、ユーザーによるアプリケーションの利用頻度が低い深夜などの時間にデプロイ スケジュールを設定するといった工夫をしていました。 クラウドをベースにした 24 時間年中無休の環境が広く普及すると、あらゆるタイムゾーンから四六時中アクセスが来るようになり、デプロイを設定しやすい時間帯はなくなりました。 現在はどの企業でも、アプリケーションを利用するかもしれないすべてのユーザーに対して、アクセスできない時間帯を作らないことが課題になっています。

以前は、変更や更新のデプロイ時にアプリケーションをオフライン状態にする手法が一般的で、これによってダウンタイムが発生していました。 現在では、アプリケーションのビルドからテスト、デプロイまで自動化する継続的インテグレーション & 継続的デプロイメント (CI/CD) パイプラインを使用することで、デプロイ プロセスにかかる時間を短縮し、環境のアップタイムを最大限に維持できます。 とはいえ、アプリケーションのデプロイや環境の更新でダウンタイムなどの問題が生じる可能性を、完全にゼロにすることはできません。

この記事では、ダウンタイムをほぼゼロにするために広く使用されている 2 つの手法について解説します。その 2 つとは、ブルーグリーン デプロイメント構成とカナリアリリース構成です。 また、それぞれの要件やメリットとデメリットについても、いくつかご紹介します。

デプロイに伴うダウンタイムをゼロに

エンドユーザーが気づくような影響を生むことなく、必要なときにいつでもアプリケーションや機能をデプロイできる体制を作る。現代の企業にとってこれは最大の目標であり、モダン アプリケーション アーキテクチャや、定評のある CI/CD パイプラインを採用する意図もそこにあります。 目標の実現には、重要なタスクを実行しているユーザーや、システムが深くかかわっているミッションクリティカルなプロセスを遮ることなく、変更を本番環境にすばやく安全にデプロイできる必要があります。

デプロイに伴うダウンタイムの最小化や一掃を目指すうえで、アプリケーションとデプロイのアーキテクチャはきわめて重要な役割を担います。カナリアリリースであってもブルーグリーン デプロイメントであっても、環境は通常、次の要件を満たす必要があります。

  • アプリケーションをビルド、テストし、特定の環境にデプロイできるデプロイ パイプラインがある。
  • 複数のアプリケーション ノードまたはコンテナがロード バランサーの配下に分散配置されている。
  • アプリケーションがステートレスで、クラスタ内のノードがいつでもリクエストを処理できる。

また、アプリケーションに変更を加える際には、データ レイヤーを破壊しないようにする必要があります。 言い換えると、データセット内の列は optional または nullable に設定し、列の名前を変更したり列を別の用途に再利用したりしないようにする必要があります。 データを破壊しないアプローチをデータ レイヤーに採用すれば、問題が発生した場合でも、変更をロールバックしたり機能を元に戻したりすることができます。

上記の要件を念頭に置きながら、ダウンタイムをゼロに抑えるデプロイ オプションの 1 つ目、”ブルーグリーン デプロイメント” を詳しく見てみましょう。

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

カナリアリリースよりも広く採用されているブルーグリーン デプロイメントでは、アプリケーション環境をリソースの等しい 2 つのセクション (ブルーとグリーン) に “分割” します。 ロード バランサーでトラフィックを制御して、一方のセクション (ブルー環境) で現行のアプリケーションを実行します。 そして、もう一方のセクション (グリーン環境) に新しいアプリケーションをデプロイします。こうすることで、ブルー環境に影響を与えずに、新しいアプリケーションをデプロイできるのです。

ロード バランサーを使ってトラフィックを転送することで、本番ユーザーに対してはブルー環境を通常どおりに稼働させながら、グリーン環境でテストやデプロイを行うことができます。デプロイとテストが成功したら、後はロード バランサーのターゲットをグリーン環境に切り替えるだけ。ユーザーに変更が気づかれることはありません。

このようにアプリケーション環境をセットアップすることには、他にもさまざまなメリットがあります。 たとえば、アプリケーションの負荷が高い場合や、ディザスタ リカバリ措置の一環として、グリーン環境を即座にホットスタンバイ環境として稼働させることができます。

カナリアリリースとは？

カナリアリリースとは、大部分がブルーグリーン デプロイメントと同じなのですが、少しだけ異なる点があります。 カナリアリリースでは、まったく同じ環境を 2 つ用意しておいてデプロイの完了時に切り換えるのではなく、1 つの環境内にあるサーバーやノードの一部だけをカットオーバーして、他よりも先行してアプリケーションをデプロイします。

カナリアリリース向けに環境をセットアップする方法はさまざまです。最もシンプルな方法は、ロード バランサーの配下に通常どおりに環境をセットアップしたうえで、追加でノードまたはサーバーをアプリケーションの規模に応じて 1 ～ 2 台、未使用のスペアとして確保する構成です。 このノードまたはサーバーのスペア グループを、CI/CD パイプラインのデプロイ ターゲットにします。 このグループでビルド、デプロイ、テストが完了したら、ロード バランサーに追加して、一部のユーザーが期間限定で使用できるようにします。こうすることで、変更によって問題が生じないことを確認してから、クラスタ内の他のノードやサーバーへのデプロイを進められます。

カナリアリリースには他にも、”機能トグル (フィーチャー トグル)” や “機能フラグ (フィーチャー フラグ)” と呼ばれる開発パターンを使用する構成方法があります。 フィーチャー トグルとは、変更をビルドしてデプロイするアプリケーションに対して、明示的にオンに切り換えない限り変更内容が有効にならない設定を加える手法です。 先ほどと同じく、クラスタからノードを 1 台切り離し、この設定を加えたアプリケーションをデプロイして、元に戻します。今回は、ロード バランサーを使用して何かをテストしたり制御したりする必要はありません。 すべてのノードを更新したら、全ユーザーに機能をロールアウトする前に、数人のユーザーに対して機能をオンに切り換えて動作を確認します。

ただし、この方法には、フィーチャー トグルをサポートするようアプリケーションに手を加えるための時間とコストがかかるというデメリットがあります。 アプリケーションの経過年数や規模にもよりますが、このような機能の開発は、きわめて複雑であったり、ほとんど不可能であることもあります。

ブルーグリーン・デプロイメントとカナリアリリース: どちらを選ぶべき？

では、ダウンタイム ゼロのデプロイを実現するには、ブルーグリーンとカナリアのどちらの手法が最適なのでしょうか。 どちらもデプロイ手法として効果的であり、非常に似たアーキテクチャを使用しますが、それぞれに独自の特徴もあります。

アプリケーション ホスティング環境全体を 2 つ用意できるキャパシティがあり、アプリケーションが主に下位互換性を維持したまま変更される場合には、ブルーグリーン デプロイメントが適しています。ブルーグリーン デプロイメントなら、アプリケーションの変更は最小限で済み、副次的なメリットを最大限に活用できるからです。つまり、構築したダウンタイム ゼロの環境を、パフォーマンスの問題が発生した場合や災害復旧の際にも使用できるのです。

一方、プロビジョニングできる追加リソースの量が限られている場合や、アプリケーションがモジュール化されていて構成に重きが置かれている場合には、カナリアリリースのほうが適しています。 他の用途に利用できるスペア環境は手に入りませんが、環境の運用と保守にかかる費用を最小限に抑えることができます。 また、カナリアリリースなら、任意のタイミングで、あるいは任意の基準に基づいて、機能の有効と無効を簡単に切り換えることができます。

ただし、どちらの手法であっても、事前にしっかりと計画を立て、アプリケーションや環境のアーキテクチャについて考える必要があります。

まとめ

ブルーグリーンとカナリアのどちらのデプロイ手法も、ダウンタイムや作業の中断を生じることなくアプリケーションをデプロイするのに効果的です。 これを実現するには、環境やアプリケーションで使用の必要な機能がある点に注意してください。中でも、負荷分散やステートレス アーキテクチャは重要です。 環境の更新や変更の際にデプロイを自動化し、一貫性を維持する機能も、ダウンタイム ゼロの実現には欠かせません。 アプリケーション環境のデプロイ、テスト、カットオーバーの自動化には、CI/CD パイプラインを活用するのがとても便利です。

カナリア型とブルーグリーン型のデプロイメント戦略について理解が深まりましたでしょうか。この記事が、みなさんの会社に最適な戦略の選択とダウンタイムのないアプリケーション デプロイのお役に立てば幸いです。 ぜひ、すぐに使い始められる CircleCI の無料トライアルをご活用ください。