デプロイタイプ

この講座では、CI/CDにおける様々なデプロイ戦略について学びます。

• 従来のデプロイ（停止を伴う）の特徴
• ローリングデプロイの仕組みとメリット
• ブルーグリーンデプロイの仕組みとメリット
• シャドウデプロイの仕組みとメリット
• カナリアデプロイによる段階的リリース

1. 様々なデプロイタイプ

デプロイを行う方法には、様々なタイプがあります。このセクションでは、代表的なデプロイタイプの種類をいくつか紹介します。

1.1 従来のデプロイ（停止を伴う）

最も基本的なデプロイ方法は、システムを一度停止してから新しいバージョンを反映し、再起動するというものです。たとえば、夜間に社内システムをメンテナンスモードにしてアプリケーションの更新を行うケースがこれにあたります。

この方法のメリットは、構成が単純で確実に入れ替えられる点です。一方で、更新中はシステムが利用できなくなるため、停止が許されないシステムでは運用上の調整が難しくなります。

また、CI/CDパイプラインと組み合わせる場合、ブランチへのマージによって自動的にデプロイが走る「継続的デプロイメント」では、停止のタイミングを制御しにくいため不向きです。

サーバが1台しか存在しない場合や、調整がしやすい社内システムではこの方法が取られることもありますが、一般向けに広く公開されているWebサービスなどでは、なるべく停止を伴わないデプロイ方法が好まれる傾向が強まっています。

1.2 ローリングデプロイ

ローリングデプロイの概要

ローリングデプロイは、ロードバランサーなどを用いて複数台のサーバを運用している場合に有効なデプロイ方法のひとつです。サーバを1台ずつ順番に更新することで、更新中も他のサーバが処理を続けるため、システムを停止することなくデプロイができます。

構成の例を見ていきましょう。ロードバランサーの背後にサーバが3台あり、負荷分散により冗長化構成を行っている環境です。これを新しいアプリケーションにデプロイする際、まずはサーバAだけを更新します。このときサーバAは一時的に停止しますが、サーバBやCが継続して処理を行うため、システム全体は停止せずに稼働を続けます。

サーバAの更新が完了したら、次はサーバB、その次はサーバCというように順番にデプロイを進めます。このように、1台ずつ順番に更新を行うことで、1台が停止しても他のサーバで処理が継続できる仕組みになっています。

ローリングデプロイの特徴

ローリングデプロイの特徴について説明します。まずは、先ほど説明したように、「システムを停止せずにデプロイができる」点があげられます。

また、「コンテナとの相性が良い構成」ともいえます。理由は、コンテナ環境ではタスクやPodといった単位でアプリケーションを個別に更新できるためです。そのため、Amazon ECSやKubernetesなどの環境では、標準でローリングデプロイの仕組みが備わっていることが多いです。

ローリングデプロイの利用シーン

ローリングデプロイの利用シーンですが、まずは「常時稼働が求められるシステム」が挙げられます。システムを停止せずにデプロイできるため、継続稼働が求められる場合には必須の構成といえます。

二つめは「頻繁にアップデートを行うシステム」です。ローリングデプロイは、この後説明する他のデプロイ方法と比べて構成の負担が少なく、デプロイ作業をシンプルに実施できるため、頻繁なアップデートがある場合に適しています。

三つめは「小規模から中規模のシステム」です。ローリングデプロイは特別な構成を必要としないため、他のデプロイ方法と比べると導入しやすい点が特徴です。ただし、堅牢性の観点では他の方式に劣る場合もあるため、大規模なシステムではブルーグリーンデプロイメントなど、より安全性の高い手法を検討するのも有効です。

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

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

ブルーグリーンデプロイメントは、二つの環境を用意し、片方で検証してからトラフィックを切り替えることで、停止や障害のリスクなくリリースを行う方法です。

