Azure Virtual Machine Scale Sets（VMSS）入門｜オートスケーリングとロードバランサー連携でクラウドインフラを自動拡張する実践ガイド

「トラフィックが急増したとき、手動でVMを追加していたら間に合わない」——オンプレのインフラ担当なら、こんな経験が一度はあるはずです。深夜の緊急スケールアップ、翌朝の縮小対応、その繰り返しに疲れてクラウド移行を検討している方も多いでしょう。

Azure Virtual Machine Scale Sets（VMSS）は、その悩みをほぼ自動で解決してくれるサービスです。負荷に応じてVMインスタンスを自動で増やし、需要が落ち着けば自動で減らす。しかもロードバランサーとの統合が標準装備されているため、複雑な設定なしに本番環境に組み込めます。

この記事では、Azure VMSSの基本概念からAzure Portalでの作成手順・Azure CLIでの操作・料金設計・実務Tipsまで、オンプレ経験者にもわかりやすく体系的に解説します。

なぜVMSSなのか？オンプレとの決定的な違い

オンプレ環境でのスケーリングには、大きく分けて2つの限界がありました。

1つ目は「時間的なコスト」です。新しいサーバーを調達してラックに搭載し、OSとミドルウェアを設定して本番に投入するまで、早くても数日かかります。キャパシティ計画を見誤ると、その間ずっと性能不足か過剰投資のどちらかを強いられます。

2つ目は「手動運用の限界」です。監視担当が閾値アラートを受け取り、手順書に従ってVM追加作業を実施する——このプロセスは人間の判断と手が介在するため、深夜や休日には対応が遅れがちです。

Azure VMSSは、これらの課題を根本から解決します。

VMSSが特に効果を発揮するのは、「日中と深夜でアクセス量が数倍違う」「キャンペーン時だけ負荷が爆発する」といった可変負荷のシステムです。ECサイト、APIサーバー、バッチ処理基盤など、クラウド移行を検討する多くの現場がこのユースケースに当てはまります。

VMSSの基本的な仕組みを理解する

1. スケールセットとインスタンスプール

VMSSの基本単位は「スケールセット」です。1つのスケールセットは、同一の構成（VMサイズ、OS、データディスク）を持つ複数のVMインスタンスを束ねた「プール」として機能します。

オンプレの感覚で言えば、「同じハードウェア仕様・同じOSイメージで作った予備サーバー群」に近いイメージです。ただし、オンプレと違う点が3つあります。

・インスタンス数の上限: デフォルトで最大1,000台（カスタムイメージ使用時は600台）まで拡張可能
・ゾーン分散: アベイラビリティゾーン（AZ）にまたがって配置でき、ゾーン障害にも対応できる
・起動プロフィール: 全台の構成を統一管理するテンプレートがあり、設定の差異が生まれない

VMSSには「Uniform（均一）」と「Flexible（柔軟）」の2つのオーケストレーションモードがあります。Uniformは旧来の標準モードで、Flexibleは2022年以降に推奨されているモードです。Flexibleはアベイラビリティゾーン分散や、VMSSと単体VMの混在管理に対応しており、新規構築では基本的にFlexibleを選択してください。

2. スケーリングポリシーの3つの方式

VMSSのスケーリングには3種類の方式があり、用途によって使い分けます。

・手動スケーリング: インスタンス数を直接指定。テスト環境やメンテナンス時に使用
・カスタム自動スケーリング: CPUやメモリなどのメトリクスに基づいてルールを設定。最も柔軟で本番環境の主流
・スケジュールベース: 曜日や時刻に合わせて事前にスケールアウト。アクセスパターンが予測可能な場合に最適

実務では「スケジュール＋カスタム自動」を組み合わせるのがベストプラクティスです。例えば「月～金の9時に最低台数を増やし、21時に戻す。その上で急なスパイクにはCPUベースで対応する」という設計がよく使われます。

3. Azure Load Balancerとの統合

VMSSはAzure Load Balancer（L4）またはAzure Application Gateway（L7）と統合できます。インスタンスが追加されると自動的にロードバランサーのバックエンドプールに登録され、削除時は自動的に解除されます。

