なぜ「開発→テスト→本番」の一括デプロイは限界を迎えるのか
カナリアリリース Kubernetes という言葉を検索している時点で、多くのチームはすでに気づいている。開発環境でテストし、ステージングを通し、本番環境にデプロイする——この一直線のフローを何段階に増やしても、本番障害はゼロにならないという事実に。
QAエンジニアがどれだけ丁寧にテストしても、決済処理の二重クリックや特定のブラウザ環境でのエッジケースをすべて事前に洗い出すことはできない。実際、Kubernetesの標準デプロイ戦略であるRolling Updateは、maxUnavailableとmaxSurgeという2つのパラメータ（デフォルトはそれぞれ25%）でPodを段階的に入れ替える仕組みを持っているが、これはあくまで可用性を保ちながらデプロイを完了させるための仕組みであり、「新しいバージョンにバグがあった場合に被害を最小化する」ための設計ではない(Kubernetes公式ドキュメント)。
つまり、Rolling Updateだけでは「デプロイが終わったら全ユーザーが新バージョンを使っている」状態になるのが早いか遅いかの違いでしかなく、バグの影響範囲をコントロールする仕組みにはならない。ここで必要になるのが、トラフィックそのものを段階的に新バージョンへシフトさせるカナリアリリースという考え方だ。
一般的なデプロイ戦略には、瞬時に旧環境から新環境へ全トラフィックを切り替えるBlue-Green、Podを少しずつ入れ替えるRolling Update、そしてトラフィックの一部だけを新バージョンに向けるCanaryの3種類がある。実務では、決済や認証のように即座のロールバックが重要なサービスにはBlue-Greenを、それ以外の大半のサービスにはRolling UpdateとCanaryの組み合わせを採用するケースが多いとされる(Kubernetesデプロイ戦略比較記事)。
こうした仕組みを本番運用に組み込むには、監視基盤やGitOps連携をどこまで自前で構築するかという判断が必ずついて回る。この点は記事後半で、KuboのようなGitOps・監視標準搭載のマネージドK3s基盤を使う場合の選択肢としても触れる。
カナリアリリースの基本設計 — 1%→10%→100%はなぜ機能するのか
カナリアリリースの核心は、「小さく試して、問題がなければ拡大する」という単純な原則にある。Kubernetesエコシステムでこれを実現する代表的なツールがArgo Rolloutsだ。Argo RolloutsではsetWeightでトラフィック配分の割合を指定し、pauseで一定時間待機するというステップを積み重ねてロールアウトを制御する(Argo Rollouts公式ドキュメント)。
例えば10台のPodがある構成で新バージョンへの配分を10%に設定すると、コントローラは新バージョンPod1台・旧バージョンPod9台という比率に近づけようとする。より厳密なトラフィック制御が必要な場合は、サービスメッシュやIngressコントローラと連携したトラフィックルーティングを使う設計が推奨されている(同上)。
実際に大規模サービスでこの仕組みを導入した事例では、Argo CDを既に導入していたことによる親和性の高さや、サービスメッシュを別途導入しなくても最小限の構成で始められる点が採用理由として挙げられている(ZOZO TECH BLOG)。同事例では、Pod単位でのトラフィック分散という比較的シンプルな構成からスタートし、必要に応じて高度化していくアプローチが取られている。
ここで重要なのは、「最初から完璧な構成を目指さない」という発想だ。Argo Rollouts公式のベストプラクティスでも、Blue-Greenのようなシンプルな戦略から始め、メトリクスとアプリケーションへの理解が深まってからカナリアへ移行することが推奨されている(Argo Rollouts Best Practices)。
Kubo文脈での実践ポイント
- K3sベースの軽量クラスタでも動作: Argo Rollouts自体はKubernetesのCRD(Custom Resource Definition)として動作するため、K3sのような軽量ディストリビューションでも導入できる
- 段階的に高度化する設計: 最初はPod比率ベースの単純な分散、慣れてきたらサービスメッシュ連携へ
「気づいたら手遅れ」を防ぐ自動ロールバックの仕組み
カナリアリリースの真価は、トラフィックを分割することそのものではなく、「異常を自動で検知し、人間の判断を待たずにロールバックする」仕組みと組み合わさって初めて発揮される。
監視の基盤としてよく使われるのがPrometheusとGrafanaの組み合わせだ。Grafanaが提供するSLO(Service Level Objective)機能では、エラーバジェット——「100% - SLO目標値」で算出される許容失敗率——の消費速度に応じて2種類のアラートを使い分ける設計が推奨されている。数時間から数日かけてエラーバジェットが消費される場合に発火する「Slow-burn」アラートと、数分から数時間という短時間で急激に消費される場合に発火する「Fast-burn」アラートだ(Grafana公式ドキュメント)。カナリアリリースの自動ロールバック判定には、この後者の「Fast-burn」に近い、短時間で急激な異常を検知する仕組みが必要になる。
実際の運用では、こうした監視基盤とカナリアリリースの仕組みを連携させ、定義した基準を超えるエラーを検知した時点で自動的にロールバックを発動させる構成が採用されている。従来のGit操作を伴う手動ロールバックと比べて、瞬時に旧バージョンへ復帰できる点が大きな違いだ(ZOZO TECH BLOG)。Argo Rollouts自体にも、バックグラウンドで解析を実行し失敗時には自動的にロールアウトを中止するAnalysisRunという仕組みが用意されている(Argo Rollouts公式ドキュメント)。
理想を言えば、5分から15分程度でデプロイの成否を自動判定できる状態を目指したい。判定が長引くほど、カナリア期間中に問題のあるバージョンがトラフィックを受け続けるリスクが積み上がるからだ。
GitOpsと組み合わせて「デプロイの意思決定」をコード化する
カナリアリリースと自動ロールバックの仕組みは、GitOpsと組み合わせることでさらに堅牢になる。GitOpsの考え方では、Gitリポジトリが「あるべきインフラの状態」を表す唯一の情報源(single source of truth)になる。ArgoCDがGit上のマニフェスト変更を検知して自動的にクラスタへ同期し、Argo RolloutsのUIやCLIからロールアウトの状態(進行中・異常・正常)を確認できる連携が可能だ(Argo Rollouts公式)。
この構成の利点は、「誰が」「いつ」「どのバージョンを」デプロイしたかがすべてGitの履歴として残ることだ。手動でのkubectl操作に依存しないため、担当者が不在でも別のメンバーがGitの状態を見て何が起きているかを把握できる。これは、属人化した障害対応から抜け出すための土台になる。
小規模チームがこの仕組みを「運用し続けられる」ためのインフラ選び
ここまで紹介してきたカナリアリリース、自動ロールバック、GitOpsという仕組みは、いずれも技術的には確立されている。しかし現実には、これらを自前でゼロから構築し、監視ダッシュボードやアラートルールを継続的にメンテナンスし続けるのは、専任のプラットフォームチームを持たない中小規模のチームにとって決して軽くない負荷だ。
Prometheus/Grafanaのセットアップ、ArgoCDのバージョン管理、Argo Rolloutsのアップグレード対応——これらは「一度作って終わり」ではなく、継続的な運用コストを伴う。
Kuboはこうした負荷を前提に設計されたマネージドK3sサービスだ。GitOps対応(ArgoCD/Fluxとの統合)とモニタリング(Prometheus + Grafana)が標準搭載されているため、この記事で紹介したカナリアリリースの土台となる基盤をゼロから構築する必要がない。K3sという軽量なKubernetesディストリビューションをベースにしながら、標準的なKubernetesの機能はそのまま使えるため、Argo Rolloutsのような標準的なCRDベースのツールもそのまま導入できる。
コスト面でも、4vCPU/8GB/40GBのノード3台構成で比較した場合、Kuboは月額48,000円程度に対し、AWS EKSは82,700円、Azure AKSは85,710円という試算がある。GitOpsと監視基盤を自前で構築・維持する人件費まで含めて考えると、この差はさらに大きくなる。セキュリティ要件からオンプレミス運用が必要な場合は、Kubo On-Premiseであれば同様の仕組みを自社インフラ内で完結させることも可能だ。
まとめ
段階的デプロイは、「慎重さ」を優先して速度を犠牲にするための仕組みではない。むしろ、安全に、そして速く変更を届け続けるための設計だ。
- Rolling Updateだけでは可用性は保てても、バグの影響範囲はコントロールできない
- カナリアリリースは1%→10%→100%とトラフィックを段階的に拡大し、影響範囲を限定する
- 自動ロールバックは、エラーバジェットの急激な消費(Fast-burn)を検知して人間の判断を待たずに発動させる設計が理想
- GitOpsと組み合わせることで、デプロイの意思決定そのものがコード化され、属人化を防げる
これらを小さく始め、少しずつ自動化の範囲を広げていくことが、本番障害に怯えないデプロイ設計への近道だ。監視・GitOps基盤の構築・維持に悩むなら、Kuboのようにこれらが標準搭載されたマネージドK3s基盤から始めてみるのも一つの選択肢だろう。まずはお問い合わせから、自社の構成に合った導入方法を相談してみてほしい。