Virtual Machinesとスケール セットに関する Azure Well-Architected Framework の観点

設計上Virtual Machines制限が発生する可能性があるクォータと制限を確認します。 VM には特定の制限とクォータがあり、VM の種類またはリージョンによって異なります。 サブスクリプションあたりの VM 数や VM あたりのコア数など、サブスクリプションの制限がある場合があります。 他のワークロードがサブスクリプションを共有している場合は、データを使用する機能が低下する可能性があります。 VM、仮想マシン スケール セット、マネージド ディスクの制限を確認します。

ネットワークおよびストレージ コンポーネントとの VM の相互作用を分析して、障害ポイントを最小限に抑えるために障害モード分析を実行します。 エフェメラル オペレーティング システム (OS) ディスクなどの構成を選択して、ディスク アクセスをローカライズし、ネットワーク ホップを回避します。 複数の VM にネットワーク トラフィックを分散することで自己保持を強化するロード バランサーを追加すると、可用性と信頼性が向上します。

Azure サービス レベル アグリーメント (SLA) に基づいて複合サービス レベル目標 (SLO) を計算します。 非現実的な期待と潜在的な問題を回避するために、SLO が Azure SLA よりも高くないことを確認します。

依存関係によって生じる複雑さに注意してください。 たとえば、仮想ネットワークやネットワーク インターフェイス カード (NIC) などの一部の依存関係には、独自の SLA がありません。 関連付けられたデータ ディスクなどの他の依存関係には、VM SLA と統合される SLA があります。 これらのバリエーションは VM のパフォーマンスと信頼性に影響を与える可能性があるため、考慮する必要があります。

ディスクやネットワーク コンポーネントなどのコンポーネントに対する VM の重要な依存関係を考慮します。 これらのリレーションシップを理解している場合は、信頼性に影響を与える重要なフローを決定できます。

状態の分離を作成します。 ワークロード データは、OS ディスクとの干渉を防ぐために、別のデータ ディスク上に存在する必要があります。 VM で障害が発生した場合は、同じデータ ディスクを使用して新しい OS ディスクを作成できます。これにより、回復性と障害の分離が保証されます。 詳細については、「 エフェメラル OS ディスク」を参照してください。

VM とその依存関係をゾーン間で冗長化します。 VM に障害が発生した場合、冗長性のためにワークロードは引き続き機能する必要があります。 冗長性の選択に依存関係を含めます。 たとえば、ディスクで使用できる組み込みの冗長性オプションを使用します。 ゾーン冗長 IP を使用して、データの可用性と高いアップタイムを確保します。

サービス レベルの低下を防ぎ、障害を回避するために、スケールアップとスケールアウトを行う準備を整えます。 Virtual Machine Scale Setsには、必要に応じて新しいインスタンスを作成し、複数の VM と可用性ゾーンに負荷を分散する自動スケーリング機能があります。

自動回復オプションを調べる。 Azure では、VM の正常性低下の監視と自己復旧機能がサポートされています。 たとえば、スケール セットは インスタンスの自動修復を提供します。 より高度なシナリオでは、自己復旧には、Azure Site Recoveryの使用、パッシブ スタンバイのフェールオーバー、またはコードとしてのインフラストラクチャ (IaC) からの再デプロイが含まれます。 選択する方法は、ビジネス要件と組織の運用に合わせて調整する必要があります。 詳細については、「 VM サービスの中断」を参照してください。

VM とその依存関係を右にサイズ変更します。 VM の予想される作業を理解して、容量が不足していないことを確認し、最大負荷を処理できるようにします。 障害を軽減するための追加の容量があります。

包括的なディザスター リカバリー計画を作成します。 災害への備えには、包括的な計画を作成し、復旧のためのテクノロジを決定する必要があります。

依存関係とステートフル コンポーネント (アタッチされたストレージなど) は、回復を複雑にする可能性があります。 ディスクがダウンした場合、その障害は VM の機能に影響します。 これらの依存関係の明確なプロセスを復旧計画に含めます。

