ひょんなことからカナリアリリースについて調べていたら、類似概念と比較したくなりました。その時のやつです。
まえがき
現代のWebサービス開発では、新しい機能やソフトウェアの更新をユーザーに迅速に届けながら、不具合による大規模障害のリスクを抑えることが重要な課題です。これを実現するための戦略の一つがカナリアリリースです。カナリアリリースとは、新しいバージョンをまず一部のユーザーに限定してリリースし、本番環境でその動作や影響を注意深く観察した上で、問題がなければ段階的に全ユーザーへ展開していく手法です。この名前は炭鉱でカナリアが有毒ガスの警告役となった逸話に由来しており、ごく少数のユーザーグループを「炭鉱のカナリア」に見立ててリスクを早期に検知し大きな被害を防ぐという思想に基づいた戦略です。
全ユーザーに対する一斉リリース（ビッグバンリリース）では、新バージョンに致命的な不具合があると全ユーザーに影響が及び、大規模障害につながるリスクがありました。これに対しカナリアリリースでは、例えばまず全体の1%や5%といった少数のユーザーだけが新バージョンを利用するようにし、得られたフィードバックやエラーレート・応答時間などのパフォーマンスデータを分析します。問題がなければ新バージョンの公開範囲を10%、30%、50%...と徐々に拡大し、最終的に100%のユーザーに新バージョンを公開します。もし途中で不具合や性能低下などの問題が見つかった場合は、リリースを即座に中止して影響範囲を最小限にし、該当ユーザーを旧バージョンに速やかにロールバックします。このようにカナリアリリースは、本番環境という現実的な利用状況の中で新バージョンをテストしつつ、万一問題があってもその影響を極小化できるため、リリース速度と安全性の両立を図る事ができる手法として知られています。
ところで、世の中には他のデプロイ戦略（ブルーグリーンデプロイメント、ローリングリリース、A/Bテスト）も存在します。これらにはどのような違いがあるのでしょうか。今回はカナリアリリースを起点として、それぞれの手法の概要とメリット・デメリットを順に説明します。
ブルーグリーンデプロイメントとの違い
ブルーグリーンデプロイメントは、本番環境を2つ用意してリリースを行う手法です。現在稼働中の本番環境（ブルー環境）とは別に、同じ構成の新バージョン用の環境（グリーン環境）を用意し、新バージョンをそちらにデプロイします。リリース時にはロードバランサーの切り替えなどにより、全ユーザーのトラフィックを一度にブルー環境からグリーン環境へ切り替えます。こうすることでユーザーから見るとダウンタイムなしに新バージョンへ移行でき、一瞬で全ユーザーが新環境を利用する状態になります。
カナリアリリースとブルーグリーンデプロイの最大の違いは、新バージョンへの移行を段階的に行うか一度に行うかという点です。カナリアリリースでは実際の本番ユーザーの一部分から徐々に検証してリスクの早期発見を図るのに対し、ブルーグリーンでは本番への段階的検証は行わず切り替え前にテスト環境で十分に検証を行った上で、一度の切り替えでリリースします。どちらの手法もロールバックは容易で、問題が見つかった場合にはロードバランサーの向き先を元の安定稼働中の環境に戻すだけで、即座に旧バージョンへ復旧できます。
ブルーグリーンデプロイメントの大きなメリットは、リリース時にサービス停止の時間を発生させずに安全な切り替えができる点と、切り替え前に新バージョン環境で十分テストできる心理的安全性にあります。またカナリア方式と同様、切り戻しもスイッチ一つで迅速に行えます。一方でデメリットとしては、本番環境を丸ごと2セット維持するインフラコストの高さが挙げられます。常に同規模の環境を二重に用意する必要があるため、リソースに余裕がない場合は負担が大きくなります。これに対しカナリアリリースは、新バージョン用の環境をまず小規模から始められるため、必要な追加リソースを抑え柔軟に運用できる利点があります。
実務での使い分けとしては、ブルーグリーンデプロイメントはダウンタイムを絶対に許容できないミッションクリティカルなシステムにおいて有効です。またデータベースの変更といった大規模なインフラ変更を伴うリリースでも、事前に同等環境で検証できるブルーグリーンが安心です。ただし、お財布との相談は必要です。一方で、カナリアリリースは新機能がユーザー行動やビジネス指標に与える影響を慎重に見極めたい場合や、性能への影響が未知な変更を安全にリリースしたい場合に適しています。一部のユーザーで検証して問題が発生した時は即座にロールバックすることで、サービス全体への影響を最小限に抑えることができます。
ローリングリリースとの違い
ローリングリリースは、複数台のサーバーで動作するアプリケーションを順番に少しずつ新バージョンへ更新していく手法です。例えば本番サーバーが10台ある場合、新バージョンをまず1台目にデプロイし、正常に稼働したら次に2台目...というようにサーバー単位で順次アップデートしていきます。更新中の期間は古いバージョンと新しいバージョンのサーバーが混在しますが、最終的には全てのサーバーが新バージョンに置き換わります。この方法ではサービス全体を停止する必要がなく、ユーザーから見ると段階的に更新が行われるためダウンタイムなしでのリリースが可能です。
カナリアリリースとの違いとしては、トラフィック制御の精度とロールバックの容易さが挙げられます。カナリアリリースではユーザー全体の1%だけを新バージョンに割り当てるなど、新旧バージョンへのトラフィック分配をかなり細かく制御できます。しかし、ローリングリリースでは基本的にサーバー単位で更新が進むため、トラフィックの新旧割合は更新済みサーバー台数の比率に依存します。例えば10台中2台を新バージョンにした時点で、新バージョンに約20%のユーザーがアクセスする計算になり、任意の割合のユーザーに対して分配を制御することは難しいです。またロールバックについても、カナリアリリースならトラフィックの向きを旧バージョンに戻すだけで済むのに対し、ローリング方式では既に更新してしまったサーバーに再度旧バージョンをデプロイし直す作業が必要になります。そのため迅速さや簡易さで劣り、混在状態だったシステムを元に戻すのはやや複雑です。
ローリングリリースのメリットは、追加のインフラをほとんど用意せずにすむためコストが低く、仕組みも比較的シンプルで容易に導入できることです。専用の複製環境や特殊なトラフィック分割機構が不要なので、小～中規模のチームでも実践しやすく、現在広く使われている手法です。デプロイのたびに大掛かりな環境を用意できない場合や、ごく小さな変更でリスクも低いリリースであればローリング更新で十分対応できます。しかしデメリットとして、カナリアリリースほど細かなユーザー影響のコントロールや監視には適さず、更新中は本番環境内に新旧バージョンが混在するので互換性の問題に注意が必要です。また前述のとおり不具合発生時の対応がカナリアやブルーグリーンより手間になる点も考慮すべきでしょう。
実務では、ローリングリリースは変更内容が小さくリスクも低いアップデートや、複雑なトラフィック制御・監視体制までは必要ない場合に有効です。できるだけダウンタイムなく展開したいが追加コストは抑えたいケースなどで有効です。一方、リスクが高い大きな変更やパフォーマンス影響が読めない場合には、より慎重に段階展開でき、かつ即時ロールバックも可能なカナリアリリースが適しています。
A/Bテストとの違い
A/Bテストはデプロイ戦略というよりマーケティング手法に分類されるものですが、カナリアリリースと混同されやすい概念です。A/Bテストでは、UIデザインや新機能の異なる2つ以上のバージョンを用意し、ユーザーをランダムにグループ分けして各グループに別々のバージョンを提示することで、どちらがより良い成果（コンバージョン率やクリック率など）を生むかを比較検証します。つまり、プロダクトを改善したときに得られる効果をデータを基に測るための実験的な手法です。
技術的な実装としては、ユーザーごとに異なるバージョンへトラフィックを振り分けるという点ではA/Bテストもカナリアリリースも似ていますが、目的は根本的に異なります。カナリアリリースの主な目的が、不具合や性能問題の早期発見、対応新バージョンに潜む技術的リスクの低減であるのに対し、A/Bテストの目的はプロダクトのビジネス上の成果を最大化することにあります。つまりA/Bテストではどちらのデザインや機能がユーザーにより支持され業績向上に寄与するかを評価するのがゴールであり、効果の低かったバージョンは最終的に廃止して効果が高いバージョンだけを採用するといった判断が行われます。一方、カナリアリリースではあくまで新旧バージョンの優劣ではなく新バージョンの安全性を検証することが目的であり、問題がなければ最終的に全ユーザーがその新バージョンを使う状態に移行します。
A/Bテストのメリットは、ユーザー体験や機能の複数案を本番で同時に試しデータに基づいて意思決定できることです。例えば新しいUIデザインが売上に与える影響を実ユーザーで測定し、より良い方を選択できます。プロダクト開発において実証データで最適解を選ぶためのアプローチとして非常に有効です。しかしデメリットとして、A/Bテスト中は劣ると判定される方のバージョンを一部ユーザーに提供する必要があるため、一時的にユーザー体験が最適でない可能性があります。また、同時に複数バージョンを走らせて結果を計測するための実装・分析のコストもかかります。何よりA/Bテストは品質保証というよりプロダクト改善のための手法です。サービスの安定性確保という観点では、A/Bテストだけでは不十分であり、カナリアリリースやブルーグリーンなどと組み合わせてリスク低減を図ることが望ましいでしょう。
ちなみに、カナリアリリースとA/Bテストは併用も可能です。例えばまず新機能をカナリアリリースで一部ユーザーに提供して安全性を確認しつつ、そのユーザー群の中でさらにA/Bテストを行って機能の効果を測定するといった応用例も考えられます。
各手法のメリット・デメリットとユースケース
最後に、今まで紹介した概念の特徴をまとめます。それぞれメリットとデメリットが異なり、適したシチュエーションも変わってきます。
カナリアリリース
リリースの安全性を高める手法で、小規模なユーザーグループで検証しながら段階的に展開します。メリットは不具合の早期発見と影響範囲の限定ができることで、リリース失敗のリスクを最小化できます。本番環境で新バージョンを試せるため予期せぬ問題も検知しやすく、問題発生時は即座に旧版へ切り戻せます。デメリットは段階展開とモニタリングの仕組みが必要なため導入の複雑さや監視コストが増すこと、リリース完了までに時間がかかる場合があることです。インフラ的にも新旧を並行稼働させる余裕が求められますが、その分リリースの安心感が得られるため、高リスクな変更や未知の影響を伴う機能追加に向いています。
ブルーグリーンデプロイメント
本番環境を二重に用意して新旧を入れ替える手法です。メリットはダウンタイムなしで確実にリリースでき、問題時のロールバックも即座に可能な点です。切り替え前に新環境で十分テストできるため、本番投入後の想定外の不具合発生リスクを下げられます。デメリットは環境を二重に維持するコストで、本番と同規模の待機環境を用意する必要があります。したがって資金やリソースに余裕が必要です。ミッションクリティカルなサービスや絶対に停止できないシステム、あるいは大掛かりなシステム更改に適しており、費用対効果の観点で慎重に採用が検討されます。
ローリングリリース
低コストで取り組みやすい段階的リリース手法です。メリットは追加リソースが少なくて済み、既存サーバー群を順に更新するだけなのでシンプルで自動化もしやすい点です。徐々に更新するためユーザーへの影響も緩やかで、一般的な機能修正で広く用いられます。デメリットは、新旧バージョンが混在することによる不整合のリスクや、トラフィックを厳密にコントロールできないこと、そして問題発生時の復旧に時間がかかることです。一部のサーバーを旧版にデプロイし直す必要があるため、即座には元に戻せません。したがって小規模な変更や低リスクのアップデートに向いており、重大な変更には向きません。大きな不安要素がある場合は、より安全策のカナリアやブルーグリーンを検討すべきでしょう。
A/Bテスト
データ駆動の機能評価に適した手法です。メリットは、本番ユーザーの反応を見ながら施策の良し悪しを判断できることで、新機能やUI改善の効果を定量的に測定できます。ただ、リリース戦略というより実験手法なので、デメリットとしては安定性確保には寄与しない点が挙げられます。片方のグループには意図的に別バージョンを当てるため、一貫した品質提供という観点では不利になります。また実装・分析の手間もかかります。したがってA/BテストはマーケティングやUI改善の場面で威力を発揮しますが、リリースの安全性を高める目的においては単独では使わずに、カナリアリリース等と併用してリスク低減と効果検証の両立を図るのが望ましいです。
まとめ
以上のように、カナリアリリースは、誤解を恐れずに言えば、少しずつ慎重に新機能を世に出す安全志向のリリース方法であり、ブルーグリーンやローリングといった他の戦略と比べてリスク低減に重きを置いた手法です。ただ、すべての状況においてカナリアリリースが有効かと問われるとそうではなく、プロジェクトの重要度や変更内容の性質、許容できるコストや労力に応じて、これらの手法を適切に使い分けることが安定したサービス提供には不可欠です。ユーザーへの影響を最小限に抑えながら継続的な機能改善を実現するためにも、我々はそれぞれのメリット・デメリットを理解し、システムの状況に合ったデプロイ戦略を選択することが求められます。