オンプレでHA ProxyやNginxのバックエンドサーバーを手動で追加・削除していた経験があれば、この自動化の価値がよくわかると思います。

Azure PortalでVMSSを作成する手順

1. 基本設定とイメージ選択

Azure Portal（portal.azure.com）にログインし、「仮想マシン スケール セット」を検索して「作成」をクリックします。

基本設定タブでは以下を設定します。

・サブスクリプション・リソースグループ: 既存のものを選択、または新規作成
・スケール セット名: リソースを識別する名前（例：webapp-vmss-prod）
・リージョン: 東日本（Japan East）または西日本（Japan West）を選択
・アベイラビリティゾーン: 高可用性が必要な場合はゾーン1・2・3すべてにチェック
・オーケストレーション モード: 「Flexible」を選択（新規構築では推奨）
・イメージ: Azureマーケットプレイスイメージ（Ubuntu Server 24.04 LTSなど）か、作成済みのカスタムイメージを選択
・VMサイズ: 用途に合わせて選択（Webサーバー程度なら Standard_B2sが費用対効果◎）

2. スケーリングポリシーの設定

「スケーリング」タブでスケーリング方式を選択します。「カスタム自動スケーリング」を選ぶと、スケールアウトとスケールインのルールをそれぞれ設定できます。典型的な設定例は次の通りです。

・スケールアウト条件: 過去5分間のCPU平均が70%以上を5分間継続したら、インスタンスを2台追加
・スケールイン条件: 過去5分間のCPU平均が30%以下を10分間継続したら、インスタンスを1台削除
・インスタンス数の上限・下限: 最小2台・最大10台といった範囲を設定

スケールアウト条件は「ちょっとした一時スパイクで無駄に起動しない」よう、複数分間の平均を見るのが現場での定石です。逆にスケールインは「慌てて削除して再スパイク時に追いつかない」を避けるため、スケールアウトより長い時間ウィンドウを設定します。

3. ロードバランサーの接続設定

「ネットワーク」タブでロードバランサーを設定します。WebアプリにはAzure Application Gatewayの選択を強く推奨します。Azure Load Balancerよりコストは上がりますが、SSL終端・パスルーティング・WAF機能が利用でき、本番Webサービスの要件を満たしやすくなります。

・Azure Load Balancer: L4ロードバランシング（TCPゲームサーバー、DBプロキシなど非HTTPのケースに適する）
・Application Gateway: HTTPSのWebアプリに最適。パスベースルーティング・WAF機能も利用可能

Azure CLIでVMSSを操作する

運用自動化やCI/CDパイプラインへの組み込みには、Azure CLIが欠かせません。主要な操作を確認しましょう。

VMSSの一覧確認：

# リソースグループ内のVMSSを表示
az vmss list --resource-group myResourceGroup --output table

VMSSの手動スケール：

# インスタンス数を5台に変更
az vmss scale   --resource-group myResourceGroup   --name webapp-vmss-prod   --new-capacity 5

インスタンスの一覧確認：

# VMSS内の各インスタンスの状態を確認
az vmss list-instances   --resource-group myResourceGroup   --name webapp-vmss-prod   --output table

VMSSのイメージ更新（ローリングアップデート）：

# 起動プロフィールのイメージを最新バージョンに更新
az vmss update   --resource-group myResourceGroup   --name webapp-vmss-prod   --set virtualMachineProfile.storageProfile.imageReference.version="latest"

# ローリング更新を開始（稼働中インスタンスを順次更新）
az vmss rolling-upgrade start   --resource-group myResourceGroup   --name webapp-vmss-prod

ローリングアップデートは「一度にアップデートするインスタンスの割合」を設定でき、無停止でOSやアプリのバージョンを更新できます。オンプレで「1台ずつ手動でパッチ当て」をしていた作業が、コマンド1つで自動化される感覚です。

Linuxサーバーの基礎操作については、姉妹サイトLinuxMaster.JPで詳しく解説しています。Azure VMのLinuxインスタンスに慣れておくと、VMSSの運用もスムーズです。

料金の仕組みとコスト試算

VMSSの料金は、基本的に「起動しているVMインスタンスの料金の合計」です。VMSS機能自体には追加料金はかかりません。ただし、関連サービスの料金に注意が必要です。

