はじめに
Google CloudのProfessional Cloud DevOps Engineer試験勉強の学習記録です。
デプロイ手法やテスト戦略について整理します。
学習記録のため実現例はGCPに寄っていますが、デプロイ手法やテスト戦略自体は一般的な説明（のはず）です。
ブルー/グリーンデプロイ (Blue/Green Deployment)
本番環境に「ブルー（現行）」と「グリーン（新）」という2つの環境を用意し、一発で（0%から100%に）切り替えてリリースする
- 今すぐ本番として扱える環境が2つ同時に存在する
- そのため2環境分のコストがかかる
- Green上でテストを行い、問題なければトラフィックをBlueからGreenに一気に切り替える
- 本番で問題が起きれば、またBlueに戻す
- 切り替えは一発で行う（0% -> 100%, 100% -> 0%）ので、即座に切り替え / 切り戻しができる
- 高速で切り替えられるため、リスクが小さいがコストが高い
- デプロイ時の可用性が求められるシチュエーションで使用される
- バージョンアップなどで障害が起こってもできるだけダウンタイムを短くしたい、など
- ちなみにRed/Black Deploymentとも呼ばれる
- この場合はRedが現在のバージョンでBlackが新しいバージョン
GCPでの実現例
- Cloud RunでTrafficを 0% → 100% に切替
- GKE で Ingress / Service のラベル切替によるルーティング変更
- App Engine のバージョン切り替え（100%切り替え）
など
カナリアリリース（カナリアテスト / カナリアデプロイメント）
少数のトラフィックだけを新バージョンに流し、段階的に本番環境に展開するリリース戦略
- ごく一部のトラフィックだけ新しいバージョンに流す
- リスクを限定しつつ、本番トラフィックで新バージョンを試せる
- 追加した機能やパフォーマンス改善の検証ができる
- 問題がなければ段階的にトラフィックを増やす
- 問題があれば即座に切り戻せる（元のバージョンにロールバックできる）
- 問題の例: 想定以上のパフォーマンス負荷がある、など
- 逆に言うと、すぐに元に戻せる体制を整えておくことも重要
- 問題を解決したら修正して次のリリースに回す
GCPでの実現例
- Cloud RunのTraffic分割利用
- 新バージョンに10%、旧バージョンに90%といった具合に、段階的にトラフィックを移行できる
- 問題が発生した場合は即座にトラフィック割合を変更して、旧バージョンに戻すことも可能
- GKE + Istio の weighted routing によるトラフィック分割
- GKE Gateway（Gateway API）の traffic split
- Cloud Load Balancing（バックエンド重み付け）での段階移行
など
シャドウテスト (Shadow Test / Mirroring)
実際のトラフィックを複製して新バージョンにも送信するが、ユーザーには新バージョンの結果を返さない。
- 本番トラフィックを利用しつつ、実際のレスポンスには影響しない
- 負荷・互換性・パフォーマンスを安全に検証できる
- ただしトラフィック倍増に注意
GCPでの例
- Istio / Anthos Service Mesh の Traffic Mirroring
- Envoy ベースのプロキシでのミラーリング
ローリングアップデートデプロイ (Rolling Update)
旧バージョンを徐々に新バージョンへ置き換える方式。
- サービスを止めずに少しずつ置き換える
- ロールバックも比較的容易
- 完了までの間は一部のPod/VMが旧バージョンのまま
GCPでの例
- GKE の Deployment（RollingUpdate がデフォルト）
- Managed Instance Group (MIG) の rolling update
再作成デプロイ (Recreate Deployment)
旧バージョンを完全に停止してから新バージョンをデプロイする、一番シンプルな方式
- 旧バージョンを旧環境を一旦落とし、それから新環境を起動する
- 最もシンプルで基本的なデプロイのやり方
- 同時に動作するバージョンは1つだけ
- ダウンタイムが発生する