# カナリアデプロイとは？SREのための実践ガイド URL: https://upstreamapi.com/ja/journal/kanaria-deploy-towa Type: blog Locale: ja Published: 2026-10-24 Updated: 2026-10-26 --- > カナリアデプロイは、変更を少量のトラフィックに流し、指標が保たれた場合だけ展開を広げる手法です。手順、ゲート指標、見落としやすい罠を整理します。 カナリアデプロイとは、新しいバージョンを本番トラフィックのごく一部に流し、稼働中のバージョンと比較したうえで、数値が保たれた場合だけ展開範囲を広げるリリース手法です。実務的に言えば、判断ポイントを内蔵したデプロイです。変更はまず1〜5%のユーザーに届き、メトリクスの検査によって続行するか差し戻すかが決まります。 本記事では、その仕組み、失敗しやすい場面、自動化すべき部分を順に解説します。 ## 午前3時のページを、Slackの一通のメッセージに変えるもの 木曜の16時40分にデプロイが出ます。決済サービスのエラー率が0.2%から4%に跳ね上がりますが、2時間後にサポートチケットが届くまで誰も気づきません。その時点で全ユーザーが新ビルドを踏んでいます。マイグレーションが途中まで適用されていたため、ロールバックには25分かかりました。 同じ変更をトラフィックの5%にカナリアとして流していれば、被害は限定されます。約20人に1人のユーザーがバグに当たりますが、数分でコントロール群との比較が失敗し、パイプラインは止まります。ポストモーテムには、見逃した障害ではなく、カナリアが捕まえた障害が書かれるはずです。 ![炭鉱の暗いトンネルで、ランタンのフックに止まる小さな黄色いカナリア](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/ac107f-img1.webp) この名前は炭鉱のカナリアに由来します。空気が致死的になる前に、さえずりをやめた鳥です。小さなコホートも同じ役割を果たします。悪いリリースを防ぐわけではありません。その影響を受ける人の数を抑えるのです。 ## カナリアデプロイが実際に行うこと：ステップごとに [Google SRE Workbook](https://sre.google/workbook/canarying-releases/) は、カナリアを「変更の部分的かつ期間限定のデプロイと、ロールアウトを続けるべきか判断する評価」と定義しています。変更を受けるサブセットがカナリアで、残りのフリートがコントロールです。この枠組みが重要なのは、カナリアを単なる遅いデプロイではなく、自社の信頼性に対する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%しか示しません。メトリクスをカナリアとコントロールに分けて見なければ、シグナルは分母に埋もれて消えてしまいます。 ![高速道路の空撮。片側の車線だけがオレンジ色のコーンで区切られ、他の車線は通常どおり流れている](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f7c98f-img2.webp) ほかにも注意すべき罠が3つあります。 - **導入前後の比較。** カナリア期間を直前の1時間と比べると、変更と時間が混ざります。平日と週末のトラフィックの差だけで、実際の劣化は簡単に埋もれます。代わりに、同時並行のコントロールと比べてください。 - **共有の依存関係。** カナリアとコントロールが同じキャッシュやデータベースを叩いている場合、悪いカナリアが両方を劣化させ、比較では何も見えなくなります。障害ドメインを確認してください。 - **ノイズの多いメトリクス。** CPU使用率はゲートとして不向きです。エラーコードとレイテンシは、ユーザーが実際に感じるものに近い指標です。Workbookは、候補メトリクスをユーザーに見える問題との対応度で順位付けし、上位の数個、多くても十数個に絞るよう勧めています。 ## リリース前にゲート用のメトリクスを決める。障害の最中ではなく 出発点はSLIです。サービスにすでに可用性SLIとレイテンシSLIがあるなら、それが最初の2つのゲートになります。リクエスト駆動型のサービスに対する妥当な出発点は次のセットです。 - 観察期間中の、カナリアとコントロールのエラー率（5xx） - カナリアとコントロールのp99レイテンシ - 変更に起因すると特定できる飽和シグナル（例：Podごとのメモリ増加） - ビジネスに近い指標を1つ（コホートごとに切り分けられるなら、たとえば決済完了率） しきい値で、多くのチームは数週間を失います。厳しすぎると、すべてのカナリアがノイズで中止され、エンジニアはゲートを上書きすることを覚えてしまいます。緩すぎると、悪いビルドが素通りします。定期的に見直してください。半年間一度も中止していないゲートは、完璧か、飾りのどちらかです。どちらなのか確かめるべきです。 また、メトリクスの集計間隔は、カナリア期間より長くしないでください。5分のカナリアに対して10分のロールアップでは、すべてが曖昧になります。 ## 設定で見るカナリア：Argo Rolloutsのステップ Kubernetesでは、[Argo Rolloutsのカナリア仕様](https://argo-rollouts.readthedocs.io/en/stable/features/canary/)が、この流れをステップのリストとして表現します。ドキュメントの形式に沿って簡略化した例を示します。 `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` を実行するまで無期限に待ちます。これは人間によるゲートで、必要かどうかは判断が要ります。 分析ステップが失敗すると、ロールアウトは中止されます。投資すべきなのはこの部分です。 ![制御盤の空撮に近いクローズアップ。ガードの付いた赤い差し戻しスイッチと、緑の表示ランプの列](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/5eb655-img4.webp) ## 安全なカナリアのもう半分はフィーチャーフラグ インフラのカナリアは、インスタンスや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時に失敗していたら、人間が起きていなくても、何かが止めてくれていたでしょうか。 ## FAQ ### カナリアデプロイとは簡単に言うと何ですか？ 新バージョンが少数のユーザーに先に届き、残りは従来のバージョンが処理するリリース方法です。両グループの健全性指標を比べ、新バージョンが問題なければ割合を増やして全体に広げ、問題があれば差し戻します。 ### カナリアデプロイとブルーグリーンデプロイはどう違いますか？ ブルーグリーンは完全な環境を2つ用意して全トラフィックを一度に切り替えるため、ロールバックは即時ですが、切り替えの瞬間に全ユーザーが影響を受けます。カナリアは少数のユーザーに先に流し、実トラフィック上で旧バージョンと比べて判断するため、影響範囲は小さい一方で運用は複雑になります。 ### カナリアには何%のトラフィックを流すべきですか？ 普遍的な数字はありません。Google SRE Workbookは例として30分間の5%を挙げています。割合と期間は、有意なシグナルを得られるだけの量があるかどうかで決まり、トラフィック量とリクエストの均一性に依存します。 ### カナリアデプロイのゲートにはどの指標を使うべきですか？ まずSLIから始めてください。カナリアとコントロールを比べたエラー率とレイテンシです。変更に起因すると特定できる飽和シグナルや、コホートごとに切り分けられるならビジネス指標を加えます。生のCPU使用率のようなノイズの多い指標は避け、リストは短く保ちます。 ### カナリアリリースとカナリアデプロイは違いますか？ チームによっては、機能のユーザー向け公開をカナリアリリース、より広いインフラのロールアウトをカナリアデプロイと呼び分けます。多くは同じ意味で使います。大切なのは、限定されたコホートが最初に変更を受け取り、その後の動きをメトリクスの判定が決めることです。 ### Kubernetesを使わずにカナリアデプロイはできますか？ できます。バージョン別にトラフィックを分けられる仕組みなら何でも機能します。重み付きルーティングのロードバランサー、サービスメッシュ、CDNのルール、ユーザー割合を対象にしたフィーチャーフラグなどです。Argo Rolloutsのような Kubernetes のツールは手順を自動化しますが、この手法がそれに依存するわけではありません。