まず、ロードバランサーなどのトラフィックの転送先を、BlueとGreenの二つに分けます。このBlueとGreenはブルーグリーンデプロイメントにおける便宜上の呼び方で、色自体に意味があるわけではありません。その際、Blueには現行バージョン、Greenには新バージョンをデプロイしておきます。

トラフィックについては、現行バージョンであるBlueに通常のトラフィックが到達するようにし、Green環境は内部的に動作確認を行うための対象として使用します。ここでは本番トラフィックを、一般的なHTTPSのポートである443、テストトラフィックを独自の8443でアクセスする例を示していますが、この構成はあくまで一例です。実際には、ロードバランサーのターゲットグループやルーティングルールを切り替えることで制御するのが一般的です。また、ポートではなくサブドメインやパスで振り分ける方法など、さまざまな構成が可能です。

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

ブルーグリーンデプロイメントの特徴として、「新バージョンをテストしてから切り替えられる」というメリットがあります。CI/CDパイプラインで静的解析やユニットテストを実施することでもある程度の品質は担保できますが、実際の環境にデプロイしてみると、そこでしか見つけられない問題も多くあります。例えば、インフラに起因する障害や、性能に関する問題などは、静的解析やユニットテストでは気づくことが難しい内容です。

また、切り替え自体はBlueとGreenの環境を入れ替えるだけなので、「切り替え後のトラブルを防ぐ」ことができます。それ以外にも、「システムを停止せずに切り替えられる」というメリットがあります。

ブルーグリーンデプロイメントの主な利用シーン

まずは「大規模なリリースや構成変更を安全に行いたい場合」です。ブルーグリーンデプロイメントでは、新バージョンを公開する前に動作確認やテストが行えるため、切り替え前に問題を検知することができます。静的解析やユニットテストでは見つけにくい、実際の環境特有の問題を事前に把握できる点が大きな利点です。

二つ目は「障害発生時にすぐにロールバックしたい場合」です。本番環境と新環境の切り替えは、ロードバランサーの設定変更やポートの切り替えなど、シンプルな操作で実現できます。そのため、もし本番切り替え後にトラブルが発生しても、すぐに旧環境へ戻すことが可能です。

三つ目は「一度に新環境へ切り替えたい場合」です。先ほど説明したローリングデプロイや、このあと紹介するカナリアデプロイは、段階的に切り替えを行う方式のため、一時的に新旧バージョンが混在します。これが許されない要件の場合には、ブルーグリーンデプロイメントが有効な選択肢となります。

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

ブルーグリーンデプロイメントは少し流れが複雑なため、簡単に説明します。

まず、切り替え前の構成ですが、BlueとGreenのどちらも現行バージョンがデプロイされた状態になっています。この段階では、新バージョンをGreen環境に反映する前の準備段階です。通常は本番トラフィックがBlue環境に送られるため、ユーザには現行バージョンが提供される形になります。

まずは、テスト環境であるGreenを新バージョンに移行します。この段階では、本番トラフィックは引き続きBlue環境に送られるため、現行の機能に影響はありません。

続いてテストや動作確認を実施します。テストトラフィックはポート8443を使用するよう設定されているため、8443番ポートでシステムにアクセスすれば、新バージョンの動作確認ができる状態になっています。このポート番号は一例であり、実際の環境に合わせて設定を変更することも可能です。

動作確認が終わったら、本番を新バージョンに切り替えます。切り替えはトラフィックのポートを入れ替える形で行います。今回の例であれば、Blueを8443、Greenを443に変更します。これにより、本番トラフィックはGreenの新バージョンにつながるため、ユーザに新バージョンのシステムを提供できます。

Blue環境は原則としてユーザからアクセスされませんが、デプロイ後は不要となるため、停止することも可能です。

このように、新旧二つの環境を用意し、新システムの動作確認が完了してから本番を切り替える方法をブルーグリーンデプロイメントと呼びます。

1.4 シャドウデプロイ

シャドウデプロイとは

シャドウデプロイは、新バージョンをデプロイした別の環境を用意し、本番環境に流れるトラフィックをミラーリング（コピー）して新環境にも送信し、実際のユーザに影響を与えずに動作を検証する方法です。

