カナリアデプロイとは？SREのための実践ガイド
要約
カナリアデプロイとは、新バージョンを本番トラフィックの小さな割合（多くは5%）に流し、一定期間、安定版と比較して段階的に展開を広げるリリース手法です。エラー率とレイテンシがコントロールと同等に保たれれば展開を広げ、崩れれば中止して差し戻します。影響範囲を抑えられますが、バージョン別のメトリクスと、シグナルを生むのに十分なトラフィックが前提になります。
カナリアデプロイとは、新しいバージョンを本番トラフィックのごく一部に流し、稼働中のバージョンと比較したうえで、数値が保たれた場合だけ展開範囲を広げるリリース手法です。実務的に言えば、判断ポイントを内蔵したデプロイです。変更はまず1〜5%のユーザーに届き、メトリクスの検査によって続行するか差し戻すかが決まります。
本記事では、その仕組み、失敗しやすい場面、自動化すべき部分を順に解説します。
午前3時のページを、Slackの一通のメッセージに変えるもの
木曜の16時40分にデプロイが出ます。決済サービスのエラー率が0.2%から4%に跳ね上がりますが、2時間後にサポートチケットが届くまで誰も気づきません。その時点で全ユーザーが新ビルドを踏んでいます。マイグレーションが途中まで適用されていたため、ロールバックには25分かかりました。
同じ変更をトラフィックの5%にカナリアとして流していれば、被害は限定されます。約20人に1人のユーザーがバグに当たりますが、数分でコントロール群との比較が失敗し、パイプラインは止まります。ポストモーテムには、見逃した障害ではなく、カナリアが捕まえた障害が書かれるはずです。
この名前は炭鉱のカナリアに由来します。空気が致死的になる前に、さえずりをやめた鳥です。小さなコホートも同じ役割を果たします。悪いリリースを防ぐわけではありません。その影響を受ける人の数を抑えるのです。
カナリアデプロイが実際に行うこと：ステップごとに
Google SRE Workbook は、カナリアを「変更の部分的かつ期間限定のデプロイと、ロールアウトを続けるべきか判断する評価」と定義しています。変更を受けるサブセットがカナリアで、残りのフリートがコントロールです。この枠組みが重要なのは、カナリアを単なる遅いデプロイではなく、自社の信頼性に対するA/Bテストにしてくれるからです。
典型的な流れは次のとおりです。
安定版の横に新バージョンをデプロイし、まだトラフィックは流さない。
少しの割合のトラフィックを振り分ける（Workbookの例では5%）。
一定の観察時間（同じ例では30分）を取り、カナリアとコントロールを比較する。
次の段階へ進む（25%、50%、100%の順）か、中止してトラフィックを戻す。
流れ自体は単純です。難しいのは比較の段階で、多くのチームはこれを「誰かがダッシュボードを眺める」という形で実装しています。
カナリア、ブルーグリーン、ローリング：障害のモードに合うのはどれか
この3つはよく混同されるので、選ぶときに重要な違いを整理します。
ローリングアップデート： インスタンスを少しずつ置き換えます。安価で、どのオーケストレーターにも組み込まれていますが、コントロールとの比較も、きれいなトラフィック分割もありません。新旧バージョンが最後まで負荷を分け合います。
ブルーグリーン： 完全な環境を2つ用意し、全トラフィックを一度に切り替えます。ロールバックは即時ですが、切り替えの瞬間の影響範囲は全ユーザーの100%です。容量も2倍必要です。
カナリア： 新バージョンに制御された割合の実トラフィックを流し、旧バージョンと比べて判断します。影響範囲は最小ですが、運用の複雑さは最大です。
ブルーグリーンが向くのは、スモークテストで検出でき、数秒で戻せる壊れたデプロイのリスクです。カナリアが向くのは、実トラフィックでしか表に出ない微妙な劣化です。たとえば、p99レイテンシの緩やかな悪化、ゆっくり進むメモリリーク、本番データの形で崩れるクエリプランなどです。
トラフィックが非常に少ないサービスでは、カナリアは避けてください。1時間に数百リクエストしかなければ、5%のスライスではサンプルが数件しか得られず、シグナルになりません。Workbookも、クエリ数が少なすぎると多様なワークロードに有用なシグナルは得られないと明言しています。
1%のカナリアは、あなたに嘘をついているかもしれない
導入から3か月以内にチームがよく直面する失敗があります。カナリアがトラフィックの5%を受け持ち、そのリクエストの20%で失敗するとします。サービス全体のエラー率は0.2%からおよそ1.2%に動きます。アラートのしきい値が2%なら、何も発火しません。
集約された監視は、カナリアの失敗を隠します。SRE Workbookにも同じ計算が載っています。トラフィックの5%で、リクエストの20%が失敗するカナリアは、全体のエラー率としては1%しか示しません。メトリクスをカナリアとコントロールに分けて見なければ、シグナルは分母に埋もれて消えてしまいます。
ほかにも注意すべき罠が3つあります。
導入前後の比較。 カナリア期間を直前の1時間と比べると、変更と時間が混ざります。平日と週末のトラフィックの差だけで、実際の劣化は簡単に埋もれます。代わりに、同時並行のコントロールと比べてください。
共有の依存関係。 カナリアとコントロールが同じキャッシュやデータベースを叩いている場合、悪いカナリアが両方を劣化させ、比較では何も見えなくなります。障害ドメインを確認してください。
ノイズの多いメトリクス。 CPU使用率はゲートとして不向きです。エラーコードとレイテンシは、ユーザーが実際に感じるものに近い指標です。Workbookは、候補メトリクスをユーザーに見える問題との対応度で順位付けし、上位の数個、多くても十数個に絞るよう勧めています。
リリース前にゲート用のメトリクスを決める。障害の最中ではなく
出発点はSLIです。サービスにすでに可用性SLIとレイテンシSLIがあるなら、それが最初の2つのゲートになります。リクエスト駆動型のサービスに対する妥当な出発点は次のセットです。
観察期間中の、カナリアとコントロールのエラー率（5xx）
カナリアとコントロールのp99レイテンシ
変更に起因すると特定できる飽和シグナル（例：Podごとのメモリ増加）
ビジネスに近い指標を1つ（コホートごとに切り分けられるなら、たとえば決済完了率）
しきい値で、多くのチームは数週間を失います。厳しすぎると、すべてのカナリアがノイズで中止され、エンジニアはゲートを上書きすることを覚えてしまいます。緩すぎると、悪いビルドが素通りします。定期的に見直してください。半年間一度も中止していないゲートは、完璧か、飾りのどちらかです。どちらなのか確かめるべきです。
また、メトリクスの集計間隔は、カナリア期間より長くしないでください。5分のカナリアに対して10分のロールアップでは、すべてが曖昧になります。
設定で見るカナリア：Argo Rolloutsのステップ
Kubernetesでは、Argo Rolloutsのカナリア仕様が、この流れをステップのリストとして表現します。ドキュメントの形式に沿って簡略化した例を示します。
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 30m }
- analysis:
templates:
- templateName: error-rate-vs-baseline
- setWeight: 25
- pause: { duration: 30m }
- setWeight: 50
- pause: {}ドキュメントから注目したい点が2つあります。トラフィックルーターがない場合、重みはベストエフォートでPod数により近似されます。レプリカ10個で10%なら、カナリアのPodは1つ、安定版は9つです。これはリクエストの計算ではなく、レプリカの計算です。また、pause: {} は期間を指定しないため、誰かが kubectl argo rollouts promote を実行するまで無期限に待ちます。これは人間によるゲートで、必要かどうかは判断が要ります。
分析ステップが失敗すると、ロールアウトは中止されます。投資すべきなのはこの部分です。
安全なカナリアのもう半分はフィーチャーフラグ
インフラのカナリアは、インスタンスやPod単位でトラフィックを分けます。フラグベースのカナリアは、ユーザー、アカウント、その他ターゲットにできる任意の属性で分けます。両者は異なる問いに答えます。前者は新しいビルドが健全かを問い、後者は新しい振る舞いが許容できるかを問います。後者なら、再デプロイなしでオフに戻せます。
フラグ駆動のロールアウトでは、ツールの選び方が重要です。LaunchDarklyは、ターゲティングルールと監査証跡が最も成熟しており、エコシステムの広さでも優れています。ただし、エンタープライズ規模での価格は、プラットフォームリードがよく挙げる不満点です。
Statsigは実験機能をフラグと一体で提供するため、同じプラットフォーム上でメトリクスに基づく判断をしたいチームに向いています。キルスイッチだけが必要なら、適合度は下がります。
率直なトレードオフがあります。フラグプラットフォームは割合ベースのロールアウトを提供しますが、多くは単独ではSLOを読みません。メトリクスを判断に結びつける作業は、依然として誰かが行う必要があります。
バージョン別に分割できる比較元が必要
ロールアウトをどう動かすにせよ、判定はテレメトリから来ます。つまり、すべてのメトリクスにバージョンまたはコホートのラベルが必要で、バックエンドは10分の遅延なしにそのラベルで照会できなければなりません。
Datadogは、タグベースの分解がうまく、デプロイ追跡によってリリースとエラー急増を相関させられます。すべてにタグを付ける前に、高カーディナリティ時のコストを見積もっておくべきです。
すでにGrafanaとPrometheusを運用していて、ロールアウトのリビジョンでメトリクスにラベルを付けるなら、Grafanaも十分に機能します。完全な制御が得られますが、保守も自分で持つことになります。
中止の自動化：AIパイロットという発想の出どころ
手動のカナリア分析はスケールしません。1日10回デプロイするなら、毎回30分ダッシュボードを見つめる人はいません。すると、ゲートは静かに「見た感じ問題なし」に変わります。持続するパターンは、自動化された判定者です。SLOを定義し、比較の方法を定義し、カナリアが安定版より速く誤差予算を消費したら、コントローラーが中止と差し戻しを行います。
upstreamapiのAI Pilotが狙うのが、まさにこの問題です。ロールアウト中にSLOのシグナルを読み、設定したしきい値をエラー率が超えると、自動ロールバックを発動します。測るのは、安定版コホートに対するエラー率とレイテンシであり、それ以上でも以下でもありません。すでに良いPrometheusクエリを使ったArgo Rolloutsの分析テンプレートを運用しているなら、同じ機能の大部分はすでに手元にあります。魔法のように語る人には、そう指摘してかまいません。ホスト型のパイロットが価値を発揮するのは、各チームが独自の分析テンプレートを保守することになる、多様なスタックをまたぐ場面です。
よくある失敗パターンがあります。チームは昇格ステップを自動化しても、中止は自動化しません。前にしか進めないパイプラインは、ベルトコンベアにすぎません。
カナリアの仕組みがうまく回っているかを測る指標
カナリアのプログラムには、独自の指標があります。四半期ごとに次を追ってください。
カナリア中止率： ゲートによって止められたカナリアの割合。ゼロなら、ゲートは何も見えていません。20〜30%を超えるなら、しきい値の不安定さか、マージ前テストの不足が疑われます。
カナリアでの検知時間： 最初の不良リクエストから中止までの分数。これがリリースにおける実質的なMTTDです。
すり抜けた回帰： カナリアを通過したリリースに起因するインシデント。1件ごとに、ゲートを見直す理由になるべきです。
平均差し戻し時間： 中止の判断から、全トラフィックが安定版に戻るまでの時間。
Workbookが強く勧めるとおり、サービスごとに同時に走らせるカナリアは1つだけにしてください。理由は実務的です。2つの変更が重なると原因の特定ができず、どちらが被害を出したのか分からなくなります。
今週どこから始めるか
十分なトラフィックがあり、15分でシグナルが出るステートレスなサービスを1つ選んでください。そのエラーとレイテンシのメトリクスにバージョンラベルを追加します。カナリアとコントロールを比較する単一のクエリを書きます。手動昇格付きで5%のカナリアを流し、直近3件のインシデントで何を検知できていたかを記録してください。
そのうえで、耳の痛い問いを投げかけてください。もしカナリアが午前2時に失敗していたら、人間が起きていなくても、何かが止めてくれていたでしょうか。