# カナリアテスト Navigation: [[index]] | [[overview]] ## 定義 カナリアテスト(canarying / canary analysis)とは、ソフトウェアの新バージョンや本番変更(カナリア)を現行バージョン・現行母集団(ベースライン/対照)と並行稼働させ、一部の母集団のみに限定して展開しながら性能・正しさを比較することで、変更をデプロイするリスクを最小化する技術である。有意な劣化が検知されればカナリアは中止され、ロールバック・ロールフォワード・人間へのアラートなどの判定が下される。名称は、有毒ガスを検知するために炭鉱で使われたカナリア鳥に由来する([[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]]、[[@2018__acmqueue__Canary Analysis Service]])。 ## 横断的知見 - **異なる企業・異なる時代の2つの独立したシステムが、統計判定→PASS/FAIL/中間状態という同型のアーキテクチャに収束する**: 2015年の IBM Research [[CanaryAdvisor]]([[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]])は、非パラメトリック統計仮説検定でメトリクスを比較し Inconclusive/Fail/Pass の3状態を返す。2018年の Google CAS([[@2018__acmqueue__Canary Analysis Service]])は、統計検定(check)の集約結果を PASS/FAIL/NONE の3値に還元する。「判定を統計処理の詳細を隠した少数の離散状態に還元する」という設計は、企業・実装が異なっても独立に到達する共通解らしい。ただし両者の状態集合には非対称性があり、CanaryAdvisor の Inconclusive(データ不足で判定不能)は「まだ判定できない」という一時的状態を明示するのに対し、CAS の NONE は「基盤インフラが利用不能で判定不能」という障害状態を指す——前者は正常運用の一部、後者は例外系という位置づけの違いがある。(Source: [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]], [[@2018__acmqueue__Canary Analysis Service]]) - **判定精度の検証課題(CanaryAdvisor)に対し、CAS は near-miss 分析という別解を提示する**: CanaryAdvisor はグラウンドトゥルース欠如下での精度検証を未解決課題として明記する。CAS はこれに直接答えるわけではないが、実運用インパクトの測定という隣接問題に対して「過去の大規模ポストモーテムを遡り、CAS があれば防げたはずの障害を特定する」near-miss 分析という現実的な代替アプローチを提示する。判定の正確性そのものではなく判定システムの価値を測る、という迂回策である点で、CanaryAdvisor が抱えた検証問題の実務的な扱い方の一例になる。(Source: [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]], [[@2018__acmqueue__Canary Analysis Service]]) - **非ランダムノイズ対策として、CAS はオンライン挙動学習による自動しきい値調整を採用する**: CanaryAdvisor は許容誤差係数と信頼区間幅の2パラメータで頑健性とデータ量のトレードオフを制御するが、パラメータ自体は静的である。CAS はデータソース・統計関数・アプリケーションバイナリ・地理的位置・プロセス年齢・観測時刻などの次元で観測を分解し、各統計関数の最小パス比率をオンラインで学習・調整する。CanaryAdvisor が2015年に「非ランダムノイズの識別・除去」を未解決課題としたのに対し、CAS は「同一環境の過去観測から動的にしきい値を学習する」ことで部分的にこの問題に対処する設計に進化しているが、CAS 自身も「同一環境過学習」という副作用(意図的な性能トレードオフを異常と誤検知)を新たな既知の課題として抱えている——ノイズ対策の高度化が別の限界を生む構図。(Source: [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]], [[@2018__acmqueue__Canary Analysis Service]]) - **CanaryAdvisor・CASが暗黙に前提とする「固定-nの統計検定を1回だけ使う」設計を、Netflixの実運用は破っていた**: [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]は、Netflixの自動カナリア分析システム [[Kayenta]](Mann-Whitney U検定などの固定-$n$検定を用いる点でCanaryAdvisor・CASと同じ設計思想)について、開発者がregressionを早期に検知しようとして検定を蓄積データに繰り返し適用する「peeking」が実務で常態化していたと報告する。CanaryAdvisor(2015)・CAS(2018)はいずれも判定を少数の離散状態に還元する設計に到達したが、「その判定を生成する統計検定が何回使われることを想定しているか」という前提はどちらの論文でも明示的に検証されていない。[[逐次検定]]の視点から見ると、CanaryAdvisor・CASの3状態設計がpeekingに対して頑健かどうかは、両ソースの記述からは判断できず未接続の問いとして残る。(Source: [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]], [[@2018__acmqueue__Canary Analysis Service]], [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]) - **regression の定義を「平均値の差」から「確率的順序(分布全体の比較)」へ広げる設計軸は、CanaryAdvisor・CASの「離散状態への還元」とは独立した進化である**: CanaryAdvisor・CASは判定結果の表現(何を返すか)を洗練させたのに対し、[[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]は判定対象の統計的性質(何を検定するか)を洗練させた。平均は変わらないが裾が悪化するケース(PlayDelayの例)は、CanaryAdvisor・CASの記述からは検知できるかどうか判断できない——両者とも「メトリクスの分布比較」を行うと述べるのみで、平均以外の分布特性を明示的に扱うとは記述していない。(Source: [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]) - **Gandalf は「カナリア/対照母集団のメトリクス統計比較」ではなく「同時進行する複数ロールアウトの中からのイベント相関による犯人特定」という、CanaryAdvisor・CAS とは異なる問題設定に立つ**: [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]] の [[Gandalf]] は、Microsoft Azure で 1 日数百件が同時進行するロールアウトを前提に、障害シグナルをどのロールアウトに帰責すべきかを空間相関(SS = N_f/N_df)・時間相関・vote-veto 機構で判定する。CanaryAdvisor・CAS は「1つのカナリアと1つの対照母集団のペア比較」を単位とするのに対し、Gandalf は「同時に何十ものコンポーネントがデプロイされている状況で、単一の障害シグナルをどのコンポーネントに帰責するか」という n 対 1 の識別問題を解く。Azure の safe deployment policy 自体が stage → canary → pilot → region という段階を経るため、Gandalf はカナリア段階を含む複数段階を横断して機能する点でも、CanaryAdvisor・CAS が想定する単一カナリア判定ステップとは設計思想が異なる。(Source: [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) - **「カナリアテスト」と「ブルー・グリーンデプロイメント(Netflix呼称: red-black deployment)」は、教科書的な導入部でも明確に区別される隣接技法である**: Gregg(2023、ch.1 §1.3)は、カナリアテストを「本番ワークロードの一部を1台の新サーバーインスタンスで処理させて新ソフトウェアをテストするテクニック」と定義し、これとは別に、もとのプールをオンラインで残しながらトラフィックを段階的に新プールへ移すブルー・グリーンデプロイメントを紹介する。同書はNetflixがこれを「red-black deployment」と呼んでいると脚注で注記しており、この用語は[[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]が報告するNetflixの自動カナリア分析システム[[Kayenta]]と同じ企業文脈で使われている。「カナリアテスト」を扱う文献群(CanaryAdvisor・CAS・Kayenta)はいずれも段階的な母集団曝露と統計判定を前提とするのに対し、blue-green/red-blackはロールバックの容易性(バックアップとして旧プールを残す)を主眼とする別技法であり、教科書的な入門記述の段階からこの境界線が明示されている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]], [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]) - **集約メトリクスが実害を隠す「70%到達で初めて破綻する」事例は、CanaryAdvisor・CASが課題とした「非ランダムノイズ」とは異なる種類の見逃しである**: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] は、ある企業が1%のカナリアをダッシュボード上で正常と判断して全展開したところ、70%まで到達した時点で全リクエストが同一のデータベース行ロックを奪い合い始めた実例を報告する。これは「ノイズによる誤判定」ではなく、「閾値効果(threshold effect)によりカナリア母集団の規模では顕在化しない障害」であり、CanaryAdvisor・CASが扱う統計的ノイズ除去の枠組みでは捉えられない失敗モードを追加する。同章はこれに対する解決策として、集約統計ではなく高カーディナリティなコホート比較(新ビルド対旧ビルドを任意の属性で絞り込み比較する)を提示しており、CanaryAdvisor・CASの「統計検定によるPASS/FAIL判定」とは異なるアプローチ(オブザーバビリティ主導の探索的比較)を提案している。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]], [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]], [[@2018__acmqueue__Canary Analysis Service]]) - **Gregg(2023)の「カナリアテスト対ブルー・グリーンデプロイメント」という二項対比に、Observability Engineering 2E ch.2はローリングデプロイを加えた三分類(ブルーグリーン・カナリア・ローリング)で応答する**: 両ソースとも各技法を独立した手法として並べる点は共通するが、Gregg(ch.1 §1.3)はロールバックの容易性という観点でブルー・グリーンを特徴づけるのに対し、[[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] は速度・コスト・複雑さ・ロールバック容易性という4軸のトレードオフとして3技法を統一的に位置づけ、さらに [[フィーチャーフラグ]] によるデプロイ/リリース分離と組み合わせた「フライホイール」の一部としてカナリア・ブルーグリーンを再定義する。教科書的な技法カタログ(Gregg)と、運用実践の統合フレームワーク(Observability Engineering 2E)という記述レベルの違いが見える。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]], [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) ## 未解決の問い - カナリアテストの判定における非ランダムノイズ(異なるハードウェアへのデプロイ、共存タスクによる測定バイアス)を、ランダムノイズと区別して除去する統計的手法は何か([[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]]が2015年時点で未解決と明言)。CAS のオンライン挙動学習はこの問題を部分的に緩和するが、同一環境過学習という副作用を伴う([[@2018__acmqueue__Canary Analysis Service]])。 - 本番環境でのカナリアテストの判定精度(正確性)を、グラウンドトゥルースが得られにくい状況でどう体系的に検証できるか。CAS の near-miss 分析(ポストモーテム遡及)は判定システムの価値を測る迂回策だが、判定そのものの精度検証には答えていない。 - カナリアテストの失敗判定の閾値(何を「悪化」とみなすか)を、アプリケーションやリリースごとに動的に調整する仕組みはどう設計すべきか。 - 2015年のCanaryAdvisorの統計仮説検定ベースのアプローチと、その後(2020年代)の機械学習・LLMベースの異常検知・根本原因分析手法群([[異常検知]]・[[Fault Localization]]等の他concept参照)との間で、カナリア判定の設計思想はどう変化したか。 - CanaryAdvisor(2015)と CAS(2018)はいずれも「確信度・p値を最終判定から隠す」設計を共有するが、いずれの論文も「なぜユーザーに確信度を見せないほうが良いのか」を実証的に検証していない(CAS は設計思想として述べるのみ)。確信度の非公開が実際にユーザーの誤った意思決定を減らすかは、行動実験的に検証可能な問いとして残る。 - CanaryAdvisor・CASの3状態判定システムは、開発者による検定の反復適用(peeking)に対してどの程度頑健か。[[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]はNetflixの[[Kayenta]]でpeekingが常態化していたと報告するが、CanaryAdvisor・CASそれぞれの運用でも同様の問題が生じていたかはソースの記述からは判断できない。 - Gandalf のイベント相関ベースの犯人特定と、CanaryAdvisor・CAS のメトリクス統計比較は、同じ「安全なデプロイ」という目的に対する異なる技術的アプローチだが、両者を組み合わせた設計(カナリア段階ではメトリクス比較、複数コンポーネント同時展開時は相関分析)は既存ソースのいずれにも記述がなく、実際に併用されている事例があるかは未確認。([[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) - ローリングデプロイ(インスタンスを1つずつ、または小バッチで置き換える方式)を含めた3変種(ブルーグリーン・カナリア・ローリング)を統一的な「プログレッシブデリバリー」の枠組みで扱う場合、各変種に最適な自動ロールバック判定ロジック(CanaryAdvisor/CAS型の統計判定、Gandalf型のイベント相関判定)はそれぞれ異なるのか、共通化できるのか。([[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) ## 関連 - ソース: [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]] / [[@2018__acmqueue__Canary Analysis Service]] / [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]] / [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] - 関連プロダクト・組織: [[CanaryAdvisor]] / [[IBM Research]] / [[Google]] / [[Štěpán Davidovič]] / [[Netflix]] / [[Kayenta]] / [[Gandalf]] / [[Microsoft Azure]] / [[Brendan Gregg]] - 関連概念: [[異常検知]]・[[Fault Localization]](統計的/機械学習的な劣化検知という観点で関連するが、横断的知見はまだ未接続) / [[逐次検定]](固定-$n$検定 vs 逐次検定という判定メカニズムの設計軸を追加する) / [[SRE]] / [[変更起因インシデント]] / [[障害緩和]] / [[制御ロールアウト]](デプロイリスクを段階的曝露と統計判定で低減するという上位の狙いは共通するが、判定メカニズムが異なる。横断的知見はまだ未接続) / [[フィーチャーフラグ]](デプロイ/リリース分離という上位のフライホイールでカナリア・ブルーグリーンと組み合わされる) - 関連 MOC: [[SRE - MOC]](発見性のための一方向参照) ## 出典 - [[@2015__ISSTA__CanaryAdvisor - A Statistical-Based Tool for Canary Testing]] - [[@2018__acmqueue__Canary Analysis Service]] - [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]] - [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]](§1 導入・4層安全機構、§4 相関アルゴリズム設計) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]](§1.3、カナリアテスト・ブルー・グリーンデプロイメントの教科書的定義) - [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]](Practice 5、プログレッシブデリバリーの3変種と70%到達時のデータベース行ロック事例)