厳密な操作を実行します。 信頼性設計の選択は、監視の原則、運用環境での回復性テスト、アプリケーション VM の修正プログラムとアップグレードの自動化、デプロイの一貫性に基づく効果的な操作によってサポートされる必要があります。 運用ガイダンスについては、「 オペレーショナル エクセレンス」を参照してください。

Linux VM と Windows VM とVirtual Machine Scale Setsのセキュリティ ベースラインを確認します。

ベースライン テクノロジの選択の一環として、ワークロードをサポートする VM SKU のセキュリティ機能を検討してください。

タイムリーかつ自動化されたセキュリティ パッチ適用とアップグレードを確保します。 適切に定義されたプロセスを使用して、更新プログラムが自動的にロールアウトおよび検証されていることを確認します。 Azure Automationなどのソリューションを使用して、OS 更新プログラムを管理し、重要な更新を行うことでセキュリティ コンプライアンスを維持します。

状態を保持する VM を特定します。 データが、organization指定された秘密度ラベルに従って分類されていることを確認します。 適切な保存レベルや転送中の暗号化などのセキュリティ制御を使用してデータを保護します。 機密性の高い要件がある場合は、二重暗号化や Azure コンフィデンシャル コンピューティングなどの高セキュリティ制御を使用して、使用中のデータを保護することを検討してください。

ネットワーク境界とアクセス制御を設定して、VM とスケール セットにセグメント化を提供します。 同じライフサイクルを共有するリソース グループに VM を配置します。

VM に到達しようとする ID と、他のリソースに到達する VM にもアクセス制御を適用します。 認証と承認のニーズにMicrosoft Entra IDを使用します。 VM とその依存関係 (シークレットなど) に対して強力なパスワード、多要素認証、ロールベースのアクセス制御 (RBAC) を配置して、許可された ID がロールに必要な操作のみを実行できるようにします。

Microsoft Entra条件付きアクセスを使用して、条件に基づいてリソース アクセスを制限します。 期間と必要なアクセス許可の最小セットに基づいて条件付きポリシーを定義します。

ネットワーク制御を使用して、イングレス トラフィックとエグレス トラフィックを制限します。 Azure Virtual Networkで VM とスケール セットを分離し、トラフィックをフィルター処理するネットワーク セキュリティ グループを定義します。 分散型サービス拒否 (DDoS) 攻撃から保護します。 ロード バランサーとファイアウォール規則を使用して、悪意のあるトラフィックやデータ流出攻撃から保護します。

Azure Bastion を使用して、運用アクセスのために VM に安全な接続を提供します。

VM からサービスとしてのプラットフォーム (PaaS) ソリューションとの間の通信は、プライベート エンドポイント経由である必要があります。

OS イメージを強化し、未使用のコンポーネントを削除することで、攻撃対象領域を減らします。 より小さいイメージを使用し、ワークロードの実行に必要ないバイナリを削除します。 必要のない既定のアカウントやポートなどの機能を削除して、VM 構成を強化します。

転送中のデータを保護するために必要な証明書などのシークレットを保護します。 キー コンテナーに格納されている証明書を自動的に更新する Windows または Linux 用の Azure Key Vault 拡張機能を使用することを検討してください。 証明書の変更が検出されると、拡張機能は対応する証明書を取得してインストールします。

脅威の検出。 VM で脅威と構成の誤りを監視します。 Defender for Servers を使用して VM と OS の変更をキャプチャし、アクセス、新しいアカウント、アクセス許可の変更の監査証跡を維持します。

脅威の防止。 ファイアウォール、ウイルス対策ソフトウェア、侵入検出システムなどのセキュリティ制御を実装することで、マルウェア攻撃や悪意のあるアクターから保護します。 信頼された実行環境 (TEE) が必要かどうかを判断します。

現実的なコストを見積もります。 料金計算ツールを使用して、VM のコストを見積もります。 VM セレクターを使用して、ワークロードに最適な VM を特定します。 詳細については、「 Linux と Windows の価格」を参照してください。

コスト ガードレールを実装する。 ガバナンス ポリシーを使用して、リソースの種類、構成、場所を制限します。 RBAC を使用して、保留中を超える可能性があるアクションをブロックします。