コスト最適化の最大の武器は「Spot VM（スポット仮想マシン）」です。Azureの余剰コンピューティングを安価に利用できるモデルで、中断（エビクション）リスクがある代わりに最大85%のコスト削減が可能です。バッチ処理・動画エンコード・CI/CDランナーなど、中断しても再実行可能なワークロードに最適です。

【コスト注意点】Auto Scalingでスケールインが過剰に発生すると、「インスタンス削除→再追加」のサイクルでOSディスクの削除・再作成コストが積み重なる場合があります。スケールインの閾値を慎重に設定し、不必要なインスタンスの増減を抑えることがコスト管理の基本です。

応用・実務Tips

【Tips 1】カスタムスクリプト拡張でプロビジョニングを自動化

VMSSはインスタンス起動時にカスタムスクリプトを自動実行できます。「インスタンスが起動したら自動でNginxをインストールしてアプリを配置する」という処理をbashスクリプトやcloud-initで実装することが現場では一般的です。

より本格的な構成管理が必要なら、VMSSとAzure DevOps Pipelinesを組み合わせて、CI/CDパイプライン内でイメージのビルド→スケールセットへのデプロイを自動化するパターンが主流です。

【Tips 2】ヘルスプローブとグレースフルシャットダウンの設定

スケールイン時に「まだリクエストを処理中のインスタンスが突然削除される」問題は、VMSSを初めて使うエンジニアが最初にハマるポイントです。対策として2つの設定を必ず入れておきましょう。

・Terminate通知: インスタンス削除前に最大15分の猶予を与え、処理中のリクエストを完了させる
・ヘルスプローブ: ロードバランサーのヘルスチェックと連動し、ヘルスチェックが通らないインスタンスをプールから外してから削除する

これらを設定することで、無停止スケールインを実現できます。オンプレで「Webサーバーの切り離し→ドレイン確認→シャットダウン」を手動でやっていた手順が、自動化されるイメージです。

【Tips 3】マルチリージョンVMSSとAzure Front Doorの組み合わせ

グローバルサービスやDR（障害復旧）対応が必要な場合、東日本と西日本リージョンにそれぞれVMSSを配置し、Azure Front Door（グローバルロードバランサー）でリージョン間のトラフィック分散を行う構成が有効です。これはオンプレで言えば「東京DC＋大阪DC＋GSSLBでのアクティブ・アクティブ構成」に相当します。

よくあるトラブルと対処法

【トラブル1】インスタンスが起動しても「不健全」のままロードバランサーに登録されない

原因: ヘルスプローブが失敗している（アプリが起動完了前にチェックが走るケースが多い）

対処: ヘルスプローブの「unhealthyThreshold（不健全判定までの試行回数）」と「intervalInSeconds（試行間隔）」を調整する。起動に時間がかかるアプリなら、プローブの初回実行までの遅延時間を設定する。

【トラブル2】スケールアウトが繰り返し発生してコストが膨れる

原因: スケールアウト後もCPU閾値を超え続けて追加→追加のサイクルに入っている（クールダウン時間が短すぎる）

対処: クールダウン時間を300秒以上に設定する。またスケールアウト条件の「増加台数」を控えめにし、一度に大量追加しない設計にすることで安定する。

【トラブル3】ローリングアップデート後に古いインスタンスが混在する

原因: 「アップグレードポリシー」が「手動」になっているため、既存インスタンスに自動適用されない

対処: アップグレードポリシーを「ローリング」に変更する。または以下のコマンドで手動適用する。

# 全インスタンスを最新モデルに手動アップデート
az vmss update-instances   --resource-group myResourceGroup   --name webapp-vmss-prod   --instance-ids "*"

本記事のまとめ

Azure Virtual Machine Scale Setsは、オンプレのインフラエンジニアが「これがクラウドの本領だ」と感じるサービスの一つです。手動スケールアップの夜更かしから解放され、トラフィックの波に対してシステムが自律的に応答する状態を実現できます。

次のステップとして、Azure Monitorと組み合わせて「VMSS＋Application Gateway＋Monitor」の三位一体構成を構築することをお勧めします。これがAzureでWebシステムを安定稼働させるための基本パターンです。