LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

一括デプロイの問題とリリース戦略の必要性

カナリアリリースとは、新バージョンを一部のトラフィックにのみ公開し、メトリクスを確認しながら段階的に対象範囲を広げるリリース手法である^*1。ソフトウェアデザインパターンの提唱者として知られるMartin Fowler氏のブログ（bliki）でDanilo Sato氏が2014年に整理した定義では、「新しいソフトウェアのバージョンをゆっくりと小さなユーザーのサブセットに展開し、インフラストラクチャ全体に展開する前にテストする技術」とされている^*1。

これに対して一括デプロイ（ビッグバンリリース）は、新バージョンを全ユーザーへ同時に反映する方式です。デプロイ作業自体は単純ですが、不具合が本番環境に潜んでいた場合、影響範囲を絞り込む手立てがありません。

Kubernetesの標準的なDeploymentが備えるローリングアップデート戦略でさえ、Podを制御された速度で置き換える仕組みは持つものの、新バージョンへのトラフィック配分を細かく制御したり、外部の監視指標をクエリして自動でロールバックしたりする機能は備えていません^*2。この制約を補うために生まれたのが、カナリアリリースやブルーグリーンデプロイといった、トラフィック制御と組み合わせたリリース戦略です。

ローリング・ブルーグリーン・カナリア－3つのデプロイ戦略

デプロイ戦略にはいくつかの型があり、それぞれ狙いと使いどころが異なります。まず整理すべきは、Kubernetes公式ドキュメントが定義するローリングアップデートです。これは古いReplicaSetを段階的に縮小しながら新しいReplicaSetを段階的に拡大し、制御された速度でPodを置き換える更新戦略です^*2。可用性を保ちながら更新できる一方、公式ドキュメントの説明どおり、新旧バージョンへのトラフィック配分を細かく指定する機能や、外部の監視指標を見て自動でロールバックする機能は持ちません^*2。

次にブルーグリーンデプロイです。Martin Fowler氏が2010年に公開し2015年に更新した記事によれば、これは「できる限り同一な2つの本番環境」を用意し、一方を稼働系として使う手法です^*3。新バージョンをもう一方の環境に展開して最終テストを済ませ、ルーターの切り替えでユーザーからのリクエストを新環境へ移します。問題が起きた場合は「ルーターを元に戻すだけ」で復旧でき、この切り戻しの単純さが特徴の1つです^*3。

これに対しカナリアリリースは、新旧を丸ごと切り替えるのではなく、新バージョンをインフラの一部にのみ展開し、ランダムに抽出したユーザーや従業員などの限定対象にルーティングします^*1。メトリクスを監視しながら対象ユーザーを段階的に広げ、問題が見つかれば旧バージョンに戻す仕組みです^*1。実際の本番トラフィックでの容量検証ができる点も、Fowler氏のブログで挙げられている利点です^*1。

このカナリアリリースを、フィーチャーフラグなど複数の技術と組み合わせて継続的に運用する広い実践を指す言葉が「プログレッシブデリバリ」です。新機能を段階的に展開し、主要指標を監視しながら、問題が生じた場合はロールアウトを自動で停止・ロールバックする考え方として整理されています^*4。カナリアリリースは、プログレッシブデリバリを実現する代表的な手法の1つと位置づけられます。

カナリアリリースの流れ－トラフィック分割から自動判定まで

実際のカナリアリリースは、次のような段階を踏みます。第一に、新バージョンをインフラの限定部分にデプロイします。第二に、ランダムサンプルや社内ユーザーなど、少数の対象に新バージョンをルーティングします^*1。

第三に、対象を拡大しながらメトリクスを監視します。Kubernetes向けのプログレッシブデリバリツールであるArgo Rolloutsの公式ドキュメントでは、新バージョンに本番トラフィックの一部を一定時間与えたうえでスケールダウンして指標を確認する運用や、パーセンテージを段階的に引き上げながら各段階の間で待機する運用が紹介されています^*5。

第四に、合否判定です。ここが一括デプロイやブルーグリーンデプロイと大きく異なる部分といえます。Argo Rolloutsは複数のメトリクスプロバイダ（PrometheusやDatadogなど）に問い合わせてKPIを検証し、自動での昇格またはロールバックを実行できる仕組みを備えています^*5。人手による目視確認を待たずに、あらかじめ定義した指標のしきい値で機械的に判定する点が特徴です。

この自動判定に使われる指標は、エラー率やレイテンシなど、あらかじめ合意したSLO（サービスレベル目標）に基づくのが一般的です。しきい値を下回った場合は、トラフィックが正常バージョンへ戻され、新バージョンの比率がゼロまで縮退します。Kubernetes向けのプログレッシブデリバリオペレーターであるFlaggerも、Prometheus・InfluxDB・Datadog・New Relicなどのデータソースを使った分析と、Slack・Microsoft Teamsなどへの通知連携を備えるとされています^*6。

プログレッシブデリバリを支えるツール群の考え方

プログレッシブデリバリを実装するツールには、いくつかの選択肢があります。優劣を一概に断定できるものではなく、既存のインフラ構成やチームの運用体制に合わせて検討すべき領域です。ここでは代表的な2つの考え方を紹介します。

Argo Rolloutsは、Kubernetesコントローラと複数のカスタムリソース定義（CRD）によって、ブルーグリーン・カナリア・実験的な配置・プログレッシブデリバリの機能を提供します^*5。Ingressコントローラやサービスメッシュと連携し、更新中に段階的なトラフィックシフトを実現する点が特徴です^*5。