適切なリソースを選択します。 VM プランのサイズと SKU の選択は、全体的なコストに直接影響します。 ワークロードの特性に基づいて VM を選択します。 ワークロードの CPU 負荷は高いか、中断可能なプロセスを実行しますか? 各 SKU には、全体的なコストに影響するディスク オプションが関連付けられています。

依存リソースに適した機能を選択します。 予約容量を持つ Azure Backup ストレージを使用して、コンテナー標準レベルのバックアップ ストレージ コストを節約します。 1 年または 3 年間の予約にコミットすると、割引が提供されます。

Azure Storage のアーカイブ層は、アクセスされることの少ない BLOB データを格納するために最適化されたオフライン層です。 アーカイブ層では、ストレージ コストは最も低くなりますが、ホットおよびクールなオンライン層と比較して、データ取得コストと待機時間が高くなります。

ゾーン冗長サービスを使用して可用性の複雑さを軽減しながら、サイト障害から復旧するために VM のゾーン間 ディザスター リカバリー を使用することを検討してください。 運用の複雑さが軽減されるため、コスト面でメリットが得られる場合があります。

適切な課金モデルを選択します。 コンピューティング用のコミットメント ベースのモデルが、ワークロードのビジネス要件に基づいてコストを最適化するかどうかを評価します。 次の Azure オプションを検討してください。

• Azure の予約: 使用量ベースの価格と比較してコストを削減するために、予測可能なワークロードの前払いを行います。

  重要

  予約インスタンスを購入して、安定した使用量のワークロードに対する Azure のコストを削減します。 使用量を管理して、使用しているリソースよりも多くのリソースに対して支払いがないことを確認します。 予約インスタンスをシンプルにし、管理オーバーヘッドを低く抑えてコストを削減します。

• 節約プラン: 1 年または 3 年間、コンピューティング サービスに一定の時間単位の金額を費やすことをコミットすると、このプランによってコストが削減される可能性があります。
• Azure ハイブリッド特典: オンプレミスの VM を Azure に移行するときに保存します。

使用状況を監視します。 使用パターンを継続的に監視し、未使用または使用率の低い VM を検出します。 これらのインスタンスの場合は、VM インスタンスが使用されていないときにシャットダウンします。 監視は、オペレーショナル エクセレンスの主要なアプローチです。 詳細については、「 オペレーショナル エクセレンス」の推奨事項を参照してください。

最適化する方法を探します。 一部の戦略には、既存のシステムでリソースを増やすか、スケールアップするか、そのシステムのインスタンスを追加するか、スケールアウトするかの間で最もコスト効率の高いアプローチを選択する方法があります。他のリソースに分散することで需要をオフロードすることも、優先度キュー、ゲートウェイ オフロード、バッファリング、レート制限を実装することで需要を減らすことができます。 詳細については、「 パフォーマンス効率」の推奨事項を参照してください。

VM インスタンスを監視します。 VM インスタンスからログとメトリックを収集して、リソースの使用状況を監視し、インスタンスの正常性を測定します。 一般的な メトリック には、CPU 使用率、要求数、入出力 (I/O) 待機時間などがあります。 Azure Monitor アラート を設定して、問題に関する通知を受け取り、環境内の構成の変更を検出します。

VM とその依存関係の正常性を監視します。

• 監視コンポーネントをデプロイして、VM、ゲスト OS、ブート 診断 データの包括的なビューを提供するログとメトリックを収集します。 Virtual Machine Scale Setsテレメトリをロールアップします。これにより、個々の VM レベルまたは集計として正常性メトリックを表示できます。 Azure Monitor を使用して、VM ごとにこのデータを表示するか、複数の VM 間で集計します。 詳細については、「 エージェントの監視に関する推奨事項」を参照してください。
• VM の正常性状態をチェックするネットワーク コンポーネントを活用します。 たとえば、Azure Load Balancerは VM に ping を実行して異常な VM を検出し、それに応じてトラフィックを再ルーティングします。
• Azure Monitor アラート ルールを設定します。 監視データの重要な条件を決定して、問題を特定し、システムに影響を与える前に対処します。

