新バージョンを最初に誰に届けるかを正確に制御したい場合
アプリケーションがアジア、ヨーロッパ、アメリカの3つのリージョンで動作していると想像してください。大規模なアップデートを終えたばかりですが、インフラの違いや利用パターンの違いによってどのような挙動を示すか確信が持てません。一度に全リージョンにプッシュしてうまくいくことを祈ることもできます。あるいはカナリアデプロイを実施し、ランダムなトラフィックの5%を新バージョンに流すこともできます。
しかし、問題がランダムに発生するとは限りません。アジアのユーザーはネットワーク構成が異なっていたり、プレミアムユーザーは無料ユーザーが決して触ることのない決済フローを利用していたりするかもしれません。ランダムな5%のスライスでは、障害が発生する正確なグループを見逃す可能性があります。
このような場合、カナリアデプロイが提供する以上の制御が必要になります。単に新バージョンにどれだけのトラフィックを流すかだけでなく、誰が新バージョンを利用するかを決定する必要があります。
ステージドロールアウトの本質
ステージドロールアウトとは、計画された順序に従って特定のユーザーグループに新バージョンをリリースするデプロイ戦略です。各グループは、アプリケーションにとって意味のある基準（地理的リージョン、アカウントタイプ、デバイスプラットフォーム、ユーザーIDの範囲、ルーティング可能なその他の属性）によって定義されます。
核となる考え方はシンプルです。各ステップで新バージョンに触れるユーザーを制御することでリスクを限定します。各グループを観察してから次のグループに移行します。問題が発生した場合、影響範囲は既知の管理可能なユーザーセットに封じ込められます。
これはカナリアデプロイとは異なります。カナリアはランダムなトラフィック割合を使用します。ユーザーが誰であるかは気にしません。ステージドロールアウトは、誰が何を得るかを重視します。グループ化は意図的であり、ビジネスまたは運用上のロジックに基づいています。
具体例：リージョンベースのロールアウト
3リージョンのシナリオに戻りましょう。アプリはアジア、ヨーロッパ、アメリカで動作しています。ネットワークレイテンシ、データセンター構成、または地域のコンプライアンスルールが、あるリージョンでは問題を引き起こすが、他のリージョンでは問題を引き起こさない可能性があると推測しています。
次のフローチャートは、3リージョンの例におけるステージドロールアウトのプロセスを示しています。
ステージドロールアウトでは、まずアジアにリリースします。チームは数時間または1日かけて、エラー率、応答時間、ユーザー報告の問題を監視します。すべてが安定しているように見えれば、ヨーロッパにリリースします。さらに観察期間を経て、アメリカにリリースします。
各ステージはチェックポイントとして機能します。アジアでデータベース接続エラーの急増が見られた場合、ロールアウトを停止し、問題を修正して最初からやり直します。他の2つのリージョンは、壊れたバージョンを目にすることはありません。
このパターンは、グローバルなユーザーにサービスを提供する企業で一般的です。また、公開リリース前の内部利用としても使用されます。内部ユーザーが最初に新バージョンを入手し、次に少数の外部アーリーアダプター、次に特定のリージョン、そして最後に全ユーザーという順序です。
別の例：アカウントタイプによるセグメンテーション
無料ユーザーとプレミアムユーザーがいるフィンテックアプリケーションを考えてみましょう。新しいリリースには、決済処理モジュールへの大きな変更が含まれています。問題が発生した場合、プレミアムユーザーは取引を完了できなくなり、収益の損失と顧客の不満を招く可能性があります。
無料ユーザーは決済機能を使用しません。彼らはより安全な最初のグループです。まず無料ユーザーにリリースし、アプリケーションの他の部分への副作用を監視してから、プレミアムユーザーにリリースします。
このアプローチが機能するのは、グループ化が地理だけでなく機能の使用状況に基づいているためです。リスクの低いグループを意図的に選び、初期の露出を吸収させています。
リングデプロイ：一般的なパターン
ステージドロールアウトは、しばしばリングデプロイとして実装されます。同心円状に広がるリングを想像してください。
- リング0: 内部チームとQA
- リング1: アーリーアダプターまたはベータユーザー
- リング2: 特定のリージョンまたは特定のアカウントタイプのユーザー
- リング3: 全ユーザー
各リングには、独自の基準、観察期間、ロールバック計画があります。内側のリングはより小さく、より安全です。外側のリングはより大きく、より多くのリスクを伴います。内側のリングで重大な問題が発生していない場合にのみ、外側に移動します。
このパターンは、すべてのリリースに対して明確で再現可能なプロセスを提供します。どのグループが最初に新バージョンを入手するか、どのくらいの期間観察するか、どのメトリクスが停止またはロールバックのトリガーとなるかを正確に把握できます。
ステージドロールアウトとカナリアの違い
重要な違いは意図性です。カナリアデプロイは「トラフィックの5%をランダムに新バージョンに送る」と言います。ステージドロールアウトは「アジアからのすべてのトラフィックを最初に新バージョンに送り、次にヨーロッパ、次にアメリカに送る」と言います。
カナリアは統計的です。ランダムサンプルがユーザーベース全体を代表すると仮定します。ステージドロールアウトはカテゴリカルです。異なるユーザーグループには異なるリスクプロファイルがあり、露出の順序を制御したいと仮定します。
どちらもリスクを低減しますが、異なる問題を解決します。カナリアは一般的な問題を早期に発見するのに適しています。ステージドロールアウトは、グループ固有の問題が広がる前に発見するのに適しています。
インフラストラクチャ要件
ステージドロールアウトは無料ではありません。トラフィックの割合だけでなく、属性に基づいてユーザーをルーティングできるインフラストラクチャが必要です。これは通常、以下を意味します。
- ヘッダーベースまたはクッキーベースのルーティングをサポートするロードバランサーまたはサービスメッシュ
- ユーザーコンテキストを読み取り、リクエストを正しいバージョンに振り向けるアプリケーションロジック
- 特定のユーザーグループにマッピングされるフィーチャーフラグまたはデプロイメントスロット
- グループごとにメトリクスをスライスできる可観測性ツール（グローバルだけでなく）
グループごとの可観測性がなければ、ステージドロールアウトは盲目的です。新バージョンを入手したグループと入手していないグループの間で、エラー率、レイテンシ、ビジネスメトリクスを比較する必要があります。グローバルなエラーチャートでは、ヨーロッパが正常でもアジアで障害が発生しているかどうかはわかりません。
ステージドロールアウトを使用すべきでない場合
ステージドロールアウトは複雑さを増します。変更が小さく、リスクが低く、ユーザーベースが均質な場合、ローリングアップデートまたはシンプルなカナリアで十分です。タイプミスの修正やマイナーなUI調整のためにデプロイ戦略を過剰に設計しないでください。
また、ルーティングレイヤーでユーザーグループを確実に識別できない場合、ステージドロールアウトはうまく機能しません。アプリケーションにユーザーアカウントがない場合、またはすべてのトラフィックがコンテキストなしで単一のエントリポイントを通過する場合、意味のあるグループを定義するために必要なデータがない可能性があります。
実践的なクイックチェックリスト
ステージドロールアウトを実装する場合、以下を正しく設定してください。
- グループは利便性ではなくリスクに基づいて定義する。最初のグループはルーティングが最も簡単なグループではなく、最も安全なグループであるべきです。
- 明確な成功基準を備えた観察期間を設定する。十分なデータが得られるまで次のステージに移行しない。
- 各ステージにロールバック計画を用意する。アジアで障害が発生した場合、他のリージョンに影響を与えずにアジアだけをロールバックできますか？
- グループごとの可観測性を確保する。ダッシュボードにはグループごとに分類されたメトリクスが表示される必要があります。
- ロールアウト計画をチームに伝達する。誰もがどのグループがライブで、次のステージがいつ開始されるかを把握している必要があります。
まとめ
ステージドロールアウトは、新バージョンを最初に誰に届けるかを制御する手段を提供します。これはカナリアデプロイの代替ではありません。異なる状況のための異なるツールです。ユーザーがすべて同じではないことがわかっており、最も価値のある、または最も脆弱なグループを最後に露出させることで保護したい場合に使用します。
次にリスクの高いリリースを計画するときは、自問してみてください。「これが失敗した場合、どのユーザーグループを最初に壊しても最もダメージが少ないか？」そのグループが最初のステージです。