Azure 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 アドレスを使用して、データの可用性と高いアップタイムを確保します。

サービス レベルの低下を防ぎ、障害を回避するために、スケールアップとスケールアウトの準備をしてください。 仮想マシン スケール セット には、必要に応じて新しいインスタンスを作成し、複数の VM と可用性ゾーンに負荷を分散する自動スケール機能があります。

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

仮想マシンとその依存関係を最適化します。 VM の予想される作業を理解して、VM が過大な負荷を受けず、最大負荷を処理できることを確認します。 障害を軽減するための追加の容量を用意します。

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

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

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

Linux および Windows VM と仮想マシン スケール セットのセキュリティ ベースラインを確認します。

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

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

状態を保持する VM を特定します。 組織が提供する秘密度ラベルに従ってデータが分類されていることを確認します。 適切な保存レベルや転送中の暗号化などのセキュリティコントロールを使用してデータを保護します。 機密性の高い要件がある場合は、二重暗号化や 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 ストレージを使用して、コンテナー Standard レベルのバックアップ ストレージ コストを節約します。 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、ブート診断データの包括的なビューを提供するログとメトリックを収集します。 仮想マシン スケール セットはテレメトリをロールアップします。これにより、個々の 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 Update Manager を使用して、Azure の Windows および Linux VM の OS 更新プログラムを管理します。

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

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

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

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

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

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

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

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