本記事は Microsoft Learn の「仮想マシンの可用性を構成する」というモジュールをまとめたものである。
メンテナンスとダウンタイムについて計画する
Azure 管理者は、計画的および計画外の障害に備える必要がある。
メンテナンス計画について知っておくべきこと
Azure VM の可用性計画には、以下の 3 つの戦略が含まれるべき。
-
計画外ハードウェア メンテナンス
- 物理マシンやプラットフォーム コンポーネントの故障が予測された場合に発生
- Azure はライブ マイグレーションを使い、VM を正常な物理マシンに移行
- 移行中は VM が短時間一時停止し、パフォーマンス低下の可能性あり
-
予期しないダウンタイム
- ハードウェアや物理インフラの突然の障害(ネットワーク障害、ディスク障害、ラックレベル障害など)により発生
- 障害検知後、Azure が同じデータセンター内の正常なマシンに VM を自動復旧
- 復旧中に再起動が発生し、一時ディスクのデータが失われる可能性あり
-
計画メンテナンス
- プラットフォーム全体の信頼性、パフォーマンス、セキュリティ向上のため Microsoft が定期的に実施する更新
- VM に影響を与える場合があるが、事前に通知される
可用性セットを作成する
可用性セットは、複数の仮想マシンをグループ化して単一障害点の影響を防ぎ、データセンターでの OS アップグレード時にもすべての VM が同時に停止しないようにする論理機能。
可用性セットについて知っておくべきこと
- 可用性セット内のすべての仮想マシンは同じ機能セットを実行する必要がある
- 同じソフトウェアがインストールされている必要がある
- 仮想マシンは複数の物理サーバー、ラック、ストレージ、ネットワーク スイッチ上で実行されることが保証される
- 障害が発生しても、可用性セット内の一部の VM のみが影響を受け、アプリケーションは稼働し続ける
- 仮想マシンと可用性セットは同時に作成可能
- 可用性セットへの VM の追加は作成時のみ可能で、変更する場合は削除して再作成が必要
- 作成は Azure portal、ARM テンプレート、スクリプト、API で実行可能
- Azure では可用性セット付き VM に対して堅牢な SLA が提供される
可用性セットを使用するときに考慮すべきこと
- 冗長性を確保するには、可用性セットに複数の仮想マシンを配置
- アプリケーション層ごとに個別の可用性セットを使用し、単一障害点を軽減
- 高可用性とネットワーク性能向上のため、Azure Load Balancer で可用性セットを負荷分散
- 可用性セット内のブロックレベルストレージには、Azure マネージド ディスクを使用
更新ドメインと障害ドメインについて確認する
Azure Virtual Machine の可用性セットでは、仮想マシンごとに「更新ドメイン」と「障害ドメイン」が割り当てられ、デプロイやアップグレード時でも高可用性と耐障害性を維持できるようになっている。
更新ドメインについて知っておくべきこと
更新ドメインは、サービスのアップグレードやロールアウト時に同時に更新される仮想マシンのグループを指す。更新ドメインを使うことで、Azure は増分アップグレードやローリングアップグレードを安全に実行できる。
- 各更新ドメインには、同時に更新・再起動可能な仮想マシンと物理ハードウェアのセットが含まれる
- 計画メンテナンス中、一度に再起動されるのは更新ドメイン1つだけ
- 更新ドメインの既定数は5
- 最大で20個まで構成可能
障害ドメインについて知っておくべきこと
障害ドメインは、物理的な障害単位を表す仮想マシンのグループで、同じラックや共通ハードウェアを共有するノードとして考えられる。障害ドメインにより、ハードウェア障害やネットワーク障害、停電、ソフトウェア更新などの影響を局所化できる。
- 障害ドメインは同じ物理ラックやスイッチ、電源を共有する仮想マシンのグループ
- 2つの障害ドメインを使うことで、障害や保守作業の影響を分散できる
- 各障害ドメイン内の仮想マシンは、異なる可用性セットに配置可能
- 例: Web可用性セットとSQL可用性セットでは、それぞれの障害ドメインから1台ずつ仮想マシンを配置
可用性ゾーンについて確認する
可用性ゾーンは、Azureリージョン内にある独立したデータセンター単位で、障害ドメインと更新ドメインの考え方を組み合わせた仕組み。リージョン内に3つのゾーンがある場合、仮想マシンを3つ以上配置すると、それぞれ別々の障害ドメインと更新ドメインに分散される。これにより、同じ更新で複数のゾーンが同時に停止することはなく、障害やメンテナンスに強い構成が実現できる。また、コンピューティング・ストレージ・ネットワーク・データをゾーンごとに配置しつつ、他ゾーンにレプリケートすることで高可用性を確保できる。
可用性ゾーンについて知っておくべきこと
- 可用性ゾーンは、Azureリージョン内の一意の物理的な場所
- 各ゾーンは独立した電源・冷却・ネットワークを持つ1つ以上のデータセンターで構成
- 有効なリージョンには最低3つのゾーンが存在
- ゾーンは物理的に分離されており、1つのデータセンター障害からアプリやデータを保護
- ゾーン冗長サービスにより、アプリやデータはゾーン間でレプリケートされ、単一障害点を回避
可用性ゾーンを使用するときに考慮すべきこと
カテゴリ | 特徴 | 代表例 |
---|---|---|
ゾーンサービス | リソースを特定のゾーンに固定して配置する | Virtual Machines, Managed Disks, Standard IP アドレス |
ゾーン冗長サービス | サービスが自動的に複数ゾーンへレプリケートされ、冗長化される | ゾーン冗長ストレージ, SQL Database |
垂直方向と水平方向のスケーリングを比較する
信頼性の高い仮想マシンはスケーラビリティを持ち、リソースに応じてスループットを拡張できる。要求が増えても応答時間や性能を落とさず対応可能。スケーリングには、リソースを増強する垂直スケーリングと、台数を増やして分散する水平スケーリングの2種類がある。
垂直方向のスケーリングについて知っておくべきこと
垂直スケーリングは「スケールアップ/スケールダウン」と呼ばれ、仮想マシンのサイズをワークロードに合わせて変更する仕組み。処理能力を増やすのがスケールアップ、減らすのがスケールダウン。
シナリオ例
- 週末など利用率が低いときにVMサイズを小さくしてコスト削減
- 余分なVMを増やさずにサイズを大きくして需要増加に対応
水平方向のスケーリングについて知っておくべきこと
水平方向のスケーリングは「スケールアウト/スケールイン」と呼ばれ、ワークロードに応じて仮想マシンの台数を増減させる仕組み。台数を増やすのがスケールアウト、減らすのがスケールイン。
垂直方向と水平方向のスケーリングを使用するときに考慮すべきこと
垂直スケーリングはハードウェアの制約に依存するため、上限に達しやすく、仮想マシンの停止・再起動が必要になる場合がある。一方、水平方向のスケーリングは柔軟性が高く、大規模なワークロードにも対応可能。また、再プロビジョニングでは既存のVMを新しいVMに置き換える必要があり、中断やデータ移行を考慮する必要がある。
-
制限
- 垂直スケーリングは水平方向より制限が多い
- 大型ハードウェアの可用性に依存し、上限に達しやすくリージョン差がある
- 仮想マシンの停止・再起動が必要になり、アクセスが一時的に制限される可能性
-
柔軟性
- 水平方向のスケーリングは柔軟性が高い
- 数千台のVMを使ってワークロードやスループットの変化に対応可能
-
再プロビジョニング
- 既存VMを削除して新しいVMに置き換えるプロセス
- サービス中断を計画し、データ移行の必要性を判断
Azure Virtual Machine Scale Sets の実装
Azure Virtual Machine Scale Sets(VMSS)は、同一構成の複数の仮想マシンをまとめてデプロイ・管理するためのサービス。
-
自動スケーリング
- 需要が増えると仮想マシンの数を自動で増加
- 需要が減ると仮想マシンの数を自動で減少
-
利点
- 仮想マシンを事前にプロビジョニングする必要なし
- 大規模なビッグデータやコンテナー化ワークロードに対応可能
- ワークロードに応じて仮想マシンを柔軟に追加・削除
- 手動・自動・両方のスケーリング操作が可能
Azure Virtual Machine Scale Sets について知っておくべきこと
- すべての仮想マシンは同じOSイメージと構成から作成され、数百台でも容易に管理可能
- Azure Load Balancerでレイヤー4のトラフィック分散、Application Gatewayでレイヤー7の分散とTLS/SSL終端に対応
- 複数インスタンスでアプリケーションを実行し、1つのVMが障害でもアクセス中断を最小化
- 自動スケーリングで需要に応じて仮想マシンの数を増減
- 最大1,000台のVMをサポート、カスタムイメージ使用時は最大600台
Virtual Machine Scale Sets を作成する
Azure portal で Virtual Machine Scale Sets を作成でき、仮想マシンの台数やサイズを指定可能。さらに、スポットインスタンスやマネージドディスク、割り当てポリシーなどの設定も行える。
Azure portal には、Azure Virtual Machine Scale Sets を作成するために構成する設定がいくつかある。
-
オーケストレーションモード
- フレキシブル: 任意の構成のVMを手動で作成してスケールセットに追加
- ユニフォーム: VMモデルを定義すると、Azureが同一インスタンスを自動生成
-
イメージ
- ベースOSやアプリケーションを選択
-
VMアーキテクチャ
- x64: ソフトウェア互換性が高い
- Arm64: 同等のx64 VMより価格性能最大50%向上
-
サイズ
- ワークロードに応じてCPU・メモリ・ストレージ容量を決定
- VMサイズとOSに基づき時間単位で課金
-
拡散アルゴリズム
- スケールセット内のVMを障害ドメイン間でどのように分散するかを決定
- 最大拡散 (Max spreading): 可能な限り多くの障害ドメインにVMを分散
- 固定拡散 (Fixed spreading): VMを常に5つの障害ドメインに分散
- 使用可能な障害ドメインが5未満の場合、最大拡散は成功、固定拡散は失敗
- 推奨は最大拡散
自動スケーリングを実装する
Azure Virtual Machine Scale Sets の自動スケーリングは、ワークロードの需要に応じて仮想マシンの数を自動で増減させる仕組み。需要が低いときは不要なインスタンスを減らし、需要が高まると自動で追加して性能を維持できる。
自動スケーリングを使用するときに考慮すべきこと
-
自動調整される容量
- スケーリングルールで許容パフォーマンスを定義
- しきい値到達で容量が自動調整される
-
スケールアウト
- 需要増加が持続する場合、VMインスタンスを追加して負荷に対応
-
スケールイン
- 夜間や週末など需要低下時、VMインスタンスを減らしてコスト削減
-
スケジュール化されたイベント
- 決まった時間に容量を自動増減するようスケーリングを設定可能
-
オーバーヘッド削減
- 自動スケーリングにより、パフォーマンス監視や最適化の管理負荷を軽減
自動スケールの構成
Azure portal で Virtual Machine Scale Sets を作成する際は、手動スケーリングと自動スケーリングの両方を有効化可能。パフォーマンスを最適化するには、仮想マシンの最小・最大・既定のインスタンス数を設定し、スケーリングモードを選択する。
スケーリングモード
-
容量を手動で更新する
- 容量を手動で更新し、固定インスタンス数を維持
- インスタンス数を0~1000で設定
- スケールインポリシーで削除順序を指定(例: ゾーン分散後に最大IDのVMを削除)
-
自動スケーリング
- メトリックやスケジュールに基づき容量を自動調整
- 使用可能な最大インスタンス数を設定
自動スケールの構成
- 既定のインスタンス数: スケールセットに最初に展開されるVMの数(0~1000)
- インスタンスの制限: スケールダウン時の最小インスタンス数、スケールアップ時の最大インスタンス数
- スケールアウト: CPU使用率しきい値で自動スケーリングをトリガー、1回あたりの追加インスタンス数を指定
- スケールイン: CPU使用率しきい値で自動スケーリングをトリガー、1回あたりの削除インスタンス数を指定
- クエリ期間: 自動スケーリングエンジンがメトリック平均を確認して安定化させる期間
- スケジュール: 開始日・終了日を指定、特定曜日に繰り返し設定可能