ここではShadow環境と呼びますが、この環境ではユーザからのリクエストを本番と同様に受け取り、同じ処理を実行します。ただし、ユーザに返すのは本番環境からのレスポンスのみであり、Shadow環境の処理結果はログやメトリクスとして記録・比較に利用されます。これにより、ユーザへの影響なく新バージョンの挙動を検証できます。

シャドウデプロイの特徴

シャドウデプロイの特徴としては、本番トラフィックを使って新旧の動作を比較できる点が挙げられます。また、本番と同等の負荷やデータ条件でテストできるため、従来のテスト環境では再現しづらい不具合の検知にも有効です。

シャドウデプロイの利用シーン

利用シーンとしては、主に大規模な機能変更やアーキテクチャの刷新を行う場合が挙げられます。このような変更をいきなり本番に適用すると、予期せぬ不具合が発生するリスクがあります。そこで、シャドウデプロイを用いて本番と同じトラフィックで事前検証を行うことで、安全にリリース準備を進めることができます。

また、複雑な本番データ特有の構造やパターンを持つシステムでも有効です。テスト環境では問題がなかったのに、本番データでのみ不具合が起きることは少なくありません。セキュリティの制約で本番データを直接テスト環境に持ち込めない場合でも、シャドウデプロイを利用すれば、本番トラフィックを安全に複製して検証することができます。

1.5 カナリアデプロイ

カナリアデプロイとは

カナリアデプロイは、新バージョンを一部のユーザだけに段階的に公開し、問題がなければ全体へ展開していくデプロイ方法です。

まず、旧環境と新環境の2つの環境を用意します。その上で、DNSの振り分けなどを用いて、トラフィックの80％を旧環境、20％を新環境に振り分けます。こうすることで、20％のユーザにのみ新バージョンを提供することができます。割合を30％、50％、100％と段階的に増やしていくことで、最終的にすべてのユーザを新バージョンへ移行させることができます。

なお、今回はDNSで振り分ける例を示していますが、ロードバランサーなど他の機能を使っても実現可能です。

カナリアデプロイの特徴

特徴としては、一部のユーザに段階的なリリースが可能である点が挙げられます。また、実際のユーザからのフィードバックが得られる点や、実際のトラフィックを使って動作を確認できる点も大きな利点です。

カナリアデプロイの利用シーン

主な利用シーンとしては、まず利用者が多いシステムの新機能リリース時です。利用者が多い場合に一度に切り替えると、問題発生時の影響範囲が大きくなります。一部のユーザに先行して提供することで、万が一の際の影響を最小限に抑えることができます。

次に、インフラ構成やライブラリなど非機能部分の変更時です。機能自体には影響がない変更でも、想定外の動作が起きないかを確認しながら、段階的に展開できます。

さらに、A/Bテストを実施する場合にも活用できます。A/Bテストでは、新旧2つのバージョンを並行して提供し、実際のユーザデータや反応をもとに新機能の有効性を検証します。

2. まとめ

この講座では、様々なデプロイタイプについて学びました。

• 従来のデプロイ（停止を伴う）はシステムを停止して更新する最もシンプルな方法で、CI/CDの継続的デプロイメントには不向き
• ローリングデプロイはサーバを1台ずつ順番に更新してシステム停止なしでデプロイでき、ECSやKubernetesで標準サポートされている
• ブルーグリーンデプロイメントは2つの環境を用意して新環境で検証後にトラフィックを切り替える方式で、即座のロールバックが可能
• シャドウデプロイは本番トラフィックを新環境にミラーリングしてユーザに影響なく動作検証でき、本番データ特有の問題検知に有効
• カナリアデプロイは新バージョンを一部のユーザに段階的に公開し、問題なければ全体展開する方式で、A/Bテストにも活用できる
• デプロイタイプはシステムの要件（可用性、安全性、規模など）に応じて選択することが重要