既存Deployment Processを改善する

ゴール

既存のデプロイプロセスについて、変更規模、手作業、影響範囲、フィードバック速度、復旧時間を評価し、現在の問題に応じて改善方向を選べる状態を目指します。

1. 最初に現在のデプロイを一連の流れとして見る

既存環境では、採用しているサービス名だけを確認しても改善点は分かりません。

変更作成
↓
テスト
↓
承認
↓
本番デプロイ
↓
正常性確認
↓
問題発生
↓
ロールバック

各段階について次を確認します。

改善は方式名からではなく、現在のボトルネックから始めます。

2. デプロイリスクは「失敗する確率」だけではない

変更が失敗する可能性が同じでも、100%の利用者へ同時に影響する場合と一部だけに影響する場合では業務影響が異なります。

また、5分で異常を検知できる場合と、利用者から連絡が来るまで1時間気付かない場合でもリスクは変わります。

したがって既存プロセスでは、変更規模、一度に影響する範囲、異常を検知するまでの時間、正常状態へ戻るまでの時間を組み合わせて評価します。

3. 一括方式自体を問題と決めつけない

一括方式が現在の業務要件を満たし、停止時間・復旧時間・変更リスクも許容範囲であれば、方式そのものを変更する必要はありません。

既存プロセスの改善では、一括方式を使っているかではなく、現在の一括方式で実際にどのリスクが発生しているかを確認します。

全面へ同時反映される
本番前の検証が不足している
成功確認が手作業
復旧時間を実測していない

このような問題がある場合は、その原因となっている部分を改善します。

4. 一括方式の問題は「100%へ同時に広がること」に現れる

すべての本番リソースへ同時に新バージョンを反映する場合、欠陥も全対象へ同時に広がります。

改善では、一度に変更する対象を減らせないか、新旧環境を並行保持できないか、本番で結果を確認してから次へ進められないかを検討します。

ここでローリングやブルー/グリーンなど、既習のデプロイ方式を改善手段として利用します。

5. ローリングでもバッチが大きければリスクは残る

ローリングデプロイを採用しているだけでは、安全なプロセスとは限りません。

100台

1回目
50台更新

正常性未確認

2回目
残り50台更新

この場合、最初の50台に問題があっても、そのまま全体へ広がる可能性があります。

改善では、バッチサイズを小さくする、各段階で正常性を確認する、異常なら次のバッチへ進まない、といった制御を検討します。

ローリングを使っているかではなく、どの単位で更新し、どこでフィードバックを得るかまで確認します。

6. ブルー/グリーンでも旧環境を早く消せば利点を失う

ブルー/グリーンでは新旧環境を並行して扱えます。しかし、新環境へ切り替えた直後に旧環境を削除し、その後に障害が判明すると、既知の正常環境へ短時間で戻せる利点を十分に使えません。

新環境へ切り替え
↓
新環境の正常性確認
↓
所定の確認期間
↓
旧環境を終了

既存プロセスでは、いつまで既知の正常環境を保持するかも運用上の判断として定義します。

7. ロールバックは「手順書がある」だけでは不十分

障害時は旧バージョンへ戻すという手順が存在していても、半年間試していない、現在の構成でも動くか不明、何分かかるか分からない場合があります。

この状態では、十分にロールバック可能とは評価できません。

改善では、既知の正常状態を特定できること、手順が現在も実行できること、要求時間内に戻れること、復旧後の正常性を確認できることを実際に確認します。

8. 大きな変更を低頻度で行うプロセスを見直す

3か月分の変更
↓
1つの大型リリース

変更点が多いほど原因候補が増え、復旧対象も大きくなり、1回の失敗による影響が大きくなりやすくなります。

改善方向は、小さな変更、高い頻度、戻しやすい単位です。

変更を減らすのではなく、1回あたりの変更を小さくするという考え方です。

9. デプロイ手順そのものを本番前に試験する

アプリケーションの機能テストに合格していても、本番だけ手順が違う、本番だけIAM設定が違う、本番だけネットワーク構成が違う場合、本番デプロイで初めて問題が発生することがあります。

