カナリアリリース

概要

カナリアリリースは、新しいバージョンをいきなり全ユーザーに公開するのではなく、まずごく一部のトラフィック（たとえば全体の5%）だけに流して様子を見て、問題がなければ 25% → 50% → 100% と段階的に対象を広げていくデプロイ手法です。名前の由来は、かつて炭鉱夫が有毒ガスの検知のためにカナリアを連れて坑道に入った故事にあります。人間より先にカナリアが異変を示すことで危険を早期に察知したように、少数のユーザーに「先に新バージョンを踏んでもらう」ことで、全体に被害が及ぶ前に問題を検知するのです。

CI/CD パイプラインで自動デプロイが日常になった現代でも、「本番で初めて発覚する問題」は無くなりません。テスト環境では再現しない負荷特性、実データの偏り、特定の端末や地域だけで起きる不具合 — こうした「本番でしか分からないこと」を、影響範囲を意図的に小さく絞った状態で確かめるのがカナリアリリースの役割です。Kubernetes やサービスメッシュ、各種クラウドのロードバランサが標準機能として重み付きルーティングを提供するようになり、大規模サービスでは標準的な手法になっています。

なぜ生まれたか

かつてのデプロイは「一斉切り替え」でした。全サーバのバイナリを新バージョンに入れ替えた瞬間、すべてのユーザーが同時に新コードを踏みます。もしそこに重大なバグがあれば、影響は即座に全ユーザーに及び、気づいてロールバックするまでの数分〜数十分が丸ごと障害時間になります。テストをどれだけ充実させても、本番環境特有の条件 — 実トラフィックの量と質、実データ、他システムとの相互作用 — を完全には再現できないため、「デプロイは毎回全ユーザーを巻き込む賭け」という構図から抜け出せませんでした。

カナリアリリースはこの賭けの掛け金を小さくする発想です。「バグをゼロにしてからリリースする」のではなく、「バグは出るものと認め、出たときの被害範囲（ブラストラディウス）を最小化する」方向に問題を組み替えました。全ユーザーの5%で異常が出たなら、被害は5%で食い止められ、残り95%は何も知らずに旧バージョンを使い続けられます。これはSRE が掲げる「信頼性はリスク管理である」という考え方の実践であり、エラーバジェットを無駄遣いしないためのリリース設計でもあります。

詳細

仕組み — 重み付きルーティングと段階的拡大

カナリアリリースの土台は、旧バージョン（stable）と新バージョン（canary）を本番環境に同時に稼働させ、ロードバランサやリバースプロキシがトラフィックを重み付きで振り分けることです。最初は canary に 5% 程度だけを流し、メトリクスを観察して問題がなければ徐々に比率を上げ、最終的に 100% にして旧バージョンを退役させます。

振り分けの実装にはいくつかの方式があります。最も単純なのはサーバ台数比による振り分け（10台中1台だけ新バージョンにする）ですが、リクエストごとにランダムに振り分けると同じユーザーが新旧を行き来してしまうため、実務ではユーザーIDや Cookie に基づくスティッキーな振り分けがよく使われます。また「社内ユーザーだけ」「特定の地域だけ」といった属性ベースのカナリアもあり、この場合は割合ではなく対象セグメントを段階的に広げていきます。

判定 — メトリクスが合否を決める

カナリアリリースの成否を分けるのは、「カナリアが健全かどうか」を何で判定するかです。人間が目視でダッシュボードを眺める運用でも成立はしますが、本領を発揮するのは判定を自動化したときです。エラー率・レイテンシ・リソース使用量といったメトリクスを stable 群と canary 群で比較し、canary が統計的に悪化していれば自動でロールバックする — この「メトリクス比較による自動昇格・自動ロールバック」を実現するのが、Argo Rollouts や Flagger、Spinnaker といったプログレッシブデリバリーのツール群です。

ここで重要なのは、新旧を同一条件で比較することです。canary のエラー率を過去の平常値と比べるのではなく、「同じ時間帯に同じ種類のトラフィックを受けている stable 群」と比べることで、時間帯変動やトラフィックの偏りの影響を打ち消せます。判定の材料をそろえるにはモニタリング基盤が新旧バージョンをラベルで区別してメトリクスを収集できることが前提で、判定基準そのものは SLO と揃えておくのが定石です。「SLOを脅かす変化はリリースしない」という一貫した基準ができます。

落とし穴と設計上の注意

カナリアリリースは万能ではありません。まず、新旧バージョンが本番に同時に存在するため、両者が互換でなければなりません。特にデータベースのスキーマ変更は、新旧どちらのコードからも読み書きできる互換な形で行う必要があります（一気に変えず、追加→移行→削除と段階を踏む展開が定石です）。次に、発生率の低いバグは少数トラフィックでは観測されにくく、5% で問題なしと判定しても 100% で顕在化することがあります。各段階の観察時間と統計的な検出力はトレードオフの関係にあり、慎重にしすぎるとリリースが何日もかかるという運用コストも生じます。

また、カナリアで検出できるのは「メトリクスに現れる問題」だけです。計算結果が静かに間違っているような不具合は、エラー率にもレイテンシにも出ません。何を観測すれば異常と言えるかを設計するオブザーバビリティの成熟度が、そのままカナリアの検出力を決めます。

ブルーグリーンデプロイ・フィーチャーフラグとの使い分け

ブルーグリーンデプロイは環境を丸ごと2系統用意して一気に切り替える手法で、切り替えとロールバックは一瞬ですが、「一部だけに流して様子を見る」段階がありません。カナリアは逆に、検証の丁寧さと引き換えにリリース完了までの時間が延びます。障害時の切り戻し速度を最優先するならブルーグリーン、本番トラフィックでの検証を重視するならカナリア、と目的で使い分けます（両者を組み合わせ、グリーン環境へ段階的に流す折衷もあります）。

フィーチャーフラグは似た効果をアプリケーションのコード内で実現する仕組みで、「デプロイの単位」ではなく「機能の単位」で公開範囲を制御できます。インフラ層のカナリアはバージョン全体の健全性を、フィーチャーフラグは個別機能の是非を検証する、と役割が分かれており、実務では併用されることが多い関係です。