定期的な操作の一部として定期的なシステム修正プログラムを含むメンテナンス プランを作成します。 即時パッチ 適用を可能にする緊急プロセスを含めます。 パッチ適用を管理するカスタム プロセスを作成したり、タスクを Azure に部分的に委任したりできます。 Azure には、個々の VM メンテナンス用の機能が用意されています。 更新中の中断を最小限に抑えるために、メンテナンス期間を設定できます。 プラットフォームの更新中は、障害ドメインに関する考慮事項が回復性の鍵となります。 ゾーンに少なくとも 2 つのインスタンスをデプロイすることをお勧めします。 ゾーン内の 1 つの障害ドメインのみが一度に更新されるため、ゾーンごとに 2 つの VM によって、各ゾーンに少なくとも 1 つの VM が保証されます。 そのため、3 つのゾーンに対して、少なくとも 6 つのインスタンスをプロビジョニングします。

ブートストラップ、スクリプトの実行、VM の構成のプロセスを自動化します。 拡張機能またはカスタム スクリプトを使用してプロセスを自動化できます。 次のオプションをお勧めします。

• Key Vault VM 拡張機能は、キー コンテナーに格納されている証明書を自動的に更新します。

• Windows および Linux 用の Azure カスタム スクリプト拡張機能は、Virtual Machinesでスクリプトをダウンロードして実行します。 この拡張機能は、デプロイ後の構成、ソフトウェアのインストール、その他の構成タスクや管理タスクに使用します。

• cloud-init を使用して、Linux ベースの VM のスタートアップ環境を設定します。

自動更新をインストールするためのプロセスがあります。 重要なパッチとセキュリティパッチをタイムリーにロールアウトするには、 VM ゲストの自動 パッチ適用を使用することを検討してください。 Azure Automationの Update Management を使用して、Azure の Windows VM と Linux VM の OS 更新プログラムを管理します。

運用環境と密接に一致するテスト環境を構築し、更新プログラムと変更を運用環境にデプロイする前にテストします。 セキュリティ更新プログラム、パフォーマンス ベースライン、信頼性エラーをテストするためのプロセスを配置します。 Azure Chaos Studio 障害ライブラリを利用して、エラー状態を挿入してシミュレートします。 詳細については、「 Azure Chaos Studio の障害とアクション ライブラリ」を参照してください。

クォータを管理します。 ワークロードに必要なクォータのレベルを計画し、ワークロードの進化に合わせてそのレベルを定期的に確認します。 クォータを増減する必要がある場合は、 これらの変更を早期に要求してください。

パフォーマンス目標を定義します。 パフォーマンス インジケーターを追跡して測定する VM メトリックを、応答時間、CPU 使用率、メモリ使用率、および 1 秒あたりのトランザクション、同時実行ユーザー、可用性と正常性などのワークロード メトリックとして特定します。

容量計画における VM、スケール セット、ディスク構成のパフォーマンス プロファイルを考慮します。 各 SKU にはメモリと CPU のプロファイルが異なり、ワークロードの種類によって動作が異なります。 パイロットと概念実証を実施して、特定のワークロードでのパフォーマンスの動作を理解します。

VM のパフォーマンス チューニング。 ワークロードで必要に応じて、パフォーマンスの最適化と機能の強化を活用します。 たとえば、高パフォーマンスのユース ケースと高速ネットワークにはローカルに接続された非揮発性メモリ Express (NVMe) を使用し、パフォーマンスとスケーラビリティを向上させるには Premium SSD v2 を使用します。

依存サービスを考慮します。 VM と対話するキャッシュ、ネットワーク トラフィック、コンテンツ配信ネットワークなどのワークロードの依存関係は、パフォーマンスに影響を与える可能性があります。 また、ゾーンやリージョンなどの地理的な分散を検討します。これにより、待機時間が増加する可能性があります。

パフォーマンス データを収集します。 適切な拡張機能を監視およびデプロイするための オペレーショナル エクセレンスのベスト プラクティス に従って、パフォーマンス インジケーターに対して追跡するメトリックを表示します。

近接配置グループ。 VM が物理的に互いに近くに配置されるようにするために、待機時間が短いワークロードでは 近接通信配置グループ を使用します。