Cloud & IT Cert Prep · レッスン

適正サイズ化と自動スケーリング

Q: 「適正サイズ化と自動スケーリング」で何を学びますか？

VM のパフォーマンス データを分析してインスタンスを適正サイズに変更し、予測可能なワークロードにスケジュールされた自動スケールを実装して、バッチ ワークロードには VMSS スポット インスタンスを使用します。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

VM のパフォーマンスデータを分析してインスタンスを適正サイズに変更し、予測可能なワークロードにスケジュールされた自動スケールを実装して、バッチワークロードには VMSS スポットインスタンスを使用します。

「適正サイズ化と自動スケーリング」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。

サイズ適正化とは

サイズ適正化とは、Azure VMまたはサービスのSKUをワークロードの実際のリソース要件に合わせるプロセスです。過剰プロビジョニング（コストの無駄）も、プロビジョニング不足（パフォーマンス低下のリスク）も避けます。オンプレミスから移行する際、多くの組織は慎重になり、当初は30～50%過剰にプロビジョニングします。通常は毎月、サイズ適正化の分析を定期的に行うことで、アプリケーションのパフォーマンスに影響を与えずに、過剰支出の大部分を回収できます。

VMパフォーマンスデータの分析

Azure Monitor metricsとVM Insightsを使用して、CPU、メモリ、ディスクIOPS、ネットワークスループットのデータを少なくとも30日間収集します。サイズ適正化したVMがトラフィックの急増に対応できるよう、平均値ではなくピーク（P95またはP99）の使用率を確認してください。Azure Advisorのサイズ適正化に関する推奨事項では、既定で過去7日間のデータが使用されますが、より代表性の高いデータを得るために、Advisor configurationで期間を30日または60日に延長できます。

# Get P95 CPU utilisation for a VM over 30 days
az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM \
  --metric 'Percentage CPU' \
  --aggregation Percentile \
  --interval P1D \
  --start-time 2024-05-01T00:00:00Z \
  --end-time 2024-06-01T00:00:00Z

VM SKUファミリとサイズ変更

Azure VMは、さまざまなワークロードに合わせて最適化されたSKUファミリに分類されています。D-series（汎用）、E-series（メモリ最適化）、F-series（コンピューティング最適化）、N-series（GPU）、L-series（ストレージ最適化）があります。VMのCPU使用率が低く、メモリ使用率が高い場合は、同じvCPU数のままD-seriesからE-seriesに移行すると、同程度のコストでより多くのRAMを利用できます。AzureでVMのサイズを変更する場合、通常は数分間の短い再起動が必要です。

# Resize a VM to a smaller SKU
az vm resize \
  --resource-group myRG \
  --name myVM \
  --size Standard_D2s_v5

予測可能なワークロードのスケジュールベースの自動スケーリング

スケジュールベースの自動スケーリングは、ワークロードのパターンが予測可能な場合に適しています。営業時間中はトラフィックが多く、夜間はほぼゼロになる小売アプリケーションでは、07:00にスケールアウトし、22:00にスケールインするスケジュールを設定できます。Virtual Machine Scale Sets (VMSS)とApp Serviceはいずれも、スケジュールされた自動スケールルールをサポートしています。既知の負荷パターンに対しては、メトリックベースの自動スケーリングよりも、この方法のほうがシンプルでコストを予測しやすくなります。

# Add a scheduled autoscale rule to a VMSS (scale out at 07:00, in at 22:00 UTC)
az monitor autoscale create \
  --resource-group myRG \
  --resource myVMSS \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name myAutoscale \
  --min-count 2 --max-count 10 --count 2

メトリックベースの自動スケーリング

メトリックベースの自動スケーリングでは、CPU使用率、HTTPリクエストキューの長さ、Azure Monitor経由で発行されたカスタムメトリックなどのリアルタイムメトリックに応じて、インスタンスを動的に追加または削除します。急激な増減を防ぐため、クールダウン期間を設けたスケールアウトルール（インスタンスを追加する条件）とスケールインルール（インスタンスを削除する条件）を定義します。ベストプラクティスは、スケールアウトのしきい値をスケールインのしきい値より低く設定することです。たとえば、CPUが70%を超えたらスケールアウトし、30%未満になったらスケールインするように設定し、クールダウン期間を5分とします。

# Add a metric-based scale-out rule (CPU > 70% for 5 minutes)
az monitor autoscale rule create \
  --autoscale-name myAutoscale \
  --resource-group myRG \
  --scale out 1 \
  --condition 'Percentage CPU > 70 avg 5m'

バッチワークロード向け VMSS スポットインスタンス

