Azure Virtual Machine Scale Sets

解決する課題

需要が時間帯やイベントで変動するワークロードでは、ピークに合わせて常時 VM を立てておくと無駄が大きく、逆に台数を固定すると急増時に処理が溢れます。Virtual Machine Scale Sets（VMSS）は、同一構成の VM をひとつの論理単位として管理し、負荷に応じて台数を自動で増減させることで、この調達と廃棄の手作業をなくします。

• 負荷の増加に応じて 自動でスケールアウトし、収まれば スケールインしてコストを抑える
• 同一構成の多数の VM を 1 つのリソースとしてまとめて管理できる
• 複数の 可用性ゾーン / 障害ドメインへ分散して可用性を高める
• イメージ更新を ローリングで適用し、無停止に近い形で入れ替えられる
• AWS の EC2 Auto Scaling（起動テンプレート＋Auto Scaling グループ）に相当する役割を担う

主要概念と用語

• スケールセット: 同一構成の VM インスタンス群をまとめる論理リソース。台数（容量）を増減できる
• オーケストレーションモード: VM の管理方式。台数や更新を柔軟に扱う「柔軟（Flexible）」と、均一なインスタンスを高速に扱う「均一（Uniform）」がある。新規作成では柔軟が推奨される
• オートスケール: メトリクスやスケジュールを条件に台数を自動調整する仕組み。ルールベースのほか予測オートスケールもある
• インスタンスプロテクション: スケールイン時に特定インスタンスを削除対象から保護する設定
• アップグレードポリシー: モデル更新の適用方法。手動・自動・ローリングから選ぶ
• ヘルスプローブ / アプリケーションヘルス拡張: インスタンスの正常性を判定し、異常なものを自動修復（再作成）する
• 障害ドメインと可用性ゾーン: 物理ラック単位の分離と、データセンター単位で分離されたゾーン。両者にインスタンスを分散して耐障害性を高める

仕様・制限・クォータ

• スケールセットは リージョンに配置し、複数の 可用性ゾーンにまたがって展開できる
• インスタンス数の上限はオーケストレーションモードや構成（単一プレイスメントグループの利用など）に依存する。大規模化したい場合は構成上の制約を事前に確認する
• 増やせる VM 台数は、サブスクリプション/リージョンごとの vCPU クォータに制限される。引き上げは申請で可能
• スケールイン/アウトの反応速度は、メトリクス収集間隔やクールダウン設定の影響を受ける
• 利用できる VM サイズやアクセラレーテッドネットワーク等の可否は、選んだ VM シリーズに従う

内部の仕組み

スケールセットは、共有の構成情報である スケールセットモデル（VM サイズ、イメージ、ネットワーク設定、拡張機能など）を保持します。台数を増やす指示が出ると、Azure はこのモデルを基に新しい VM インスタンスを起動し、設定済みの ロードバランサや Application Gateway のバックエンドプールへ自動的に組み込みます。スケールインではインスタンスを切り離して削除します。

オートスケールエンジンは、CPU 使用率などの メトリクスやスケジュール、あるいは予測に基づいて目標台数を計算し、モデルに沿ってインスタンス数を調整します。アプリケーションヘルスを監視している場合、異常と判定されたインスタンスは自動的に置き換えられ、健全な台数が維持されます。モデルを更新したときは、アップグレードポリシーに従って ローリングで順次インスタンスを入れ替えるため、サービス全体を止めずに新イメージへ移行できます。

• 永続化が必要なデータは個々のインスタンス内に置かず、外部ストレージ（Blob、Files、データベース、Cache など）へ逃がすのが前提
• インスタンスはいつでも追加・削除され得るため、各 VM は **使い捨て（イミュータブル）**として扱う

設計パターン / ベストプラクティス

