Virtual Machine Scale Sets の機能と利点
Virtual Machine Scale Sets では、一連の仮想マシン (VM) でアプリケーションを実行するためのスケーラブルな方法が提供されます。 スケール セット内の VM はすべて同じ構成を持ち、同じアプリケーションを実行することも、異なる構成を持ち、異なるアプリケーションを実行することもできます。 需要が増えると、スケール セットで実行される VM の数が増えます。 需要が減ったら、余分な VM を削除できます。 仮想マシン スケール セットは、コンピューティング ワークロード、ビッグ データ ワークロード、コンテナー ワークロードが含まれるシナリオに最適です。
この例のシナリオでは、あなたの顧客が会社の Web サイトのいずれかを使用して、配送の状態を管理および確認します。 Web サイトは世界中からアクセスされるため、特定の時刻の負荷を予測することが困難な場合があります。 さらに、負荷は季節によっても異なる場合があり、年末は休日になるため、12 月は繁忙期になります。 あなたは、顧客の要求に対する短い応答時間を維持しながら、Virtual Machine Scale Sets を使用して変動する負荷を処理することにしました。
このユニットでは、仮想マシン スケール セットの機能を確認します。 このユニットの終わりまでに、スケール セットのしくみについて説明できるようになります。 スケール セットがスケールアウトとスケールアップのシナリオをサポートする方法と、自動スケーリングとスケジュールベースのスケーリングを使用してスケール セットで使用できるリソースを調整する方法について説明します。
Virtual Machine Scale Sets とは
Azure の Virtual Machine Scale Sets は、負荷分散された数多くの VM をデプロイして管理できるように設計されています。 Virtual Machine Scale Sets は、VM インスタンスの数を自動的にスケールアップまたはスケールダウンできるインテリジェンスを備えています。
アップスケールまたはダウンスケールのアクティブ化に使用される条件には、カスタマイズされたスケジュールまたは実際の需要と使用状況を利用できます。 スケール セットでは、VM のグループに同じ構成を同時に適用できます。 不要な場合は、インスタンスを個別に手動で構成する必要はありません。
スケール セットでは、ロード バランサーを使用して、VM インスタンス間に要求が分散されます。 正常性プローブまたはアプリケーション正常性拡張機能を使用して、各インスタンスの可用性が判断されます。 正常性プローブまたはアプリケーション正常性拡張機能では、インスタンスに対して ping を実行します。 インスタンスから応答があった場合、スケール セットでは、インスタンスが引き続き使用可能であることが認識されます。 ping が失敗またはタイムアウトした場合、スケール セットでは、インスタンスが使用できないことが認識され、そのインスタンスには要求が送信されません。
Virtual Machine Scale Sets では、Azure 内の Linux および Windows VM の両方がサポートされており、単一のスケール セットで最大 1,000 個の VM を実行できます。
需要が変化し、予測できない大規模なワークロードを処理する場合、スケール セットは優れたソリューションです。 仮想マシン スケール セットは、需要に応じてスケーリングでき、負荷分散される仮想マシンを提供します。 これらは、高可用性環境を自動的に提供します。
スケール セットのスケーリング オプション
スケール セットは、コスト効果を高めるように設計されています。 新しい VM インスタンスは、必要な場合にのみ作成されます。
場合によっては、需要に応じて、スケール セット内のマシンを追加または削除する必要があります。 たとえば、週または日の期間で重要が少ないときは一部のコンピューターを実行する必要がない場合があります。 インスタンスの数を手動で増やしたり減らしたりして、スケール セット内の VM の数を調整できます。 多くの場合、ルールを使用して VM を自動的に追加または削除することをお勧めします。 ルールはメトリックに基づきます。 それにより、需要またはスケジュールに応じて、適切な数の VM が確実に追加されます。
スケール セットのスケーリング
Virtual Machine Scale Sets では、変動するワークロードに対して VM をすばやく作成および管理する必要性に対応できます。 スケール セットには、次の 2 種類のスケーリングを構成することができます。
スケジュール スケーリング: 1 個以上の追加インスタンスをデプロイしてトラフィックの急増に対応し、急増が終わったらスケールダウンして戻すように、スケール セットを事前にスケジュールできます。
自動スケーリング: ワークロードが変化し、常にスケジュールできるとは限らない場合は、メトリック ベースのしきい値のスケーリングを使用することができます。 自動スケーリングでは、ノードの使用量に基づいてスケールアウトされます。 その後、リソースがベースラインに戻ったらスケールバックします。
これらのオプションはどちらも、それに関連するコストを管理しながら、スケーリングの要件に対応します。 次の例では、さまざまな種類のスケーリングを使用する可能性があるシナリオについて説明します。
スケジュール スケーリング
たとえば、あなたは大規模な食品配送会社の DevOps チームに所属しているとします。 通常、金曜日の夜が最も忙しい時間です。 反対に、水曜日の午前 7 時は一般に最も需要が少ない時間です。
Azure ではリソースの消費量に基づいて課金されるため、必要ではないサービスは実行しないようにします。 金曜日の夜に需要を満たすために 100 台の Web サーバーが必要な場合は、その分の料金については快く支払います。 しかし、水曜日の朝に 2 台のサーバーのみが必要な場合は、アイドル状態の 98 台のサーバーについて支払いたくはありません。 運用要件に対応しながらコストを管理するには、スケジュール スケーリングを使用することを検討します。
自動スケーリング
あなたは、人気の靴を販売する会社の DevOps チームに所属しているとします。 間もなく商品の発売があり、サービスに対して大きな需要があると思われます。 しかし、需要の急増は予測ができず、数量を定めるのが難しい可能性があります。 現在のリソースが使用されているときに水平方向にスケーリングして、サービスで需要を満たす必要があります。
このシナリオでは、メトリック ベースの自動スケーリングを使用できます。 この種の自動スケーリングでは、需要が増加するとインフラストラクチャがスケールアウトされます。 需要が減少するとスケールインして戻されます。
スポット仮想マシンを使ってコストを削減する
Azure Spot Virtual Machines を使用すると、大幅にコストを削減して未使用の容量を利用できます。 Azure に元の容量が必要になったらいつでも、Azure インフラストラクチャは Azure Spot Virtual Machines を排除します。 したがって、これらの仮想マシンは、バッチ処理ジョブ、開発/テスト環境、大規模なコンピューティング ワークロードなど、中断してもかまわないワークロードに最適です。
利用可能な容量は、サイズ、リージョン、時刻、その他の要因によって異なります。 Azure Spot Virtual Machines をデプロイすると、利用可能な容量がある場合は Azure によって VM が割り当てられますが、このような VM には SLA がありません。 Azure スポット仮想マシンは、高可用性を保証するものではありません。 Azure の容量が必要になったらいつでも、Azure インフラストラクチャは 30 秒前通知の後、Azure Spot Virtual Machines を排除します。
Azure でコンピューティング能力が再び必要とされるようになると、Azure によってスケール セットから削除される VM に関する通知を受け取ります。 VM でコードをクリーンアップまたは正常に終了する必要がある場合は、Azure Scheduled Events を使用して、VM 内の通知に対応することができます。 また、別の VM を作成し、削除される VM を置き換えるように、スケール セットを設定することもできます。 ただし、新しい VM の作成は保証されません。
Azure Spot Virtual Machines では、削除ポリシーを設定することで、次の 2 種類の削除を指定できます。
- 割り当て解除ポリシー (既定値): VM は停止されます。 処理リソースとメモリ リソースは割り当てが解除されます。 ディスクはそのまま残り、データは保持されます。 VM が実行されていない間も、ディスク領域に対して料金が発生します。
- 削除ポリシー:基になるすべてのディスクを含む VM 全体が削除されるため、ストレージについて課金されることはありません。
Azure Spot Virtual Machines は、実行中に中断のあるワークロードや、非常に低いコストでより大きな VM を使用する必要がある場合に便利です。 VM が削除されるタイミングを制御できないことにだけは注意してください。