Azure VMSS 完全ガイド｜Uniform/Flexible・Auto Scale・Rolling Upgrade・Spot 混在

Virtual Machine Scale Sets (VMSS) は、同一構成の VM を 1-1000 台規模で自動スケール・自動デプロイ・自動修復する Azure サービス。Auto Scale (CPU 使用率・カスタムメトリクスベース) で需要に応じてインスタンス数を増減、デプロイは ARM/Bicep テンプレートまたは Custom Image で統一構成。Azure Load Balancer / Application Gateway と統合してトラフィック分散、AZ 冗長で SLA 99.99% 達成可能。代表的なユースケース: Web Tier の自動スケール・バッチ処理ワーカー・AKS Node Pool (内部実装)・SAP HANA Scale-out 等。VM 単体運用より遥かに大規模・耐障害的な運用が可能な、Azure コンピュートの主力サービスの 1 つです。

Uniform Orchestration mode (旧来): 全インスタンスが同一構成 (Image・Size・Network)、最大 1000 インスタンス、Auto Scale が高速。VMSS のオリジナル方式で、Web Tier やステートレスワークロード向け。Flexible Orchestration mode (2021 GA、現在の主流): 各インスタンスが独立した VM リソースとして扱われ、異なる VM サイズ・Image を混在可能、最大 1000 インスタンス、より柔軟。AZ 冗長や Fault Domain 制御が細かく可能、Spot VM と通常 VM の混在 Node Pool も実現可能。新規 VMSS は Flexible mode 推奨で、Microsoft も Uniform から Flexible への移行を推奨。AKS Node Pool は内部的に VMSS Flexible を使用しています。

Azure Monitor Auto Scale 経由で構成。ルール種別: 1) Metric-based (CPU 使用率・メモリ使用率・ネットワーク I/O 等、最も一般的)、2) Schedule-based (時間帯ベース、例: 平日 9-18 時のみインスタンス数増加)、3) Custom Metric (Application Insights カスタムメトリクス、例: キュー長・リクエスト/秒)。標準パターン: CPU 使用率 70% 超 5 分継続で +1 インスタンス Scale Out、CPU 30% 未満 10 分継続で -1 インスタンス Scale In。Cooldown Period (デフォルト 5 分) で連続スケール抑制、Min / Max Instances で安全範囲設定。本番環境では Min を 2 以上 (HA 保証) + Max を予算上限内に設定するのがベストプラクティスです。

Marketplace Image: Microsoft / OS ベンダ提供の標準イメージ (Ubuntu 22.04・Windows Server 2025 等)、毎月セキュリティパッチ更新、新規インスタンスは最新パッチ取得。Custom Image: 組織で構築した独自イメージ (アプリ・ミドルウェア・設定をプリインストール)、Azure Compute Gallery (旧 Shared Image Gallery) で集中管理・複数リージョン複製・バージョン管理可能。デプロイ高速化 (Marketplace + Custom Script Extension で構築するより数倍速い) と一貫性 (全インスタンス同一構成保証) がメリット。新規組織は Marketplace Image + Custom Script Extension で初期構築 → 安定後に Custom Image 化、Azure Image Builder で CI/CD パイプラインから自動 Image 構築するのが現代的な運用パターンです。

Manual: 管理者が手動で各インスタンスをアップグレード、最も慎重・運用負荷高。Automatic: 全インスタンスを一斉アップグレード、ダウンタイム発生・本番非推奨。Rolling: バッチ単位で順次アップグレード (例: 20% ずつ)、Application Health Probe で各バッチの正常性確認後に次へ進行、ダウンタイム最小化。本番運用は Rolling 一択で、Batch Size (20% 推奨)・Pause Time Between Batches (5-15 分)・Max Surge (Capacity を一時的に増やしてゼロダウンタイム実現) を構成。Application Health Extension をインスタンスにインストールしてヘルス情報を VMSS に通知することで、Rolling Upgrade 中の異常検知精度が向上します。

Flexible Orchestration mode の強力な機能の 1 つ。1 つの VMSS 内に Spot VM と通常 (Regular) VM を混在可能、Spot Priority Mix (例: 通常 30% + Spot 70%) で構成。Spot VM が Eviction された際に自動的に通常 VM で補充される動作。コスト最適化シナリオ: 1) ステートレス Web Tier で Spot 70% + Regular 30% (コスト 50% 削減・部分 Eviction でもサービス継続)、2) バッチ処理で全 Spot (停止時はジョブ再実行)、3) AKS Node Pool で Spot と Regular の組み合わせ。Spot VM の最大価格を Pay-as-you-go まで OK にすると Eviction 頻度が下がり、コスト削減効果と安定性のバランスが取れる構成が実現します。

代表的な落とし穴: 1) Custom Image の更新管理を忘れて古い OS / アプリで運用 (Image Builder + CI/CD で自動更新)、2) Auto Scale Min Instance を 1 にして HA 喪失 (最低 2 + AZ 冗長必須)、3) Stateful アプリ (DB) を VMSS で運用 (Stateless 専用、ステートは外部 Storage)、4) Rolling Upgrade で Health Probe 未構成、異常インスタンスが Healthy 判定でサービス停止、5) Spot VM を本番ステートフルで使用 (Eviction で停止)、6) Upgrade Policy が Automatic でサービス停止、7) ネットワーク Subnet の IP 不足 (1000 インスタンスで /24 では枯渇)、8) Custom Script Extension のスクリプト失敗を放置 (失敗時アラート設定)、9) Reserved Instance を購入せず Pay-as-you-go コストが膨張。これらを設計段階で意識することが運用負荷の大幅削減につながります。

AZ-104 (Administrator) のドメイン 3 (Compute 20-25%) で VMSS が深く問われる、本領域の本命認定。AZ-305 (Solutions Architect Expert) でアーキテクト視点での Auto Scale 設計、AZ-204 (Developer Associate、2026-07 リタイア注意) で開発者視点での VMSS デプロイ、AZ-400 (DevOps Engineer Expert) で CI/CD パイプラインからの VMSS Image 自動更新、AZ-140 (AVD Specialty) で AVD ホストプール (内部的に VMSS)、AKS Node Pool は内部 VMSS で構成。Azure コンピュートエンジニアにとって VMSS の理解は必須スキルです。