もう一方のFlaggerは、Kubernetes上で稼働するアプリケーションのリリースプロセスを自動化するプログレッシブデリバリツールです^*6。新バージョンへのトラフィック段階移行、メトリクス測定、適合性テストの実施によって、本番環境でのリスクを抑える仕組みを持ちます^*6。いずれのツールも、サービスメッシュやIngressコントローラといったトラフィック制御基盤と組み合わせて動作する前提である点は共通しています。

自社でこうしたツールを内製導入するには、Kubernetesの運用知識に加え、メトリクス基盤（Prometheus等）の構築・運用、SLOの設計、CRDやAnalysisTemplateの記述といった専門知識が必要です。目安として、基盤構築から初回リリースパイプラインの稼働までには、複数名体制での検証期間を要する取り組みになります。

外注でカナリアリリースを導入する委託範囲

カナリアリリースの導入を外注する場合、委託範囲は大きく3つに分けて整理すると発注しやすくなります。

1つ目は、トラフィック制御基盤の設計・構築です。サービスメッシュまたはIngressコントローラを用いたトラフィック分割の仕組みを、既存のKubernetesクラスタや周辺システムに合わせて設計する工程です。

2つ目は、メトリクス基盤とSLOの設計です。エラー率やレイテンシなど、どの指標を自動判定に使うかを定義し、しきい値と監視の仕組みを整備します。ここを曖昧にすると、自動ロールバックの判定基準が定まらず、カナリアリリースを導入しても運用が属人化するリスクがあります。

3つ目は、CI/CDパイプラインへの組み込みです。Argo RolloutsやFlaggerのようなプログレッシブデリバリツールをデプロイフローに組み込み、段階的な展開ルールとロールバック条件をコード化する工程です。

これら3つは互いに独立した専門領域であり、いずれか1つでも欠けると段階的リリースの効果が限定的になります。外注先を選定する際は、トラフィック制御・メトリクス設計・CI/CD統合のどこまでを対応範囲としているかを、提案依頼段階で明確にすることが実務上重要です。

発注準備で整理すべき4つの論点

外注先へ発注する前に、発注側で整理しておくべき論点は次の4つです。

1. 対象システムの構成です。Kubernetes上で稼働しているか、既存のIngressコントローラやサービスメッシュの有無を洗い出します。
2. 合否判定に使う指標です。エラー率・レイテンシ・ビジネス指標のうち、どれを自動判定の基準にするかをあらかじめ関係者間で合意します。
3. ロールバック時の運用フローです。自動ロールバックが発生した際に、誰が検知し、誰が原因調査に着手するかの体制を決めます。
4. 段階的展開の刻み方です。初期配信比率や拡大までの待機時間をどう設定するかは、サービスの利用者数や許容できるリスクの大きさに応じて検討する必要があります。

これらを発注前に整理せずに着手すると、外注先が提案するデフォルト値をそのまま採用することになり、自社のリスク許容度に合わない運用になりかねません。特に合否判定の指標は、自社のSLOと紐づけて発注仕様に明記しておくべき事項です。

加えて、内製で判定基準の設計まで担う体制がない場合、CRDやAnalysisTemplateの記述、メトリクスクエリの調整といった専門作業には相応の学習コストがかかります。トラフィック制御基盤の構築・メトリクス設計・CI/CD統合を専門パートナーに委託した場合と、社内エンジニアだけで内製した場合とでは、初期設計にかける時間配分と、判定ロジックの検証範囲に違いが生じます。委託する場合は、自社のSLOや既存インフラの制約を発注時点で正確に伝えられるかどうかが、導入後の運用品質を左右します。

まとめ：カナリアリリース導入の3つの判断軸

本稿では、一括デプロイの課題からローリング・ブルーグリーン・カナリアという3つのデプロイ戦略の違い、カナリアリリースの段階的展開と自動判定の流れ、外注時の委託範囲までを整理しました。要点を3つに集約すると、第一にカナリアリリースは新バージョンを一部トラフィックへ限定公開しメトリクスで合否判定する手法である点、第二に自動ロールバックの精度はSLO設計とメトリクス基盤の整備に左右される点、第三に外注時はトラフィック制御・メトリクス設計・CI/CD統合の3領域を委託範囲として明確にすべき点です。段階的なリリース戦略の導入を検討する際は、自社のシステム構成とリスク許容度を踏まえたうえで、どこまでを内製し、どこから外部パートナーに委ねるかを判断することが実務上のポイントになります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Martin Fowler氏公式ブログ（Danilo Sato）「CanaryRelease」（https://martinfowler.com/bliki/CanaryRelease.html）（2014年）
2. *2　出典：Kubernetes公式ドキュメント「Deployments」（https://kubernetes.io/docs/concepts/workloads/controllers/deployment/）
3. *3　出典：Martin Fowler氏公式ブログ「BlueGreenDeployment」（https://martinfowler.com/bliki/BlueGreenDeployment.html）（2010年公開・2015年更新）
4. *4　出典：Unleash「Canary release vs progressive delivery: What’s the difference?」（https://www.getunleash.io/blog/canary-release-vs-progressive-delivery）
5. *5　出典：Argo Rollouts公式ドキュメント（https://argo-rollouts.readthedocs.io/en/stable/）
6. *6　出典：Flagger公式ドキュメント（https://docs.flagger.app/）

Tweet