このブログでは、VMware Cloud Foundation® 9（および最新の9.1）の新機能である VMware Cloud Foundation® Automation（VCF Automation） を複数回のテーマに分けてご紹介しておりまして、今回がいよいよ第6部となります。
前回の第5部では、アプリケーション開発者が享受できるセルフサービス IaaS 体験や、ポータル画面からの直感的な「VM Service」を用いたVMデプロイ手法について解説しました。
最終回となる第6部では、これまでの自動化技術を統合した形でフル活用することで、現代の企業ITが直面しているクリティカルな課題に向かい合っていく点にフォーカスします。それは、「フロンティアAI時代における脆弱性へのより早い修正対応・安全な対応サイクル」に対する VCF Automation の利活用です。
AIの進化によって脆弱性の発見ペースが劇的に加速し、推論による組み合わせや多角的な新たなサイバー攻撃手法が次々と生まれる昨今、本番インフラの更新（パッチ適用、設定修正）は数週間・数か月も引き延ばすことはできません。１日や数日といった一刻も早く安全な「パッチ適用・検証・本番切り替え」を回す仕組みの重要性が増しています。
この要求に対してサーバーワークロードのライフサイクルをより早く回す仕組みとして利活用できるのが、 VCF 9.1 で搭載された「App Stack Formation」と言われる新たなアプローチです。アプリケーション動作環境とインフラを丸ごと自律取得し、安全なパッチ検証環境を1クリックでセルフプロビジョニングし、Blue-Greenデプロイで安全に切り替えるといった利用を可能にします。その仕組みについて解説していきます。
App Stack Formation を使った脆弱性対応・パッチ検証の「6ステップ」
VCF Automation では、App Stack Formation という仕組みを活用することで、インフラまで含めたアプリケーションのライフサイクル管理を非常に簡素化することができます。
これをどのように活用できるか、本番環境の再現・安全な検証プロセスの実施といったアプリケーションのライフサイクルを例にして、詳細を具体的な6つのステップに沿って解説します。
STEP 1
既存本番環境（Namespace）のキャプチャ
現在、外部公開されている本番稼働環境（名前空間: CRM）に対して脆弱性が発見されたと仮定します。この CRM 環境には、web01（Nginx）、app01（Tomcat）、db01（PostgreSQL）といった3層構成のVM、それらを隔離する専用VPCネットワーク、さらに「HTTPS(443)のみを許可する最小権限のアクセスルール」が組まれたファイアウォール（vDefend）が動いています。
VCF Automation は、こうした稼働環境を予めキャプチャしておくことができます。
STEP 2
Blueprint（ブループリント）の自律的な自動生成
キャプチャしておいた CRM 環境の構成要素に基づき、VCF Automation が自動的に宣言型 YAML テンプレート（Blueprint）を生成します。このときVCF Automation が自律的に収集る情報には以下のようなものが含まれます：
- VM構成: vCPU、メモリ、割り当てられたVMイメージディスク
- ネットワーク: 専用VPC、サブネット構造、ゲートウェイ（VPC GW/TGW）および vDefend セキュリティルール（境界FWポリシー）
- ストレージ: 追加された永続ボリュームなど
- 起動順序: データベース（db01）➔ アプリサーバー（app01）➔ Webサーバー（web01）などという順序関係を「仮想マシン グループ（VirtualMachineGroup）」とパワーオン遅延設定により整合性を保持
STEP 3
ブループリントの編集・パラメータ化（パターン管理）
キャプチャしておいた本番環境（Blueprint）を、開発用やステージング用、または将来の新本番用としてデプロイしやすいようにパラメータ化（パターン設計）します。用途に合わせて、同じBlueprintから異なるスペックで再展開できるよう変数設計（環境別パラメータ設定）を行うこともできます：
| 対象環境 | web01 / app01 構成スペック | 接続される専用VPC |
|---|---|---|
| 開発検証用 (Dev) | 2 vCPU / 4 GB メモリ | Dev-VPC |
| テスト検証用 (Test) | 4 vCPU / 8 GB メモリ | Test-VPC |
| 新しい本番環境 (Prod) | 8 vCPU / 16 GB メモリ | Prod-VPC |
STEP 4
サービスカタログへの登録・公開
構成された Blueprint を組織内の「サービスカタログ」に公開することで、開発・テストチームへスムーズに解放することができます。これにより、パッチ検証に必要な環境の定義（CRMパッチ検証環境）がカタログアイテムとして出来上がり、組織の中のメンバーがセルフサービスで利用できるようになります。
STEP 5
検証環境のセルフサービス展開 ＆ パッチ適用
開発チームやパッチ適用担当者は、カタログから「CRMパッチ検証環境」を選び、パラメータ（例: Test環境、リソースサイズ）を入力してワンクリックで展開することができます。
裏側では、VCF Automationにより、本番環境と同一のネットワークトポロジー（専用VPC・サブネット・ゲートウェイ・FWセキュリティまで）を持つ隔離環境が自動デプロイされます。
この隔離されたサンドボックス環境上で、担当者は脆弱性パッチを実際に適用し、動作やセキュリティに支障がないかをに検証していくことができます。以下のようにインフラを含めてキャプチャし、カタログからワンクリックデプロイできることから、従来のアプリケーションのデプロイと比べ、非常に多くの作業が削減されます。
STEP 6
検証完了後の「Blue/Greenデプロイメント」本番切り替え
パッチ検証が完了したら、パッチが正常適用された新規の本番環境（グリーン）として稼働させます。そして、上位のロードバランサでトラフィックをこれまでの本番環境（ブルー）から、パッチ適用済みの新環境（グリーン）へとシームレスにシフトさせます。こうした流れを通して、既存本番環境のサービス停止を最小限に抑えつつ、安全に（万一の場合はロールバック）、短時間かつ低リスクでのパッチ適用を完了させることができるようになります。
App Stack Formation を支えるバックエンド技術
稼働中インフラのキャプチャからカタログ公開までの流れは、これまでのブログシリーズ（第1部〜第5部）でご紹介してきた VCF の様々な機能が高度に連携することで成立しています。特に以下の機能が、このプロセスの基盤として支えています。
| VCF テクノロジー | キャプチャと再展開における技術的役割 |
|---|---|
| 専用 VPC と接続プロファイル | 名前空間（Namespace）のキャプチャを行う際、VM が「専用 VPC 」で構成されていることが前提となります。これにより、再デプロイした際もIPアドレスやMACアドレスの競合を防ぎ、VRF/L3 のネットワークレベルで隔離された検証環境として再現されます。 |
| vDefend セキュリティプロファイル | VPC と紐づいたファイアウォールは、キャプチャ時にセキュリティ規則（FWによるアクセス制御ルール）も丸ごと Blueprint に記録されます。パッチ適用の前後にファイアウォール設定を手動で再構築するリスクが排除されます。最小権限アクセスなどを含む標準構成をワンクリックで展開可能にすることを下支えする技術です。 |
※現行リリース（VCF 9.1）のApp Stack Formation は、検証スピードが求められる「VMベースのワークロード」に重点を置いて実装されています。VKS Kubernetes クラスタやコンテナなどのワークロードのキャプチャについては、今後のリリースにご期待ください。
開発者のスピードとITのガバナンス：ポリシーエンジンの役割
「本番同一の検証環境を開発者がワンクリックで作れるのは良いが、検証完了後に不要になったインフラが放置されたり、リソース制限を超えてデプロイされたりする心配はないだろうか？」そうした、セキュリティ管理者やインフラ管理者の懸念もあるかと思いす。この課題を解消するのが、VCF Automation の「ガバナンス＆ポリシーエンジン（Policy as Code）」です。キャプチャされ公開されたカタログ項目に対して、管理者は事前に以下のような強力なガードレールを強制適用することができるようになっています。詳細はこちらのブログをご参照ください。
🛡️ 統制自動化に有用な3つの自律型ポリシー
- ① 組織（Org）クォータ管理と利用上限
組織やプロジェクトが利用できる総リソース（CPU・メモリ・ストレージ）の上限をあらかじめ統制。検証環境が過剰に展開されて物理基盤のキャパシティを枯渇させることを未然に防ぐことに役立てることができます。
- ② 自動破棄を促すリースポリシー（利用期限管理）
「パッチ検証用の一時環境は、デプロイから最大14日間で自動回収する」といったリースポリシーをカタログ項目にバインドさせることができます。期限が来ると、システムがVM、永続ボリューム、アタッチされた専用VPCのサブネットまで一連のライフサイクルを自律的に一括削除させたり、リソースの解放を無人化させるような使い方もできます。
- ③ VM配置ポリシー（Infrastructure Placement Policy）
「データベースVM（db01）は性能要件が高いため、適合させるため特定のホストグループにしか配置しない」といった配置制限ルールを定義することができます。開発者が意識せずとも、再デプロイ時には必ず裏側のvSphereがコンプライアンスを満たす形で物理ホストへと自動的にマウント・制御させることができます。
さいごに
ここまで6回にわたる VCF Automation 詳細ブログシリーズ、いかがでしたでしょうか。
第1部でご紹介した仮想共通基盤の「スピード」と「セキュリティ」のジレンマ、数週間の手動プロセスといった「運用の行き詰まり」は、VMware Cloud Foundation® 9 の自動化コンソール、次世代テナント管理（VPC分離）、VM Service、そして 9.1 の App Stack Formation をはじめとするセルフサービス型テクノロジーによって解消されることを解説してきました。
モダンプライベートクラウドが実現する本質的な価値は、単なるサーバーの「仮想化」ではなく、「オンプレミス環境にパブリッククラウドと同等の、あるいはそれ以上のスピードと統制を実現すること」にあります。
開発者にはパッチを数クリックで検証できる「スピード」を得ることができます。一方で、管理者にとっては安全柵（ガードレール）によって「セキュリティ」を自動追従させることができます。プライベートクラウドだからこそ実現できるこうした技術を、ぜひ VMware Cloud Foundation® 9 を通して使い倒していただけたらと思います。
本ブログシリーズをご愛読いただき、誠にありがとうございました！今後の機能拡張や詳細な技術デモにつきましても、また随時お届けしてまいります。
VCF Automation 詳細ブログシリーズ（全6部完了）
- 第1部：仮想基盤/共通基盤のジレンマと「運用の行き詰まり」
- 第2部：VCF 9 が提示する解決策「プライベートクラウドポータル」
- 第3部：VCF 9 の「次世代テナント管理」徹底解説
- 第4部：プライベートクラウドへの「VPC」の必要性とネットワークアーキテクチャ
- 第5部：アプリ開発者向け「セルフサービス IaaS」体験と自動化の裏側
- 第6部：「App Stack Formation」が実現するガバナンスとスピードの両立（本記事）
