フレームワーク活用ガイドひとことで言うと#
ローリング・カナリア・ブルーグリーンなど複数のデプロイ方式の特徴を比較し、サービスの要件に合った戦略を選ぶためのフレームワーク。「どうやってリリースするか」もアーキテクチャの一部。
押さえておきたい用語#
- Rolling Deployment（ローリングデプロイ）
- インスタンスを少しずつ新バージョンに置き換えていく方式。ダウンタイムゼロで段階的に展開できる。
- Canary Deployment（カナリアデプロイ）
- 全体の一部（1〜5%）にだけ新バージョンを配信し、問題がなければ徐々に拡大する段階的リリース方式を指す。
- Blue-Green Deployment
- 同一構成の環境を2面用意し、トラフィックを一気に切り替える方式。瞬時のロールバックが可能になる。
- Recreate Deployment
- 旧バージョンをすべて停止してから新バージョンを起動する方式。最もシンプルだがダウンタイムが発生する。
- A/B Testing Deployment
- ユーザー属性に基づいて異なるバージョンを配信し、ビジネスメトリクスで比較評価する手法を指す。
デプロイメント戦略の全体像#
こんな悩みに効く#
- どのデプロイ方式を選べばいいかわからない
- ダウンタイムなしのデプロイを実現したい
- リリース時のリスクを定量的に下げたい
基本の使い方#
以下の3軸で自分のサービスの要件を明確にする。
- ダウンタイム許容度: ゼロ必須か、メンテナンスウィンドウがあるか
- ロールバック速度: 秒単位で戻したいか、数分で許容か
- リソース制約: 環境を2倍にするコストをかけられるか
| 要件 | 推奨戦略 |
|---|---|
| ダウンタイムゼロ + コスト低 | Rolling |
| ダウンタイムゼロ + リスク最小化 | Canary |
| 瞬時のロールバックが必須 | Blue-Green |
| ダウンタイム許容 + シンプルさ重視 | Recreate |
具体例#
従業員15名のSaaSスタートアップ。Kubernetesを採用しており、デプロイ方式はデフォルトのRolling Deploymentを使用。
maxSurge=1、maxUnavailable=0に設定し、常に最低限の稼働Podを維持しながら段階的に更新。
| 指標 | 値 |
|---|---|
| デプロイ頻度 | 日5〜8回 |
| デプロイ所要時間 | 約3分 |
| ダウンタイム | ゼロ |
| 追加インフラコスト | ほぼゼロ |
小さなチームで追加インフラコストをかけずにダウンタイムゼロを実現。新旧バージョンが混在する時間は最大3分で、APIの後方互換さえ守れば問題にならなかった。
月間GMV50億円の決済プラットフォーム。1分のダウンタイムで推定800万円の損失が出るため、ロールバック速度が最優先要件だった。
AWS ECSでBlue-Green環境を構築。ALBのターゲットグループ切り替えでデプロイとロールバックを実装。
- 新バージョン（Green）を起動し、ヘルスチェック通過を確認
- ALBのターゲットを一括切り替え（所要時間 約5秒）
- 問題発覚時は即座にBlueに戻す（所要時間 約5秒）
インフラコストは約1.8倍になったが、障害時の損失リスクを考えれば投資対効果は十分。過去1年間のデプロイ起因障害は ゼロ。
月間PV3,000万のメディアサイト。検索エンジンの大規模リファクタリングを控えており、全ユーザーに一気にリリースするのはリスクが高すぎた。
Istioを使ったCanary Deploymentを導入。
- 初日: 全トラフィックの1%を新バージョンに配信
- 3日目: 問題なしを確認し10%に拡大
- 7日目: 50%に拡大。検索精度の比較検証
- 10日目: 100%に展開
1%の段階でレイテンシの微増を検出し、インデックスの最適化を追加。修正後に再度1%から展開し直した。最終的に検索レスポンスが 20%改善 した状態でリリース完了。一気にリリースしていたら全ユーザーにレイテンシ悪化が影響していた。
やりがちな失敗パターン#
- 新旧バージョンの互換性を考えない — Rolling/Canaryでは新旧が混在する。APIやDBスキーマの後方互換を保つ設計が前提
- すべてのサービスに同じ戦略を使う — 内部ツールにBlue-Green、決済システムにRecreateは明らかに不適切。サービスごとに最適な方式を選ぶ
- Canaryのメトリクス比較を自動化しない — 目視でメトリクスを比較すると見逃しが起きる。CanaryとBaselineの自動比較（Kayenta等）を導入する
- Blue-Greenの旧環境をすぐに削除する — 問題は数時間後に判明することもある。旧環境は最低24時間は残しておく
まとめ#
デプロイメント戦略は 「ダウンタイム許容度」 「ロールバック速度」「リソース制約」 の3軸で選ぶ。多くのケースではRolling Deploymentが最初の選択肢になり、リスクの高いリリースにはCanary、瞬時のロールバックが必須ならBlue-Greenを使い分ける。どの方式を選んでも、新旧バージョンの互換性確保とデプロイ後の自動監視が成功の土台。