段階的リリースが可能な設計になっているか？¶
Type: DeepDive
Category: リリース・ロールバック
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
本番環境でのリリースを一気に行うと、障害時の影響範囲が大きくなる
カナリアリリース、Feature Flag、ABテストなどの段階展開の仕組みを設計時点から想定することで、安心して変更を本番に導入できる
例¶
- Feature Flag を切り替えて、社内ユーザーから先行有効化
- リビジョン併用や段階的なトラフィック切替により、トラフィックの50%を新バージョンに振る設定（例：Cloud Run のリビジョン機能、AWS App Runnerのトラフィックルーティング、Azure Container Apps のリビジョンベースデプロイ）
- リリース日は画面上にバナーを表示して、段階リリースへの意図を明示
よくある失敗例¶
- カナリアリリースを意識せずコードを組んだため、バージョン差分が生じて不整合
- フィーチャーフラグの制御が雑で、想定外のユーザーに変更が展開されてしまった
- バージョン切替でログ解析が困難になり、問題検知が遅れた
FAQ¶
Q. Feature Flagは技術的負債にならない？
A. リリース後に早期で削除する運用ルールを整備すれば問題なし。Flag削除漏れが一番の負債原因
Q. カナリアリリースはどの単位でやるべき？
A. 機能単位・ユーザー属性・リクエスト量など。最小単位で切替できると柔軟性が高くなるがケースバイケース