• ステートレス設計: セッションや状態を外部（Cache for Redis、Cosmos DB、Blob など）へ退避し、どのインスタンスが消えても問題ない構成にする
• ロードバランサ / Application Gateway との組み合わせ: スケールセットをバックエンドに置き、増減するインスタンスへ自動で振り分ける
• 複数ゾーンへの分散: ゾーン障害でも稼働を維持できるよう、インスタンスを複数の可用性ゾーンに配置する
• イメージのカスタム化: 起動時のセットアップを減らすため、Azure Compute Gallery のカスタムイメージや事前構成済みイメージを使い、スケールアウトを高速化する
• スケールインポリシーの調整: どのインスタンスから減らすかを制御し、必要なインスタンスを保護する
• 適切なメトリクスとクールダウン: 振動（短時間での増減の繰り返し）を避けるため、しきい値とクールダウンを保守的に設定する

運用・監視

• Azure Monitor でインスタンス数、CPU、ネットワークなどのメトリクスを監視し、オートスケールルールの妥当性を継続的に見直す
• アプリケーションヘルス拡張 / ヘルスプローブで正常性を判定し、自動修復を有効化する
• モデル更新は ローリングアップグレードで段階適用し、失敗時に被害を局所化する
• スケールイベント（増減のタイミングと理由）をログで追跡し、想定外のスケールが起きていないか確認する

コスト

VMSS 自体に追加料金はかからず、課金されるのは起動している VM インスタンスとそのディスク、ネットワークなどの基盤リソースです。したがってコスト最適化は、需要に追従して不要なインスタンスを確実に減らすことと、各インスタンスの購入オプションを使い分けることが軸になります。

• スケールインを適切に効かせ、アイドル時の台数を最小化する
• 定常的に必要な基盤台数には リザーブドインスタンスや Savings Plan を、変動分は従量課金で賄う考え方が有効
• 中断を許容できるステートレスなワークロードでは スポットインスタンスでスケールアウト分を安く確保できる場合がある
• ディスクや固定の付帯リソースは、インスタンスを止めても残るものがある点に注意する

セキュリティ

• 各インスタンスに マネージド ID を付与し、資格情報のハードコードを避ける（AWS の IAM ロール相当）
• **ネットワークセキュリティグループ（NSG）**で通信を最小化し、直接の受信は基本的にロードバランサや Application Gateway 経由に限定する
• 操作権限は Microsoft Entra ID と RBAC で制御し、スケール操作やモデル変更を担当者に限定する
• イメージや拡張機能を最新の修正済みに保ち、ローリングで安全に展開する
• 保存データはディスク暗号化で保護し、鍵は Key Vault で管理する

Well-Architected の観点

• 信頼性: 複数ゾーンへの分散と自動修復により、インスタンスやゾーンの障害があっても健全な台数を維持できる
• コスト最適化: 需要追従の自動増減でアイドルコストを削り、購入オプションの組み合わせでさらに圧縮できる
• パフォーマンス効率: 負荷の急増に対してスケールアウトで応答性を保ち、収束時はスケールインで効率を取り戻す
• 一方で、オートスケールのしきい値やクールダウンが不適切だと振動や応答遅延を招くため、運用での継続的な調整が前提になる

試験で問われるポイント

関連サービス・比較

VMSS は Azure VM を自動スケールさせる仕組みで、AWS では EC2 Auto Scaling が同じ役割を担います。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# スケールセットを作成（2台で開始、複数ゾーンへ分散）
az vmss create \
  --resource-group demo-rg \
  --name demo-vmss \
  --orchestration-mode Flexible \
  --image Ubuntu2204 \
  --instance-count 2 \
  --zones 1 2 3 \
  --admin-username azureuser \
  --generate-ssh-keys

# CPU 使用率に基づくオートスケールを設定（最小2、最大10、既定2）
az monitor autoscale create \
  --resource-group demo-rg \
  --resource demo-vmss \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name demo-autoscale \
  --min-count 2 --max-count 10 --count 2

# CPU が高いときにスケールアウトするルール
az monitor autoscale rule create \
  --resource-group demo-rg \
  --autoscale-name demo-autoscale \
  --condition "Percentage CPU > 70 avg 5m" \
  --scale out 2

# CPU が下がったらスケールインするルール
az monitor autoscale rule create \
  --resource-group demo-rg \
  --autoscale-name demo-autoscale \
  --condition "Percentage CPU < 30 avg 5m" \
  --scale in 1