リリース手法の違いと採用判断

前のチームではBlue/Greenパターンをリリース手法として採用していた。
今のチームではローリングアップデートを採用している。

AWSを使っているか、K8を使っているかの違いではある。ただ、いつどんな時にどのリリース方法を採用するか自分の中で体系化されていなかったので整理しようと思った。

Blue/Greenパターン

システムやアプリケーションを停止せずに新しいバージョンをリリースするためのデプロイ手法

• Blue環境：現在稼働中の安定した本番環境（利用者がアクセスしている環境）。
• Green環境：新しいバージョンのアプリをデプロイしてテストする環境。

新しいリリースを行う際には、まず Green環境に新バージョンをデプロイして動作確認を行う。問題がなければ、ロードバランサやDNSの切り替えによってトラフィックを BlueからGreenに一気に移行する。

メリット

• ダウンタイムがほぼゼロ

  システムを止めずにリリース可能。

• ロールバックが容易

  万一問題が起きても、すぐにBlue環境に戻せる。

• 本番同等環境でのテストが可能

  切り替え前に新バージョンを実際の環境で検証できる。

---

デメリット / 課題

• 環境コストが高い

  BlueとGreenの2つの本番環境を同時に維持する必要がある。

• データベースの整合性

  DBのスキーマ変更やデータ移行が伴う場合は工夫が必要。

• 運用の複雑性

  トラフィック切替や監視の仕組みをきちんと整える必要がある。

カナリアリリース

ロードバランサーを用いて、旧環境と新環境に割り振る

段階を経てだんだん新環境の方に渡す割合を増やしていく手法

メリット

• 本番環境で少数のユーザーを対象に安全にテストできる。
• 問題が発覚しても影響範囲が限定的。
• 段階的に適用するためユーザー影響を最小化できる。

デメリット

• 運用が複雑（ユーザーやリクエストをどのように振り分けるか工夫が必要）。
• Blue-Greenほどシンプルにロールバックできない。
• ユーザー体験がバージョンごとに分かれる期間が発生。

小さい規模の開発なら使わない？結構手間のかかる印象。
IaCを使っていたので、その割り振り比率ごとのPRをつど使ってアプライしてる。(もっと良い方法があるのかも？

大規模な機能のリリースでよく使ってた。

ローリングアップデート

• 稼働中のサーバー群を 少しずつ順番に新バージョンに置き換えていく方法。
• Kubernetesなどのオーケストレーションツールでよく使われる。

メリット

• 追加コストが少ない（環境を2重に用意する必要がない）。
• サーバーごとに徐々に更新するため、サービスが途切れない。
• 自動化しやすい。

デメリット

• 更新中は新旧のバージョンが混在するため不整合リスクあり。
• ロールバックが面倒（途中で失敗すると再度全サーバーを戻す必要がある）。

実務だとロールバックに関してはCI/CD整備されていればさほど問題ではなかった。
整合性に関しては一から自分で用意する時は考えないと危なさそう。

採用判断フローチャート

フローチャートにするとこんな感じで良い気がする。また知見が溜まったら更新してみよう