> [!abstract] 概要(acmqueue abstract の日本語訳) > 1913 年、スコットランドの生理学者 John Scott Haldane は、危険なガスを検知するためにカナリアを炭鉱に持ち込むというアイデアを提案した。100 年以上後、Haldane の「炭鉱のカナリア」的発想はソフトウェアテストにも応用されている。本稿では、canarying(カナリアリリース)という語を、サービスの変更を部分的かつ時間を区切って展開し、その変更が安全かどうかを評価する手法として用いる。本番変更のプロセスはその後、ロールフォワード・ロールバック・人間へのアラート、あるいは他の対応を取りうる。効果的なカナリアリリースには、部分的なサービス変更をどう展開するか、意味のあるメトリクスをどう選ぶかなど多くの意思決定が伴い、それ自体が別途議論に値する。Google は CAS(Canary Analysis Service)と呼ばれる共有の中央集権型サービスを展開しており、本番変更時の主要メトリクスを自動的(かつしばしば自動設定済み)に分析する。CAS は新しいバイナリバージョン・構成変更・データセット変更・その他の本番変更を分析するために使われ、Google では1日あたり数十万件の本番変更を評価している。 ## 論文情報 - タイトル: Canary Analysis Service - 著者: Štěpán Davidovič(執筆)、Betsy Beyer(共著者としてクレジット)。ともに Google 所属。 - 媒体: ACM Queue(*acmqueue*)、2018年1・2月号 - URL: https://queue.acm.org/detail.cfm?id=3213188 - PDF 原本: https://storage.googleapis.com/gweb-research2023-media/pubtools/4394.pdf(Google Research pubs 経由) - 著者略歴(本文末尾より): Štěpán Davidovič は Google のサイト信頼性エンジニアで、執筆当時は内部インフラの自動モニタリングを担当。過去の SRE ロールで Canary Analysis Service を開発し、共有インフラプロジェクトおよび AdSense の信頼性業務にも従事した。チェコ工科大学(プラハ)で2010年に学士号を取得。Betsy Beyer は Google Site Reliability Engineering のテクニカルライター(NYC)で、*Site Reliability Engineering: How Google Runs Production Systems* の編者。 ## 概要 本稿は、Google が全社的に展開する集中共有型のカナリア分析サービス CAS(Canary Analysis Service)の設計と運用知見を報告する実践論文である。CAS はバイナリ更新・構成変更・データセット変更などあらゆる種類の本番変更に対して、カナリア集団と対照集団のA/Bテストを自動実行し、PASS/FAIL/NONE の明確な判定のみをロールアウトツールに返す。オートコンフィグレーション機構により統計知識のないエンジニアでも利用できる点が全社的な採用を後押しした一方、既知の限界(環境過学習・ユーザー不信・相対比較のみ・入力スケール限界)についても率直に論じている。 ## 問題設定 - **入力**: カナリア集団(変更が適用された本番の一部)と対照集団(変更が適用されていない残りの一部)の識別子(BNS パス、マシンホスト名など)、比較する時間範囲、任意でユーザー定義の設定(チェックの定義)。 - **出力**: PASS(問題なし)、FAIL(危険な異常挙動)、NONE(基盤インフラが利用不能で判定不能)のいずれか一つの明確な verdict。 - **前提**: CAS は本番を変更しない純粋な観測者であり、カナリアの実際のセットアップ(トラフィックの一部振り分けなど)はロールアウトツール側の責務として CAS の外部で行われる。粒度は呼び出し側が実行時に自由に定義でき(例: プロセス単位の BNS パス、マシン単位のホスト名)、静的な事前カナリアセットアップを不要にする。 ## 提案手法 - **アーキテクチャ**: rollout tool → CAS という単純な外部インタラクションの内側に、Spanner データベース(進捗と最終ステータスの正規ストレージ)・RPC front end(Evaluate()/GetResult() の受付)・Coordinator(評価のオーケストレーションと状態管理)・Configuration server(設定の解決・展開)・Evaluator(実際の時系列取得と統計検定の実行)・Model server(自動分析の予測)の各コンポーネントが連携する(Figure 2)。 **Figure 2: CASの主要コンポーネント構成図** ![[_attachments/acmqueue-2018-canary-analysis-service/fig02-cas-components.png]] (Figure 2. Diagram of main components of CAS。rollout tool → RPC front end → spanner という基本経路に加え、coordinator が web front end・evaluator・config server・model server と連携し、evaluator が Monarch から時系列を取得する構成。Source: 本論文 Figure 2。) - **API**: 公開 API は `Evaluate()` と `GetResult()` の2つの RPC のみ。`Evaluate()` は1つ以上の trial(カナリア集団・対照集団・比較時間範囲のペア)を受け取り、CAS UI への完全修飾 URL となる一意な Evaluation ID を返す。`GetResult()` は Evaluation ID を受け取り、分析完了までブロックする冪等な呼び出し。実際の分析処理は `Evaluate()` 時点で最適化として開始されるが、API 仕様上は誰かが結果に関心を持ったことを示す `GetResult()` 呼び出し時に開始されると定義される。この2 RPC分離設計により、あるバグで CAS プロセスが5〜10分ごとにクラッシュした際も、複雑なクライアント協調なしに処理を再開でき、全ユーザーリクエストへのサービス提供を継続できた。 - **ワークフロー**(Figure 1): ①ロールアウトツールがカナリアをセットアップ、②CAS に判定を依頼、③CAS が判定(verdict)を返却、④ロールアウトツールがロールフォワード/ロールバックを実行、という4ステップで構成される。CAS はこの間、母集団記述子(population descriptors)のみを受け取るパッシブな存在であり続ける。 **Figure 1: CASの典型的なワークフロー** ![[_attachments/acmqueue-2018-canary-analysis-service/fig01-cas-workflow.png]] (Figure 1. Diagram of typical CAS workflow。rollout tool が①カナリアをセットアップし、②CAS に判定を依頼、③受け取った判定に基づき④ロールフォワード/ロールバックする。CAS は母集団記述子(population descriptors)だけを受け取るパッシブな観測者として描かれる。Source: 本論文 Figure 1。) - **評価構造**: 最小単位は check(カナリア/対照双方の時系列と、それらを PASS/FAIL に変換する統計関数の組)。1回の評価リクエストは複数の trial(カナリア/対照母集団のペア)を持ちうる。いずれかの trial のいずれかの check が FAIL すれば、評価全体が FAIL となる。フロントエンドとバックエンドのように異なるが関連するコンポーネントを同時に評価する場合など、複数 trial を1リクエストにまとめられる。 - **設定構造**: ユーザーはチェックごとに「名前」「時系列の取得方法(通常は Monarch へのクエリ)」「時系列から verdict への変換方法(統計テスト)」を指定する。CAS は抽象クエリをランタイムに実カナリア/対照母集団向けへ自動書き換えする機構を持つ(例: 「CPU使用率を取得」→「job foo-server の replica 0, 1, 2 の CPU使用率を取得」)。CAS チームがキュレートする定型クエリ(crash rate、RPC server error ratio、CPU utilization等)も用意されている。 - **実装上の工夫(オートコンフィグレーション)**: ユーザーが統計テストを未指定の場合、CAS は「オンライン挙動学習」で典型的な挙動を推定する。観測はデータソース・統計関数とパラメータ・アプリケーションバイナリ・地理的位置・プロセス年齢(再起動有無)・日次粒度の観測時刻など複数の次元で分解して蓄積され、各統計関数ごとの最小パス比率(`sum[PASS] / (sum[PASS]+sum[FAIL]+sum[NONE])`)を閾値として PASS/FAIL を予測する。ブートストラップ(過去の該当評価を遡って実行し初期データを作る仕組み)により、初回利用時から一定の精度を確保する。 ## 新規性 先行研究(参考文献に挙がる Fail at Scale、SRE Book 等)がカナリアリリースという実践自体の価値を論じるのに対し、本論文は「統計知識を要求しない、全社横断の集中型カナリア分析サービス」という具体的システム設計を報告する点が新しい。特に、(1) 判定を PASS/FAIL/NONE のみに限定し確信度スコアやp値を意図的に返さないことで、ロールアウトツール側に誤った意思決定ロジックを実装させない設計思想、(2) ゼロコンフィグレーション(設定なしでも自動特徴検出により妥当な既定分析を行う)によって導入障壁を下げた戦略、(3) オンライン挙動学習による自動しきい値調整、の3点が、他の一般的なA/Bテスト基盤やモニタリング異常検知とは異なる CAS 固有の設計選択として強調されている。 ## 実験設定 本論文は実験論文ではなく、システムの設計・運用に関する実践報告(experience report)であるため、独立した実験セクションは存在しない。裏付けとして用いられるのは Google 内部の本番運用実績(1日あたり数十万件の本番変更評価)とポストモーテム分析である。 ## 実験結果 - **規模**: CAS は Google で1日あたり数十万件(hundreds of thousands)の本番変更を評価している。 - **信頼性の実証**: あるバグで CAS プロセス群が5〜10分おきにクラッシュした際も、2 RPC 分離設計のおかげで全ユーザーリクエストへのサービス提供を継続できた(具体的な障害復旧の実例)。 - **インパクト分析(near-miss 分析)**: CAS チームは A/B 的な直接効果測定(一部評価の失敗を無視してパスさせ影響を測る)を、外乱要因が多すぎて明確なシグナルを得られないと判断して断念し、代わりに大規模ポストモーテムを遡って「CAS が防げたはずだが防げなかった」障害を特定する near-miss 分析を採用した。ある機能があれば1000万ドル(10M)規模のポストモーテムを防げたと分かれば、その機能実装が1000万ドル分の CAS の価値を証明する、という定性的な例が示される。この分析により、CAS は数百件規模のポストモーテム相当の障害を防いだと推定され、CAS を使わないグループのポストモーテム発生率はより高いと報告されている(具体的な件数・比率の数値は本文中に明記されない)。 ## 考察 - CAS の設計哲学は「統計的に完璧であることより、エンジニアが使いやすく広く採用されること」を一貫して優先する。確信度スコアを返さない・オートコンフィグレーションを提供する・ゼロコンフィグレーションを許容するといった各設計判断は、いずれも「統計知識を前提にしない」という一点に収束している。 - 著者らは、CAS のデータ再利用(例: 最適な地理的位置を推薦する)が一見魅力的でも危険だと指摘する。推薦に従ってユーザーが特定地域だけでカナリアを行うようになると、CAS がその他の地域について学習する機会が失われ、局所最適が大域最適から乖離するリスクがあるためである。これはレコメンドシステム一般に見られるフィードバックループ問題の一種と言える。 - 「Perfect is the enemy of good」という教訓は、カナリアリリースがユニットテスト・統合テスト・モニタリングを置き換えるものではなく、それらを補完する一手段に過ぎないという位置づけを明確にする。過度に厳密なカナリア設定を追求すると、かえってリリースの妨げになるトイル(運用上の負荷)を生む。 ## 強み / 弱点・課題 **強み** - 統計知識を前提としない設計により、Google 全社の主要な本番変更ツールへの統合を達成し、実運用で1日数十万件という規模で稼働している。 - 2 RPC(Evaluate/GetResult)というシンプルな API 設計が、クライアント側の複雑な状態管理を不要にし、サービス側の障害からの回復力を高めている。 - near-miss 分析という、直接的なA/B測定が困難な状況における現実的なインパクト評価手法を提示している。 **弱点・課題**(著者ら自身が Known Issues として明記) - **同一環境過学習**: 全く同じ環境での豊富な過去観測がある場合、その環境のデータのみが使われるため、意図的な性能トレードオフ(例: レイテンシは倍だが品質が大幅向上)を異常として誤検知しうる。 - **ユーザーの不信**: 複雑な自動化への不信から、ユーザーがカナリア失敗を無視して壊れたリリースをプッシュした事例がある。 - **相対比較のみ**: モデルサーバーは統計関数の結果(outcome)のみを保存し入力値そのものを知らないため、時系列の典型値が分からない。値が通常ゼロに近い、または絶対値としては軽微でも相対変化が大きいケースで誤検知しやすい。 - **入力値のスケール限界**: ハードコードされた統計関数とパラメータのセットを使うため、想定スケール外の入力(例: 通常200%の変動が正常な系、逆に1%の差も許容できない系)への対応が硬直的。著者らはこれが実運用上大きな問題にならなかったと述べるが、根本的な設計制約として残る。