デプロイ戦略

デプロイ戦略とは

デプロイ戦略とは、作ったアプリケーションの新バージョンを本番環境へどう切り替えるかの方式のことです。

素朴にやるなら「サーバーを止めて、新しいコードを置いて、起動し直す」で済みます。しかし24時間動くサービスではその停止時間が許されませんし、新バージョンに不具合があったときに素早く戻せる備えも要ります。そこで、停止時間と切り戻しやすさ、そして必要なリソース量のバランスを取った方式が使い分けられます。

主な方式の比較

ローリングデプロイ

10台あるサーバーを2台ずつ新バージョンに入れ替えていく方式です。[[ロードバランサ]] が切り替え中の台を振り分け対象から外すことで、利用者には停止が見えません。[[Kubernetes]] の標準的な更新方式もこれにあたります。

注意点は、途中で新旧のバージョンが同時に動くことです。データベースのスキーマを変える更新では、旧版でも新版でも動く形にしておく必要があります。

ブルーグリーンデプロイ

現行環境(ブルー)とは別に、新バージョンの環境(グリーン)を丸ごと立ち上げます。動作確認を済ませてからルーティングを一気に切り替え、問題があればブルーに戻すだけで復旧できます。

切り戻しが最速という強力な利点がありますが、一時的に環境が2つ必要でコストがかかります。

カナリアリリース

炭鉱のカナリアが名前の由来です。まず利用者の5%だけを新バージョンに振り向け、エラー率や応答時間を観察します。問題がなければ25%、50%と広げ、異常が出たらすぐ戻します。

本番でしか起きない問題を、影響範囲を限定して発見できるのが強みです。判断材料になる指標を見られる監視体制が前提になります。

実務のポイント

• どの方式でも、切り替えを自動化してくれるのは [[CI/CD]] のパイプラインです。手作業の切り替えは事故のもとになります
• 切り戻し手順を先に決めておくこと。「戻せる」と分かっているからこそ、安心して前に進めます
• コードのデプロイと機能の公開を分離したいときは [[フィーチャーフラグ]] を併用します。先にコードを本番へ入れておき、公開はスイッチで制御する形です
• データベースの変更は元に戻しにくいため、コードより先に「新旧どちらでも動く」状態を作ってから進めます

初学者向けポイント

• 「デプロイ」はコードを本番に置くこと、「リリース」は利用者に機能を届けることです。フィーチャーフラグを使うとこの2つを別々に扱えます
• 小さく頻繁にデプロイするほど、1回あたりの変更量が減って事故の原因を特定しやすくなります。[[DevOps]] が頻度を重視するのはこのためです
• 深夜作業でしかリリースできない状態は、デプロイ戦略の改善余地があるサインです

関連技術とのつながり

• [[CI/CD]] — デプロイを自動実行するパイプラインの土台
• [[フィーチャーフラグ]] — デプロイと機能公開を切り離し、リスクをさらに下げる
• [[DevOps]] — 小さく頻繁にデプロイする文化を支える考え方
• [[ロードバランサ]] — 無停止の切り替えを実現する振り分け役
• [[Kubernetes]] — ローリング更新を標準機能として備えるプラットフォーム
• [[コンテナレジストリとイメージ管理]] — 旧版のイメージが残っているから切り戻せる

Q: 切り戻しが最も速いデプロイ方式はどれ?
- [ ] ローリングデプロイ
- [x] ブルーグリーンデプロイ
- [ ] 再作成デプロイ
解説: ブルーグリーンは旧環境が丸ごと残っているため、ルーティングを戻すだけで即座に復旧できます。

Q: カナリアリリースの説明として正しいものはどれ?
- [x] まず一部の利用者にだけ新バージョンを出して様子を見る
- [ ] 全サーバーを停止してから一斉に入れ替える
- [ ] 旧バージョンを完全に削除してから新バージョンを配置する
解説: 影響範囲を限定したうえで本番の指標を観察し、問題がなければ段階的に広げていく方式です。

Q: ローリングデプロイで特に注意すべき点はどれ?
- [ ] 必ず停止時間が発生すること
- [x] 途中で新旧のバージョンが同時に動くこと
- [ ] サーバー台数が2倍必要になること
解説: 順番に入れ替えるため移行中は新旧が混在します。データベースのスキーマ変更などは両方で動く形にしておく必要があります。