改善では、本番に近い環境、本番と同じデプロイ設定、同じセキュリティ制御、同じ手順でデプロイプロセスそのものを試験します。

10. デプロイ完了と変更成功を分ける

デプロイ処理
成功

でも、ログインできない、注文が失敗する、レイテンシーが悪化するといった問題が残る可能性があります。

したがって、デプロイ処理が終了したことと、期待した業務結果を満たしたことは分けて確認します。

デプロイ
↓
自動テスト
↓
正常性シグナル確認
↓
成功条件を満たす？
│
├─ はい → 継続
└─ いいえ → 復旧判断

11. ロールバックを自動化する前に成功条件を明確にする

異常なら自動ロールバックと決めるだけでは不十分です。先に、何をもってデプロイ成功とするかを決めます。

例えば、エラー率、レイテンシー、ヘルスチェック、主要業務処理、自動テスト結果などです。

成功条件を満たさない
↓
ロールバック

ここでは個別サービスのロールバック機能ではなく、現在のデプロイプロセスに検証と復旧判断が組み込まれているかを評価します。

12. 独立した変更を1つの巨大なリリースにまとめない

アプリケーション変更、インフラストラクチャ変更、設定変更が互いに独立しているにもかかわらず、全部まとめて1リリースにすると、一部の失敗によって無関係な変更まで戻す必要が生じます。

独立して変更できる単位
↓
独立して検証
↓
独立して復旧

可能な場合は、デプロイと復旧の単位を分離します。

13. 改善案を「デプロイ時間だけ」で評価しない

現行10分、改善後25分となっても、それだけで改善失敗とは言えません。

一度に影響する対象
100% → 10%

異常検知
30分 → 3分

復旧
40分 → 5分

このように業務リスクが下がるなら、デプロイ時間が長くなることを含めて総合的に評価します。

速度、影響範囲、フィードバック速度、復旧時間、手作業、失敗時の業務影響を合わせて比較します。

14. 現在状態から改善方向を選ぶ

ブルー/グリーンの方が高度だから採用するのではなく、現在の問題から原因となるデプロイリスクを特定し、そのリスクを減らす改善を選びます。

15. 代表的なアンチパターン

16. SAP-C02判断フロー

既存環境で本番変更による障害が多い場合は、まず現在のプロセスを可視化してから改善点を探します。

現在のデプロイプロセスを可視化
↓
変更規模は大きすぎないか
↓
一度に影響する範囲は広すぎないか
↓
段階ごとのフィードバックがあるか
↓
本番前に同じ手順を試験しているか
↓
成功条件を自動判定できるか
↓
既知の正常状態へ
要求時間内に戻せるか

判断の目安

一括変更で全面影響
+ 段階展開可能
→ 影響範囲を限定する改善

ローリング
+ 大きなバッチ
+ 途中確認なし
→ バッチ縮小 + 正常性確認

ブルー/グリーン
+ 旧環境を即削除
→ 旧環境保持期間を見直す

大型・低頻度リリース
+ 原因特定が困難
→ 小さく戻しやすい変更

本番だけ手順が異なる
→ 本番相当環境でデプロイ手順を試験

デプロイ後の不具合検知が遅い
→ 成功条件 + 自動検証

ロールバック未検証
→ 復旧手順を試験して実際の復旧時間を確認

まとめ

既存のデプロイプロセス改善では、どのデプロイ方式が一番優れているかではなく、現在どこにリスクがあるかを確認します。

現在プロセスを可視化
↓
変更を小さくする
↓
影響範囲を限定する
↓
早くフィードバックを得る
↓
デプロイ手順を試験する
↓
成功条件を検証する
↓
要求時間内に復旧できるようにする

一括・ローリング・ブルー/グリーンは目的ではなく、現在のデプロイリスクを業務要件に合わせて下げるための手段として利用します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 3.1
• AWS Well-Architected Framework — Operational Excellence Pillar / Mitigate deployment risks
• AWS Well-Architected Framework — Make frequent, small, reversible changes
• AWS Well-Architected Framework — Test deployments
• AWS Well-Architected Framework — Automate testing and rollback