Contents
スポンサードリンク
1️⃣ VMSS の従量課金構造と最新価格の留意点
| 項目 | 課金単位 | 主な計算式 | 参考価格*（東京リージョン） |
|---|---|---|---|
| CPU・メモリ | インスタンス時間 (1 h) | vCPU数 × vCPU単価 + メモリGB × メモリ単価 |
Standard_D4s_v3 ≈ ¥0.112/時 |
| OS ディスク | GB/月 | ディスクサイズ(GB) × ストレージ単価 |
Premium SSD 128 GB → ¥3.6/GB/月 |
| データディスク | GB/月 | ディスクサイズ(GB) × ストレージ単価 |
Standard HDD 500 GB → ¥1.2/GB/月 |
| ネットワーク送信 | GB | 転送量(GB) × 転送料金 |
100 GB → ¥0.09/GB |
*価格は2024‑10‑01 時点の Azure Pricing Calculator（公式ページ）を基にしています。リージョンや為替レート、割引（Reserved Instances・Savings Plans 等）によって変動しますので、実装前に必ず Azure Pricing Calculator で最新価格をご確認ください。
ポイント
- 「CPU・メモリ」の単価は VM のサイズごとに固定ですが、リージョン別に数円〜十数円の差があります。
- ディスク費用はインスタンス数に関係なく 永続化 されるため、スケールアウト時の変動要因にはなりません。
- ネットワークは送信のみ課金対象です（受信は無料）。
2️⃣ スケーリング構成の評価フロー（Microsoft Learn ガイド）
公式ガイド 「スケーリング コストを最適化するためのアーキテクチャ戦略」（2024‑10‑14 更新）では、以下の 4 パターンが提示されています。
| パターン | 特徴 | 適用シナリオ例 |
|---|---|---|
| Fixed Count | 常時一定数 | バッチ処理やバックエンド API のベースライン確保 |
| Auto‑scale (CPU トリガー) | CPU 使用率で増減 | 突発的トラフィックが予測できない Web フロントエンド |
| Predictive Scale | Azure Monitor 予測モデル使用 | 定期的なピーク（例：営業開始前のアクセス集中） |
| Schedule‑based Scale | 時間帯で固定数 | 夜間は低負荷、昼間は高負荷が決まっている業務系アプリ |
評価手順（実践編）
- 現行構成の把握
-
VMSS 名・インスタンス数・使用している SKU を Azure Portal または
az vmss listで取得。 -
代替シナリオ作成
-
上表のパターンから 2〜3 パターンを選定し、想定スケール範囲（最小/最大）とトリガー条件を決める。
-
コストシミュレーション
- Azure Pricing Calculator に Standard_D4s_v3 と各ディスク構成を入力し、平均インスタンス数 をシナリオ別に設定する（例：Auto‑scale 平均 13 台）。
| シナリオ | 平均インスタンス数 | 月額概算（東京） |
|---|---|---|
| Fixed Count (20 台) | 20 | ¥210,000 |
| Auto‑scale (8〜18 台) | 13 | ¥136,500 |
| Predictive Scale (6〜12 台) | 11 | ¥115,500 |
| Schedule‑based (4/15 台) | 9 | ¥94,500 |
※シミュレーションは2024‑10‑01 の価格を使用。実際の請求額はディスク・ネットワーク利用量、割引適用状況により変動します。
- 意思決定基準
- コスト削減率 ≥ 30 %かつSLA（99.9 %）を満たす構成が採用対象。上記例では Schedule‑based が最も効果的です。
3️⃣ Spot 優先度ミックスの実装ガイド
3‑1. 正しいリファレンス日付
公式ドキュメントは 2024‑10‑07 に更新されています（priorityMix プロパティが正式にサポート開始）。過去の「2025/10/07」表記は誤りですので、以降は 2024‑10‑07 を参照してください。
3‑2. Spot ミックスの概念とリスク
| 項目 | 内容 |
|---|---|
| Spot VM | 余剰キャパシティを割安価格で提供。中断（Eviction）リスクあり。 |
| Regular VM (Priority = Regular) | 中断不可。ベースライン可用性として確保。 |
| 優先度ミックス | Spot と Regular を比率で混在させ、コスト削減と可用性を同時に実現。 |
設計上の前提条件
1. Spot の最大価格は「現在価格 × 0.7」程度に設定（過度に低いと即中断）。
2. Regular インスタンスは最低 2 台 を常時確保し、Spot が Eviction した際のフェイルオーバー先とする。
3‑3. Bicep コード例（API バージョン 2024‑07‑01）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
resource vmss 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = { name: 'myVmss' location: resourceGroup().location sku: { tier: 'Standard' capacity: 10 // 初期総数（Spot+Regular の合計） } properties: { upgradePolicy: { mode: 'Automatic' } virtualMachineProfile: { priorityMix: { spotPriorityPercentage: 80 // Spot が全体の 80% regularPriorityPercentage: 20 } evictionPolicy: 'Deallocate' // 中断時は停止（再起動は別途処理） osProfile: { /* 省略 */ } storageProfile: { /* 省略 */ } } } } |
3‑4. 比率設計シナリオと期待削減率
| Spot : Regular | 想定削減率* | 主な適用対象 |
|---|---|---|
| 70 % : 30 % | 約 45 % | フロントエンド Web、非ミッションクリティカル API |
| 80 % : 20 % | 約 55 % | バッチ処理・データ解析ワークロード |
| 90 % : 10 % | 約 65 % | 大規模 HPC、短時間で完了する計算ジョブ |
*削減率は Spot の平均価格がオンデマンドの 30 % 前後になる前提です。実際の価格は Azure Portal の「Spot price」メトリックで確認してください。
4️⃣ Azure Advisor・Reserved Instances（RI）/Savings Plans の併用
4‑1. Advisor の Right‑Sizing 推奨取得手順
| 手順 | 操作 |
|---|---|
| ① | Portal → 「Azure Advisor」→「コスト最適化」タブを開く。 |
| ② | フィルターで対象の VMSS を選択し、右側付け（Right‑Sizing）推奨 を表示。 |
| ③ | 推奨項目にある 現在サイズ → 推奨サイズ と 予測削減額 を確認し、「実装」ボタンで自動更新（または Bicep/ARM で手動適用）。 |
4‑2. RI・Savings Plans のシミュレーション例（東京リージョン）
| プラン | 適用対象 | 契約期間 | 割引率目安 | 月額ベース (Standard_D4s_v3) |
|---|---|---|---|---|
| 1 年 RI（Standard） | 単一 SKU | 1 年 | 35 % | ¥73,000 → ¥47,450 |
| 3 年 RI（Convertible） | 任意 SKU | 3 年 | 45 % | ¥73,000 → ¥40,150 |
| Savings Plans (Compute) | 複数 SKU 混在可 | 1 年 / 3 年 | 30‑50 % | 利用実績に応じて自動適用 |
ベストプラクティス
1. Advisor → Right‑Sizing で過剰リソースを削減。
2. 削減後の安定稼働インスタンス数で 小規模 RI（10 %） をテスト導入し、実績が安定すれば拡大。
3. 長期的に Savings Plans に移行すると、SKU が変わっても割引が継続できるため、Spot 優先度ミックスとの相性が良い。
5️⃣ Cost Per Hour カスタムメトリックを用いたコスト感知型 Auto‑scale
5‑1. 前提条件と注意点
| 条件 | 内容 |
|---|---|
| Log Analytics ワークスペース | VMSS が所属するサブスクリプションにリンク済み。 |
| 課金データ取得 | Azure Consumption API の UsageDetails テーブルを Log Analytics にエクスポート（PowerShell/CLI で設定）。 |
| 集計間隔 | 5 分粒度で算出し、スケール判定に使用。 |
5‑2. カスタムメトリック作成手順
- Log Analytics 側のクエリ（Kusto）
|
1 2 3 4 5 6 |
UsageDetails | where ResourceId contains "Microsoft.Compute/virtualMachineScaleSets" | summarize totalCost = sum(PreTaxCost) by bin(TimeGenerated, 5m), VmssName = tostring(split(ResourceId, '/')[8]) | extend costPerHour = totalCost * 12 // 5分 → 1時間換算 (12倍) | project TimeGenerated, VmssName, costPerHour |
PreTaxCostは使用量ベースの課金額（USD）。日本円に変換したい場合は、為替レートテーブルとextend costJPY = costPerHour * 150のように追加してください。- 上記クエリは 5 分ごと に集計し、
costPerHourをカスタムメトリックとして保存します。
- カスタムメトリックの登録（Azure Monitor）
|
1 2 3 4 5 6 |
az monitor metrics create \ --resource /subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName> \ --name costPerHour \ --namespace "customMetrics" \ --value $(az monitor log-analytics query -w <workspace-id> --analytics-query "<上記KQL>" --query "costPerHour") |
- Auto‑scale 設定（JSON）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
{ "type": "Microsoft.Insights/autoscaleSettings", "apiVersion": "2022-10-01", "name": "costAwareAutoscale", "properties": { "profiles": [ { "name": "ScaleOutWhenCostHigh", "rules": [ { "metricTrigger": { "metricName": "costPerHour", "metricNamespace": "customMetrics", "timeGrain": "PT5M", "statistic": "Average", "threshold": 0.12, // $0.12/時 超過でスケールアウト "operator": "GreaterThan" }, "scaleAction": { "direction": "Increase", "type": "ChangeCount", "value": "2", "cooldown": "PT5M" } }, { "metricTrigger": { "metricName": "costPerHour", "metricNamespace": "customMetrics", "timeGrain": "PT5M", "statistic": "Average", "threshold": 0.08, // $0.08/時 以下でスケールイン "operator": "LessThan" }, "scaleAction": { "direction": "Decrease", "type": "ChangeCount", "value": "2", "cooldown": "PT10M" } } ] } ], "enabled": true, "targetResourceUri": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName>" } } |
5‑3. 補助的な通知（Logic Apps）
| トリガー | アクション |
|---|---|
Cost Per Hour が閾値超過（Azure Monitor アラート） |
Teams/メールへ通知、同時に Azure Automation Runbook で手動確認用スナップショット取得 |
6️⃣ 継続的コスト監視と運用ベストプラクティス
| 項目 | 実装例 |
|---|---|
| タグ付け | Environment=Prod, Project=WebApp を VMSS と関連リソースに統一。Cost Management の「タグ別集計」で部門ごとの費用可視化が可能。 |
| 予算設定 | Azure Cost Management → 「予算」作成 → 月額 ¥150,000（例）で 80 %・100 % アラートを Teams に送信。 |
| アラート | Spot Eviction Rate > 5 %、Cost Per Hour > $0.15 を Azure Monitor の「条件付きアラート」へ登録。 |
| CI/CD とスケジュールデプロイ | GitHub Actions → azure/arm-deploy@v1 で Bicep テンプレート（スケジューリング含む）を自動適用。例：オフピーク時は Regular VM を 2 台、オンピーク時に Spot を最大 8 台まで拡張。 |
| リカバリー | Spot が Eviction したら az vmss scale --new-capacity <regularCount> で Regular インスタンスを自動的に増やす Runbook を用意。 |
7️⃣ まとめ（要点）
- 価格は常に変動 – リージョン・為替レート・割引の有無を Azure Pricing Calculator で最新確認。
- 評価フロー – Fixed → Auto‑scale → Predictive → Schedule の４段階でシナリオ比較し、30 % 以上削減かつ SLA を満たす構成を選定。
- Spot 優先度ミックス – 公式ドキュメントは2024‑10‑07 更新版が正しい。Spot:Regular の比率と最低 Regular 台数の確保でコストと可用性を両立。
- Advisor + RI/Savings Plans – Right‑Sizing 後に小規模 RI でテスト、実績が安定すれば Savings Plans に移行すると最大 60 % 削減可能。
- Cost Per Hour カスタムメトリック – Log Analytics で課金データを集計し、Auto‑scale の条件に組み込むことで「費用感知型」スケーリングが実現できる。
- 継続的監視 – タグ・予算・アラート＋CI/CD による自動デプロイで、コスト超過をリアルタイムに検知・対処する体制を構築。
次のステップ
1. Azure Pricing Calculator と Consumption API を使い、現在使用中の VMSS の正確な単価を取得。
2. Advisor が提示する Right‑Sizing 推奨を実装し、最小構成でテストデプロイ。
3. Spot 優先度ミックス（例：80 % Spot / 20 % Regular）を Bicep でコード化し、ステージング環境で Eviction 率とスケール挙動を確認。
4. Cost Per Hour カスタムメトリックを作成し、Auto‑scale に組み込んだら本番環境に適用。
これらを順に実行すれば、コスト削減 × 可用性確保 の最適バランスが取れた Azure VM Scale Sets 運用が可能になります。
スポンサードリンク