クラウドコンピューティングの普及に伴い、アプリケーションの負荷に応じて柔軟にリソースを調整できるスケーラビリティが不可欠となっています。Azure仮想マシンスケールセット（Virtual Machine Scale Sets, VMSS）は、まさにこの要求に応えるための強力なサービスです。
本記事では、Azure VMSSの概要から、そのメリット、そしてInfrastructure as Code (IaC) ツールであるTerraform を用いた具体的なデプロイ方法までを詳しく解説します。
特に、オートスケールの設定やTerraformコードの各パラメータに焦点を当て、実践的な知識を提供します。
Azure仮想マシンスケールセットとは？
Azure仮想マシンスケールセットとは、多数の同一構成を持つ仮想マシン（VM）を簡単にデプロイし、一元的に管理するためのAzureのコンピューティングサービスです。最大の特長は、アプリケーションの需要変動に応じてVMのインスタンス数を自動的に増減させる（オートスケール）機能にあります。
例えば、オンラインショッピングサイトで大規模なセールが開催される際、アクセス数が急増することが予想されます。このような場合、VMSSは自動的にVMインスタンスを増やして増加したトラフィックを処理し、セール終了後にアクセス数が落ち着けばインスタンス数を減らしてコストを最適化します。
Azure仮想マシンスケールセットの特徴
集中管理
複数のVMを単一のリソースとして管理できます。OSイメージの更新、ネットワーク設定の変更、拡張機能の追加などを、スケールセット内の全インスタンスに容易に適用できます。
自動スケーリング
CPU使用率、メモリ使用量、ネットワークトラフィック、キューの長さといった様々なメトリックに基づいて、VMインスタンス数を自動的に調整します。また、特定のスケジュールに基づいてインスタンス数を変更することも可能です。
高可用性と回復性
インスタンスは障害ドメインおよび更新ドメインに分散されるため、ハードウェア障害や計画メンテナンス時にもアプリケーションの継続的な稼働を支援します。障害が発生したインスタンスは自動的に修復または置き換えられます。
大規模ワークロードへの対応
数千台規模のVMを必要とする大規模なコンピューティング処理、ビッグデータ分析、コンテナ化されたワークロードなどに適しています。
多様なOSとイメージのサポート
Windows Serverや各種Linuxディストリビューションに対応しており、Azure Marketplaceで提供される標準イメージのほか、独自のカスタムイメージも利用できます。
VMSSを利用することで、インフラストラクチャの運用負荷を軽減し、アプリケーションのパフォーマンスと可用性を高めながら、コスト効率の良いシステム運用を実現できます。
Azure仮想マシンスケールセットを使用するメリット
Azure仮想マシンスケールセットを利用することには、多くのメリットがあります。これらを理解することで、どのようなシナリオでVMSSが有効であるかを判断する助けとなります。
スケーラビリティ
VMSSの最も大きなメリットは、そのスケーラビリティです。アプリケーションへの負荷の増減に応じて、VMインスタンス数を自動的に調整できます。これにより、ピーク時には十分なリソースを確保してユーザーエクスペリエンスを維持し、オフピーク時には余分なリソースを削減してコストを最適化します。手動での介入が不要なため、運用効率も向上します。
高可用性
VMSSは、複数のVMインスタンスにワークロードを分散させることで、単一障害点を排除し、アプリケーションの可用性を高めます。Azureのインフラ内で、インスタンスは障害ドメイン（ハードウェア障害の影響範囲を限定する単位）と更新ドメイン（計画メンテナンス時の影響範囲を限定する単位）に自動的に分散配置されます。万が一、いずれかのインスタンスに障害が発生しても、他の正常なインスタンスが処理を引き継ぎ、サービスの中断を最小限に抑えます。
管理の簡素化
多数のVMを個別に管理するのは非常に手間がかかりますが、VMSSではすべてのインスタンスで同一の構成を維持できます。OSのパッチ適用、セキュリティ更新、アプリケーションのデプロイやアップデートといった作業を、スケールセット全体に対して一元的に実行できます。これにより、管理作業の時間が大幅に削減され、ヒューマンエラーのリスクも低減します。
コスト効率
「必要なときに、必要なだけ」リソースを使用するという原則に基づいているため、コスト効率に優れています。トラフィックが少ない時間帯や、処理負荷が低い期間には自動的にインスタンス数が減少（スケールイン）するため、アイドル状態のVMに対する無駄な課金を避けることができます。さらに、Azure Spot Virtual Machinesと組み合わせることで、大幅なコスト削減を実現することも可能です（ただし、Spot VMは中断の可能性があるため、耐障害性のあるワークロードに適しています）。
迅速なデプロイ
事前定義されたVM構成（OSイメージ、サイズ、拡張機能など）に基づいて、多数のVMインスタンスを迅速かつ一貫性を持ってプロビジョニングできます。新しいバージョンのアプリケーションをデプロイする際や、開発・テスト環境を迅速にセットアップする際などに非常に有効です。
これらのメリットにより、Azure VMSSは、Webサーバー、アプリケーションサーバー、バッチ処理システム、コンテナオーケストレーションのワーカーノードなど、さまざまなワークロードで活用されています。
Azure仮想マシンスケールセットをterraformで作成する際に決定すること
Azure仮想マシンスケールセット（VMSS）をTerraformで構築する際は、いくつかの主要な項目を事前に決定しておく必要があります。これらはスケーラブルで安定した構成を作るための基本要素であり、実際の運用要件に即した設計が求められます。
インスタンスタイプとサイズ
VMSSで使用するインスタンスのタイプ（Windows/Linux）とサイズ（例：Standard_DS1_v2など）は、アプリケーションの処理能力やコストに直結します。用途に応じて適切なSKUを選ぶ必要があります。
※詳しくは別記事「【基礎編】Azure仮想マシンをTerraformでデプロイする手順を解説」をご参照ください。
オートスケールの設定
VMSSでは、CPUやメモリの使用率などのメトリクスに基づき、インスタンス数を自動的に増減させる「オートスケーリング」の構成が可能です。Terraformでは azurerm_monitor_autoscale_setting リソースを使って、柔軟なスケーリングルールを定義できます。
インスタンス数の範囲と初期値
オートスケーリングを設定する際は、スケールセットにおける最小インスタンス数、最大インスタンス数、初期インスタンス数を明示的に決める必要があります。たとえば「最小1、最大5、初期2」のように、需要に応じた余裕を持たせて設計するとよいでしょう。
スケールアウト、スケールインの条件
スケールアウト（増加）やスケールイン（削減）を行うトリガー条件を定義します。一般的には「CPU使用率が75%を超えたら1台追加」「25%を下回ったら1台削除」など、シンプルかつ分かりやすい閾値を設定します。条件設定によってスケーリングの効率や反応速度が変わるため、慎重な調整が必要です。
任意：スケーリング時の通知
必要に応じて、スケーリングイベントが発生した際にメール通知を受け取る設定も可能です。Terraformでは notification ブロックで特定のメールアドレスを指定できます。監視体制の一環として有用です。
Terraformを使えば、これらの設定をコードで一貫して管理・再現できるため、インフラの自動化と可搬性が飛躍的に向上します。実装前に上記の項目をしっかり検討し、構成ファイルに反映することが成功の鍵です。
Azure仮想マシンスケールセットのデプロイ方法
ここでは、事前にリソースグループ、仮想ネットワーク（VNet）、サブネットが作成されている前提で、Terraformを使用してWindows仮想マシンスケールセットをデプロイし、オートスケール設定を構成する具体的な方法を解説します。提示されたTerraformコードを基に、各リソースとパラメータの意味を詳しく見ていきましょう。
前提条件:
- Terraform CLIがインストールされていること。
- Azure CLIがインストールされ、
az loginコマンドでAzureにログイン済みであること。 - デプロイ先となるAzureサブスクリプションが選択されていること。
- 既存のリソースグループ、VNet、サブネットの名前やIDを把握していること。これらはTerraformコード内で参照されます。
Terraformコードの構成:
提示されたコードは、主に2つのAzureリソースを定義しています。
azurerm_windows_virtual_machine_scale_set: Windows VMで構成されるスケールセット本体。azurerm_monitor_autoscale_setting: 上記スケールセットに対するオートスケールルール。
以下、それぞれのコードブロックを詳細に解説します。
# Windows仮想マシンスケールセット
resource "azurerm_windows_virtual_machine_scale_set" "vmss01" {
name = "aitvmss01"
location = azurerm_resource_group.rg01.location
resource_group_name = azurerm_resource_group.rg01.name
sku = "Standard_DS1_v2" # VMサイズ
instances = 2 # 初期インスタンス数
admin_username = "azureuser"
admin_password = "P@ssw0rd1234!" # 本番ではより強固なパスワードを使用
# Windows Server イメージを指定
source_image_reference {
publisher = "MicrosoftWindowsServer"
offer = "WindowsServer"
sku = "2016-Datacenter"
version = "latest"
}
# OSディスクの設定
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
# ネットワーク設定（NICとIP構成）
network_interface {
name = "vmss-nic01"
primary = true
ip_configuration {
name = "vmss-ipconfig01"
subnet_id = azurerm_subnet.snet01.id
primary = true
}
}
upgrade_mode = "Manual" # 手動アップグレード
overprovision = true # 高速デプロイのための予備インスタンス
}
# VMSSのオートスケール設定
resource "azurerm_monitor_autoscale_setting" "vmss_autoscale" {
name = "vmss-autoscale"
location = azurerm_resource_group.rg01.location
resource_group_name = azurerm_resource_group.rg01.name
target_resource_id = azurerm_windows_virtual_machine_scale_set.vmss01.id
enabled = true
# スケーリングプロファイル
profile {
name = "autoscale-profile"
# インスタンス数の範囲と初期値
capacity {
minimum = "1"
maximum = "5"
default = "2"
}
# CPUが75%以上でスケールアウト
rule {
metric_trigger {
metric_name = "Percentage CPU"
metric_namespace = "Microsoft.Compute/virtualMachineScaleSets"
metric_resource_id = azurerm_windows_virtual_machine_scale_set.vmss01.id
time_grain = "PT1M"
statistic = "Average"
time_window = "PT5M"
time_aggregation = "Average"
operator = "GreaterThan"
threshold = 75
}
scale_action {
direction = "Increase"
type = "ChangeCount"
value = "1"
cooldown = "PT5M"
}
}
# CPUが25%未満でスケールイン
rule {
metric_trigger {
metric_name = "Percentage CPU"
metric_namespace = "Microsoft.Compute/virtualMachineScaleSets"
metric_resource_id = azurerm_windows_virtual_machine_scale_set.vmss01.id
time_grain = "PT1M"
statistic = "Average"
time_window = "PT5M"
time_aggregation = "Average"
operator = "LessThan"
threshold = 25
}
scale_action {
direction = "Decrease"
type = "ChangeCount"
value = "1"
cooldown = "PT5M"
}
}
}
# スケーリング通知（任意）
notification {
email {
send_to_subscription_administrator = false
send_to_subscription_co_administrator = false
custom_emails = ["your-email@example.com"]
}
}
}Terraformコマンドによるデプロイ手順
VMSS構成のTerraformコードを .tf ファイル（例：main.tf、vmss.tf、lb.tf など）として保存したら、次はいよいよAzure上へのデプロイ作業に移ります。Terraformでは、以下の3つの基本コマンドを順に実行することで、構成されたインフラを自動的に展開できます。
1. terraform init：プロジェクトの初期化
まず最初に実行するのが terraform init コマンドです。
このコマンドは、Terraformプロジェクトの作業ディレクトリを初期化し、必要なプロバイダ（今回は azurerm）をダウンロードします。新しい環境を構築する際や、別の開発者の作成したコードをクローンして利用する場合には、必ずこのステップから始めましょう。
terraform init成功すると、「Terraform has been successfully initialized.」というメッセージが表示され、準備が整います。
2. terraform plan：変更内容の確認
次に実行するのは terraform plan です。
このコマンドは、現在のAzure環境とTerraformコードとの差分を分析し、「これからどのようなリソースが作成・変更・削除されるか」という実行計画を表示します。
terraform planこのステップでは、実際のクラウドリソースにはまだ変更は加えられません。出力結果を確認して、意図した構成になっているか、誤って削除されるリソースがないかを慎重にチェックします。
3. terraform apply：インフラの構築
実行計画に問題がなければ、いよいよ terraform apply を実行します。
このコマンドは、plan で表示された内容をもとにAzure上で実際にインフラリソースを作成・更新・削除します。
terraform apply実行時には、確認のために「本当に適用してよいか？」というプロンプトが表示されます。yes と入力することで、構成が適用され、VMSSやロードバランサー、オートスケール設定などが自動でデプロイされます。
デプロイ後の確認
デプロイが完了したら、Azure Portalにアクセスし、以下の点を確認します。
- 指定したリソースグループ内に、
aitvmss01という名前の仮想マシンスケールセットが作成されていること。 - スケールセットのインスタンスが、初期値またはオートスケール設定のデフォルト値（この例では2台）で起動していること。
- スケールセットの「スケーリング」設定で、
vmss-autoscaleという名前のオートスケール設定が構成され、CPU使用率に基づくスケールアウトルールとスケールインルールが正しく設定されていること。 - 通知設定で指定したメールアドレスに、テスト通知が送信されるか（設定によっては初期デプロイ時には通知されない場合もあります）。
可能であれば、VMインスタンスに負荷をかけるツール（例: CPUストレステストツール）などを使用して、CPU使用率を変動させ、実際にスケールアウトおよびスケールインがトリガーされるかを確認してみるとよいでしょう。その際、Azure Monitorでメトリックのグラフやオートスケールイベントのログを確認することで、動作を詳細に追跡できます。
まとめ
本記事では、Azure仮想マシンスケールセットの基本的な概念、そのメリット、そしてTerraformを用いた具体的な作成方法について解説しました。特に、オートスケールの設定はVMSSの能力を最大限に引き出すための鍵であり、インスタンス数の範囲、スケール条件、通知設定などを適切に行うことが重要です。
Terraformを利用することで、このような複雑なインフラ構成もコードとして管理でき、再現性のあるデプロイ、バージョン管理、チームでの協調作業が容易になります。提示したコードはWindows VMSSの例でしたが、Linux VMSS (azurerm_linux_virtual_machine_scale_set) も同様の考え方で構築可能です。
Azure VMSSとTerraformを組み合わせることで、スケーラブルで可用性が高く、コスト効率の良いアプリケーション基盤を効率的に構築・運用できます。今後のAzureインフラ構築において、本記事がその一助となれば幸いです。さらに理解を深めるためには、カスタムイメージの利用、ロードバランサーやアプリケーションゲートウェイとの連携、より高度なオートスケール戦略（カスタムメトリックやスケジュールベースのスケーリング）などについても学習を進めていくとよいでしょう。
コメント