Azure Spot VMs を使用すると、従量課金価格と比べて最大 90% 割引で、未使用の Azure キャパシティを利用できます。ただし、Azure がキャパシティを回収する必要がある場合、30 秒前に通知してスポット VM をエビクトすることがあります。そのため、スポットインスタンスは、レンダリング、科学技術計算、データ処理パイプラインなどの中断可能なバッチワークロードに適しています。VMSS では、優先度混在ポリシーを使用して、同じスケールセット内で通常の VM（ベースライン用）とスポット VM（バーストキャパシティ用）を組み合わせられます。

# Create a VMSS with spot instances for batch workloads
az vmss create \
  --resource-group myRG \
  --name myBatchVMSS \
  --image UbuntuLTS \
  --priority Spot \
  --eviction-policy Deallocate \
  --max-price -1 \
  --instance-count 5

App Service の自動スケーリング

Azure App Service の自動スケーリングは、App Service プラン レベルで動作し、構成したルールに基づいてワーカーインスタンスを追加または削除します。利用できるメトリックトリガーには、HTTP キュー長、CPU 使用率、メモリ使用率があります。Standard レベル以上では手動スケーリングと自動スケーリングがサポートされますが、Basic レベルでサポートされるのは手動スケーリングのみです。サーバーレスワークロードには、従量課金プランの Azure Functions の使用を検討してください。このプランはゼロまでスケールし、実行ごとにのみ課金されるため、アイドル状態のインスタンスコストを完全に排除できます。

# Enable autoscale on an App Service plan
az monitor autoscale create \
  --resource-group myRG \
  --resource myAppServicePlan \
  --resource-type Microsoft.Web/serverfarms \
  --name webAppAutoscale \
  --min-count 1 --max-count 5 --count 1

避けるべき自動スケーリングの落とし穴

自動スケーリングでよくある落とし穴は次のとおりです。セッションアフィニティ — アプリが VM メモリにセッション状態を保存している場合、スケールインによってセッションが失われます。代わりに Redis Cache またはデータベースを利用したセッションを使用してください。起動時間が長い — VM やコンテナーのウォームアップに 10 分かかる場合、メトリックベースの自動スケーリングでは十分な速さで対応できません。予測されるピークの前に、スケジュールされたスケールアウトで事前にウォームアップしてください。スケールインが急すぎる — 処理中のリクエストがあるインスタンスを終了するとエラーが発生します。コネクションドレインを構成し、十分に長いクールダウン期間を設定してください。

データベースと PaaS の適正サイズ化

適正サイズ化は PaaS サービスにも適用されます。DTU モデルのAzure SQL Databaseは、DTU 使用率が継続的に 50% 未満であれば、サイズを小さくできます。vCore モデルでは、CPU とストレージを個別にスケーリングできます。永続化と geo レプリケーションが不要であれば、Azure Cache for Redis を Premium レベルから Standard レベルにダウンサイジングできます。Azure Kubernetes Service のノードプールでは、Cluster Autoscaler を使用して、保留中のポッドやアイドル状態に基づいてノードをスケールインおよびスケールアウトできます。

# Change Azure SQL Database service objective (tier)
az sql db update \
  --resource-group myRG \
  --server mySQLServer \
  --name myDatabase \
  --service-objective S2

継続的な適正サイズ化の実践

適正サイズ化は一度きりの作業ではありません。ワークロードは時間とともに変化します。トラフィックパターンが変わり、機能が追加され、ユーザー数が増減するためです。FinOps プロセスに毎月の適正サイズ化レビューを組み込み、Advisor の推奨事項を取得し、使用率が低い上位 10 件の VM と過剰にプロビジョニングされた PaaS サービスを確認して、担当チーム向けの作業項目を作成してください。FinOps の投資対効果を経営陣に示すため、推奨事項の生成数に対する実現した削減額を追跡してください。

適正サイズ化と予約の組み合わせ

最適なコスト戦略は、まず適正サイズ化し、その後で予約することです。過剰にプロビジョニングされた VM に対して Reserved VM Instance を購入すると、誤った SKU へのコミットメントが固定されます。まず VM を適切なサイズに変更し、新しい使用率を 30 日間観測して安定性を確認してから、その適正サイズ化した SKU の予約を購入してください。この 2 段階のアプローチにより、無駄な予約済みキャパシティを避けながら、割引を最大化できます。

クイックチェック

このレッスンで扱った Microsoft Azure Fundamentals（AZ-900）の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、適正サイズ化によってパフォーマンスメトリックを使用し、VM SKU を実際のワークロード要件に合わせる方法、スケジュールベースおよびメトリックベースの自動スケーリングによって需要に合わせてキャパシティを動的に調整する方法、そしてスポット VMによって中断可能なバッチワークロードを最大 90% 割引で実行する方法を学びました。次は、コミットメント型ワークロード向けの Azure Savings Plans と予約について説明します。

よくある質問