プログレッシブデリバリと自動ロールバック

プログレッシブデリバリとは何か

プログレッシブデリバリは、デプロイ戦略のカナリアに 自動解析（automated canary analysis, ACA） を組み込んだものです。新版をごく一部のトラフィックに流し、SLI（サービスレベル指標）を新旧で機械的に比較し、合格なら次の重みへ昇格、不合格なら昇格を止めて自動で巻き戻します。人間の「なんとなく大丈夫そう」を、再現可能な判定ロジックに置き換えるのが本質です。

重要なのは、これが単なる「少しずつ出す」ではない点です。割合を上げるたびに 判定（gate） が入り、判定に必要な指標と基準が事前に定義されていなければなりません。判定材料がなければ、ただ遅いブルーグリーンにすぎません。

カナリア解析：何と何を比べるか

素朴な実装は「新版のエラー率が閾値（例：1%）を超えたら止める」です。しかしこれは ベースラインのドリフト に弱い。時間帯やトラフィック構成で旧版のエラー率自体が動くため、絶対閾値は誤検知（昼に厳しく夜に甘い）を生みます。

実務で堅いのは 相対比較、しかも ベースライン版とカナリア版を同時に立てて比べる 方式です。

• 本番旧版 … 既存の全トラフィックを受ける現行
• ベースライン版 … 旧版と同一コードを少量トラフィックで新たに起動
• カナリア版 … 新版を同量トラフィックで起動

カナリアを「本番旧版」ではなく「今まさに同条件で動くベースライン版」と比べることで、JITウォームアップ差・キャッシュ充填状態・新規プロセスゆえの初期挙動といったバージョン差以外のノイズを相殺します。比べるのはエラー率、p99レイテンシ、飽和（CPU・メモリ）など、SLOに直結するSLIです。

判定窓と統計的有意性

ここが上級者が外しやすい核心です。判定窓（解析対象の時間幅）が短いとサンプル数が足りず、偶然のばらつきと真の劣化が区別できません。

たとえばベースラインのエラー率が真に1%だとして、100リクエストの窓で観測すると、エラー2件（2%）が出ることは珍しくありません。これを「悪化」と判定すれば偽陽性（健全な版を不当に巻き戻す）です。逆に窓を広げすぎると判定が遅れ、被害が広がります。

頻度論的アプローチでは、新旧の差が偶然で説明できるかを 仮説検定 で判断します。「両者に差はない」を帰無仮説とし、観測差が偶然ではあり得ないほど大きい（p値が有意水準を下回る）ときだけ「悪化」とします。指標分布は正規でないことが多いため、レイテンシ分布の比較には マン・ホイットニーのU検定 のようなノンパラメトリック手法が向きます。

合否を一発の閾値ではなくスコア化するのも定石です。各指標の劣化度合いを重み付き合算し、総合スコアがしきい値（例：75点）を割ったら不合格とします。致命指標（エラー率）には大きな重み、参考指標には小さな重みを与え、{critical, high, low} のように分類して扱います。

ベイズ的判断：意思決定の枠組み

頻度論の検定は「差があるか/ないか」を答えますが、運用が本当に知りたいのは「この新版を全展開して許容範囲を超える確率はどれくらいか」という意思決定です。これにはベイズ的な見方が噛み合います。

ベイズ統計では、観測データから劣化幅の 事後分布 を求め、「劣化が許容値（実質的同等性の範囲、ROPE）を超える確率」を直接見積もります。たとえば「カナリアの方がレイテンシ悪化している確率が95%」「ただし悪化幅が許容内に収まる確率も95%」を別々に評価でき、統計的に有意でも実害として小さい変化を昇格させる、といった判断ができます。p値だけでは表現しにくい「effect size（効果量）」を中心に据えられるのが利点です。

実務上の含意は明快です。サンプルが少ない初段では事後分布が広く確信が持てない（区間が広い）ので、自信を持って合格にも不合格にもできない。判定窓を延ばすか、重みを上げてサンプルを稼ぐまで保留する、という挙動が統計的に正当化されます。

自動ロールバックの安全性

判定が「不合格」を出したとき、自動で巻き戻せること自体が前提条件です。ロールバックが安全であるには、次が成立していなければなりません。

• トラフィックの巻き戻しが冪等：重みをカナリアから0%に戻す操作は、冪等で、何度実行しても同じ状態（旧版100%）に収束する必要があります。途中失敗で中途半端な重みに固まらないこと。
• DBスキーマの後方互換：新版が当てたマイグレーションは旧版でも動く形（expand and contract）でなければ、アプリだけ戻してもデータが戻せません。「アプリは戻せたがDBが戻せない」は自動ロールバック最大の落とし穴です。
• 状態の非依存：カナリアが書いた壊れたキャッシュやキューのメッセージが旧版に毒を回さないこと。

ベイクタイム：遅発障害を捕まえる

100%到達は終わりではありません。ベイクタイム（bake time） は、全展開後に旧版をすぐ破棄せず一定時間 観測する期間です。理由は、短い判定窓では絶対に見えない劣化があるからです。

• メモリリーク … 数十分〜数時間かけてOOMに至る。秒〜分の判定窓では検出不能。
• キャッシュ/コネクションの飽和 … ヒット率低下やプール枯渇が累積して顕在化。
• バッチ・cronの初回実行 … 日次処理が初めて回るのは展開から数時間後かもしれない。
• トラフィックパターン依存 … ピーク時間帯に入って初めて顕在化する飽和。

ベイクタイム中は旧版を稼働可能なまま残し、即時に重みを戻せる状態を維持します。これはブルーグリーンの「旧環境をしばらく残す」発想と同じで、遅発障害に対する保険です。ベイクが無事に明けて初めて旧版を破棄します。

判定設計の比較

実装の要点

最後に再強調すべきは、自動化の価値は速度ではなく再現性だという点です。同じ指標・同じ統計基準で毎回判定するからこそ、深夜のリリースでも担当者の経験差なく安全に倒せます。判定基準（有意水準・スコア重み・ベイクタイム）はコードとしてバージョン管理し、なぜその閾値なのかを根拠とともに残すことが、長期的な信頼性を支えます。