AzureでWindows VM を実行する

Azure Backup
Azure Blob Storage
Azure Resource Manager
Azure Storage
Azure Virtual Machines

Azureで仮想マシン (VM) をプロビジョニングするには、ネットワークリソースやストレージ リソースなど、VM 自体以外にも追加のコンポーネントが必要です。 この記事では、Azureでセキュリティで保護されたWindows VM を実行するためのベスト プラクティスについて説明します。

アーキテクチャ

Azure 内にある Windows 仮想マシンを示すダイアグラム

このアーキテクチャのVisio ファイルをダウンロードしてください。

Workflow

この例では、必要なコンポーネントを含む単一の仮想マシンを使用した基本的なデプロイを示します。 仮想マシンはワークロードを実行でき、管理可能であり、パブリック インターネットと通信できます。 外部の脅威に直接触れないように設計されています。

  • 仮想マシンで実行されているワークロードは外部に公開されず、ハブとスポークの構成など、同じ仮想ネットワークまたはピアリングされた仮想ネットワーク内からのみアクセスできます。
  • 仮想マシンへの管理アクセスは、リモート デスクトップ プロトコル (RDP) 経由のAzure Bastionを使用して表示され、パブリック インターネットからは直接許可されません。
  • 送信外部インターネット アクセスは、ネットワーク アドレス変換 (NAT) ゲートウェイとそれに関連付けられているパブリック IP アドレスを使用して提供されます。

Components

リソースグループ

リソース グループ は、関連するAzure リソースを保持する論理コンテナーです。 一般には、リソースの有効期間や管理者に基づいて、リソースをグループ化します。

同じライフサイクルを共有する密接に関連付けられたリソースを同じ リソース グループにデプロイします。 リソース グループを使用すると、リソースをグループとしてデプロイおよび監視したり、リソース グループ別に課金コストを追跡したりできます。 セットとしてリソースを削除することもできます。これはテスト デプロイの場合に便利です。 特定のリソースの検索やその役割の理解を簡略化するために、意味のあるリソース名を割り当ててください。 詳細については、「Azure リソースのRecommended 名前付け規則を参照してください。

仮想マシン

VM は、公開済みのイメージの一覧から、または Azure Blob Storage にアップロードされたカスタム マネージド イメージや仮想ハード ディスク (VHD) ファイルからプロビジョニングできます。

Azureには、さまざまな仮想マシン サイズが用意されています。 既存のワークロードをAzureに移動する場合は、オンプレミス サーバーに最も近い VM サイズから始めます。 次に、CPU、メモリ、およびディスクの 1 秒あたりの入出力操作 (IOPS) について、実際のワークロードのパフォーマンスを測定し、必要に応じてサイズを調整します。

一般に、内部ユーザーまたは顧客に最も近いAzureリージョンを選択します。 すべてのリージョンですべての VM サイズを使用できるわけではありません。 詳細については、「リージョン別サービス」を参照してください。 特定のリージョンで使用可能な VM サイズの一覧については、Azure CLIから次のコマンドを実行します。

az vm list-sizes --location <location>

発行された VM イメージの選択については、「Find Windows VM イメージを参照してください。

ディスク

ディスク I/O のパフォーマンスを最大限に高めるには、ソリッド ステート ドライブ (SSD) にデータを格納する Premium SSD をお勧めします。 コストは、プロビジョニングされたディスクの容量に基づきます。 また、IOPS とスループットもディスク サイズによって異なるため、ディスクをプロビジョニングする場合は、3 つの要素 (容量、IOPS、スループット) すべてを考慮してください。 Premium SSD には無料のバースト機能があり、ワークロード パターンの理解と組み合わせることで、IaaS インフラストラクチャの効果的な SKU 選択とコスト最適化戦略が提供されます。 これにより、過剰な過剰プロビジョニングを行わずに高いパフォーマンスを実現し、未使用の容量のコストを最小限に抑えることができます。

注意

現在、Premium SSD v2 ディスクと Ultra ディスクは、データ ディスクにのみ使用できます。 OS ディスクではサポートされていません。

マネージド ディスクでは、ストレージが自動的に処理されることでディスク管理が簡素化されます。 マネージド ディスクにはストレージ アカウントが必要ありません。 ディスクのサイズと種類を指定すると、可用性の高いリソースとしてデプロイされます。 また、Managed disksオーバー プロビジョニングを必要とせずに目的のパフォーマンスを提供し、ワークロード パターンの変動を把握し、未使用のプロビジョニング容量を最小限に抑えることで、コストの最適化も実現します。

既定では、OS ディスクは Azure Disk Storage に格納されているマネージド ディスクであるため、ホスト マシンがダウンした場合でも保持されます。 高速プロビジョニングと OS 永続化が必要ないステートレス ワークロードの場合は、 エフェメラル OS ディスク をお勧めします。 これらのディスクは、リモート Azure Storageの代わりに VM ホストのローカル ストレージに OS イメージを配置し、読み取り待ち時間を短縮し、再イメージ化を高速化し、マネージド ディスク コストを排除します。 ただし、一時的な OS ディスク上のすべてのデータは、停止時 (割り当て解除)、再イメージ化、またはホスト メンテナンス復旧イベントで失われます。 エフェメラル OS ディスクでは、スナップショットやAzure Backupはサポートされていません。 VM がオートメーションから完全に再デプロイできる場合にのみ、エフェメラル OS ディスクを使用します。

選択した SKU によっては、VM がホスト マシン上の物理ドライブ (Windows 上の D: ドライブ) に格納されている一時ディスクがある場合もあります。 一時ディスクはAzure Storageに保持されず、再起動やその他の VM ライフサイクル イベント中に削除できます。 一時ディスクは、アプリケーション固有の一時ファイルやスワップ領域など、再起動後も存続する必要のないスクラッチ データにのみ使用します。

Windows仮想メモリ管理用のページ ファイルが必要です。 Small Computer System Interface (SCSI) ベースの VM サイズ (v5 以前) では、Marketplace イメージは既定でページ ファイルを一時ディスクに配置します。 非揮発性メモリ Express (NVMe) ベースの VM サイズ (v6 以降) では、NVMe 一時ディスクの起動後に初期化が必要になるため、ページ ファイルは既定で OS ディスクに設定されます。 エフェメラル OS ディスク VM の場合、ページ ファイルも OS ディスク上にあります。

可能であれば、OS ディスクではなく、データ ディスクにアプリケーションをインストールします。 一部のレガシー アプリケーションでは、C: ドライブへのコンポーネントのインストールが必要になることがあります。その場合は、PowerShell を使用して OS ディスクのサイズを変更できます。

アプリケーション データ用に 1 つ以上の データ ディスク を作成することをお勧めします。 データ ディスクは、Azure Storageによってサポートされる永続的なマネージド ディスクです。

VM に新しいディスクを追加すると、フォーマットが解除されます。 VM にログインして ディスクのフォーマットを行います。 新しいデータ ディスクの追加は、 PowerShell を使用して行うこともできます。

ネットワーク

ネットワーク コンポーネントには、次のリソースが含まれます。

  • Virtual network。 すべての VM は、複数のサブネットにセグメント化できるvirtual networkにデプロイされます。

  • ネットワーク インターフェイス (NIC) 。 NIC を使用すると、VM はvirtual networkと通信できます。 VM に複数の NIC が必要な場合は、VM サイズごとに NIC の最大数が定義されます。

  • パブリック IP アドレス。 パブリックIPアドレスは、外部のAzureからリモートデスクトップを介してVMと通信するために使用される可能性があります。 ただし、これは潜在的なセキュリティ リスクであるため、推奨されません。

    Warning

    パブリック IP アドレスを直接アタッチすることは、潜在的なセキュリティ リスクを表します。 これは、極端な状況 でのみ 実行し、ネットワーク セキュリティ グループを使用したトラフィックのフィルター処理などの他のセキュリティ方法と組み合わせて行う必要があります。

    仮想マシンへの管理アクセスには、VPN またはAzure ExpressRoute経由で接続されている場合は、Azure Bastionまたは内部的に使用することをお勧めします。

    • パブリック IP アドレスは、動的でも静的でもかまいません。 既定では、動的になっています。 変わらない固定 IP アドレスが必要な場合 (たとえば、DNS 'A' レコードを作成するか、またはセーフ リストに IP アドレスを追加する必要がある場合) は、静的 IP アドレスを予約します。
    • IP アドレスの完全修飾ドメイン名 (FQDN) を作成することもできます。 これにより、その FQDN を参照する DNS で CNAME レコードを登録できます。 詳細については、「Azure ポータルで完全修飾ドメイン名を作成するを参照してください。

  • ネットワーク セキュリティ グループ (NSG) 。 ネットワーク セキュリティ グループ は、VM やサブネットへのネットワーク トラフィックを許可または拒否するために使用されます。 サブネットまたは VM に接続されている個々の NIC に関連付けることができます。

    • すべての NSG には、既定の規則のセットが含まれています。これには、すべての受信インターネット トラフィックをブロックする規則が含まれます。 既定のルールを削除することはできませんが、他の規則でオーバーライドすることはできます。 インターネット トラフィックを有効にするには、特定のポート (HTTPS のポート 443 など) への受信トラフィックを許可する規則を作成します。

  • Azure NAT Gateway.Network Address Translation (NAT) ゲートウェイ は、プライベート サブネット内のすべてのインスタンスが完全にプライベートな状態でインターネットに送信接続できるようにします。 NAT Gateway を通過できるのは、アウトバウンド接続への応答パケットとして到着するパケットのみです。 インターネットからの未承諾の受信接続は許可されません。

注意

既定のセキュリティを向上させるために、すべての新しい仮想ネットワークで暗黙的な送信インターネット アクセスが非推奨になります。 送信インターネット接続は、NAT ゲートウェイ、Azure Standard Load Balancer、ファイアウォールなどの他のリソースを使用して明示的に構成する必要があります。 詳細については、 Azure での送信アクセスの既定値を参照してください。

  • Azure Bastion.Azure Bastion は、プライベート IP アドレス経由で VM への安全なアクセスを提供するサービス ソリューションとしてのフル マネージド プラットフォームです。 この構成では、インターネットに公開されるパブリック IP アドレスが VM に必要ないため、セキュリティ体制が向上します。 Azure Bastionでは、Azure ポータルやネイティブ SSH または RDP クライアントなど、さまざまな方法を使用して、トランスポート層セキュリティ (TLS) 経由で VM に安全なリモート デスクトップ プロトコル (RDP) または Secure Shell (SSH) 接続を直接提供します。

操作

診断 基本的な正常性メトリック、診断インフラストラクチャ ログ、ブート診断などの監視と診断を有効にします。 VM が起動不可能な状態になった場合は、起動エラーを診断するのにブート診断が役立ちます。 ログを格納するAzure Storage アカウントを作成します。 診断ログには、標準のローカル冗長ストレージ (LRS) アカウントで十分です。 詳細については、「監視と診断の有効化」を参照してください。

可用性。 VM が計画メンテナンスまたは計画外のダウンタイムの影響を受ける可能性があります。 VM の再起動ログを使用すると、VM の再起動が計画的なメンテナンスによるものかどうかを確認できます。 高可用性を実現するために、リージョン内の 可用性ゾーン 間で複数の VM をデプロイします。 これにより、より高い サービス レベル アグリーメント (SLA) が提供されます。 可用性ゾーンがサポートされていない場合、 可用性セット は、ホストの障害やホストの更新に対する保護を提供するのに役立ちます。 ただし、可能な場合は可用性ゾーンが推奨されるオプションです。

バックアップ。 偶発的なデータ損失から保護するには、Azure Backup サービスを使用して VM をストレージにバックアップします。 リージョンによっては、geo 冗長ストレージまたはゾーン冗長ストレージをバックアップに使用できます。 Azure Backupでは、アプリケーション整合性バックアップが提供されます。 パフォーマンスに影響を受けやすいワークロードの場合は、ボリューム シャドウ コピー サービス (VSS) を使用せずに VM のバックアップを実現し、パフォーマンスへの影響を軽減するエージェントレスのマルチディスク クラッシュ整合性バックアップ機能を検討してください。

VM の停止。 Azureでは、"停止" 状態と "割り当て解除済み" 状態が区別されます。 VM が割り当て解除されたときではなく、VM が停止状態のときに課金されます。 Azure ポータルで、Stop ボタンによって VM の割り当てが解除されます。 ログイン中に OS からシャットダウンした場合、VM は停止しますが割り当ては "解除されない" ため、引き続き課金されます。

VM の削除。 VM を削除する場合は、そのディスクを削除するか保持するかを選択できます。 つまり、データを失うことなく安全に VM を削除できます。 ただし、ディスクに対しては引き続き課金されます。 マネージド ディスクは、他のAzure リソースと同様に削除できます。 誤って削除されないようにするには、リソース ロックを使用して、リソース グループ全体をロックするか、VM などの個々のリソースをロックします。

代替案

  • 仮想マシン スケール セット - ビジネス運用に不可欠なワークロードは、単一の仮想マシンに依存しないでください。 スケール セットは、ノード間でワークロードを分散する機能を提供し、トラフィックの増加時にスケールアウトしたり、トラフィックが最小限のときにスケールインしたりして、コストを最小限に抑えることができます。

  • Azure Load Balancer は、複数の仮想マシンまたは仮想マシン スケール セット間の負荷分散を提供するのに役立ちます。 また、NAT ゲートウェイの代わりに使用して、インターネットからワークロードへのアクセスを許可し、送信アクセスもサポートすることもできます。

  • Application Gateway は、HTTP/HTTPS トラフィックの代替レイヤー 7 負荷分散オプションです。通常は、複数の仮想マシンまたは Azure リージョン内の仮想マシン スケール セットの前にデプロイされます。

  • エンタープライズ レベルのデプロイの詳細については、Azure ランディング ゾーンのAzure 仮想マシンベースライン アーキテクチャを参照してください。

シナリオの詳細

上の図では、このシナリオは、内部専用ユーザーに役立つ重要でないワークロードを提供する場合に役立ちます。

考えられるユース ケース

1 つの VM デプロイを使用して、インターネットに公開する必要のない、ある程度のダウンタイムに耐えることができる単純なアプリケーションをホストできます。 たとえば、これは基本的な内部レポート アプリケーションである可能性があります。

考慮事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

Reliability

信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

このアーキテクチャは単一の仮想マシンを使用する単純な例に過ぎないため、信頼性は最小限です。 仮想マシン自体または仮想マシンが実行されているホストに関する問題が発生すると、停止が発生し、ホストされているワークロードが使用できなくなります。 高可用性を必要とするワークロードの場合は、同じワークロードを含む複数の仮想マシンをデプロイし、それらのインスタンスを適切な負荷分散ソリューションの背後に配置する必要があります。 これらが同じリージョン内にある場合は、それらの VM を可用性ゾーン (サポートされている場合) にデプロイし、ワークロードが HTTP/HTTPS ベースの場合は、Azure Standard Load Balancerまたは Application Gateway のバックエンドに追加する必要があります。 これにより、バックエンド内の単一の仮想マシンがダウンした場合でも、ワークロードを引き続き使用できます。

仮想マシン スケール セット は、CPU やメモリの消費量など、いくつかのメトリックのいずれかに応じてインスタンスの数を自動的にスケールインまたはスケールアウトする機能を必要とするマルチノード ワークロードの管理を簡素化するのに役立つもう 1 つのオプションです。

高可用性/ディザスター リカバリー (HA/DR)

爆発半径を減らし、回復性を向上させるには、ワークロードを複数のリージョンにデプロイし、Azure ランディング ゾーン ガイダンスを活用する必要があります。 これは、プライマリ リージョンが使用できなくなった場合にセカンダリ リージョンにフェールオーバーする Active-Passive 構成、または両方のリージョンがコンシューマーにトラフィックを提供する Active-Active アーキテクチャにある可能性があります。 例については、「次の手順」の「HA/DR 用に構築された多層 Web アプリケーション」を参照してください。

この記事の例では、Azure Site Recovery を使用して、個々の仮想マシンのディスクをセカンダリ リージョンにレプリケートします。Site Recoveryを使用して、回復ポイント目標 (RPO)/目標復旧時間 (RTO) が低いセカンダリ リージョンにそれらの仮想マシンをフェールオーバーできます。

仮想マシンだけでなく、すべてのコンポーネントで HA/DR 要件を満たすようにアーキテクチャを評価してください。 これらすべての決定には、考慮事項の中にネットワーク、ID、データが含まれます。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、セキュリティ設計レビューのチェックリストを参照してください。

Microsoft Defender for Cloud を使用して、Azure リソースのセキュリティ状態を一元的に確認します。 Defender for Cloud は、潜在的なセキュリティ上の問題を監視し、デプロイのセキュリティの正常性を包括的に示します。 Defender for Cloud は、Azure サブスクリプションごとに構成されます。 「 Azure サブスクリプションの接続で説明されているように、セキュリティ データ収集を有効にします。 データ収集を有効にすると、Defender for Cloud Standard は、そのサブスクリプションに作成されているすべての VM を自動的にスキャンします。

更新プログラムの管理。 有効になっている場合、Defender for Cloud はセキュリティ更新プログラムや緊急更新プログラムが不足しているかどうかをチェックします。 VM でグループ ポリシー設定を使用して、システムの自動更新を有効にします。

マルウェア対策。 有効になっている場合、Defender for Cloudはマルウェア対策ソフトウェアがインストールされているかどうかを確認します。 Defender for Cloudを使用して、Azure ポータル内からマルウェア対策ソフトウェアをインストールすることもできます。

アクセスの制御。 Azureロールベースのアクセス制御 (Azure RBAC) を使用して、Azure リソースへのアクセスを制御します。 Azure RBAC を使用すると、DevOps チームのメンバーに承認ロールを割り当てることができます。 たとえば、閲覧者ロールはリソースAzure表示できますが、リソースの作成、管理、削除は行いません。 一部のアクセス許可は、Azureリソースの種類に固有です。 たとえば、仮想マシン共同作成者ロールは、VM の再起動または割り当ての解除、管理者パスワードのリセット、新しい VM の作成を行うことができます。 このアーキテクチャに役立つ可能性のあるその他の 組み込みロール には、 DevTest Labs ユーザー と ネットワーク共同作成者が含まれます。

注意

Azure RBAC では、VM にログインしたユーザーが実行できるアクションは制限されません。 これらのアクセス許可は、ゲスト OS のアカウントの種類によって決まります。

監査ログ。 プロビジョニング操作や他の VM イベントを確認するには、監査ログを使用します。

データの暗号化。 host で encryption を有効にして、一時ディスクやディスク キャッシュなど、VM データのエンドツーエンドの暗号化を実現します。 ホストでの暗号化は、VM ホスト インフラストラクチャでの暗号化を処理し、ゲスト ベースの暗号化とは異なり、VM CPU リソースを消費しません。 顧客管理キーは、永続的な OS ディスクとデータ ディスクの Azure Key Vault と共に使用できます。 一時ディスクとエフェメラル OS ディスクは、プラットフォームマネージド キーで暗号化されます。 プロビジョニングする前に、選択した VM サイズでホストでの暗号化がサポートされていることを確認します。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

使用法やワークロードに応じて、VM サイズにはさまざまなオプションがあります。 この範囲には、machine learning用に最適化された最新の GPU VM に対する Bs シリーズの最も経済的なオプションが含まれています。 使用可能なオプションの詳細については、「Azure Windows VM の価格」を参照してください。

予測可能なワークロードの場合は、Azure Reservations と Azure コンピューティングの節約計画を 1 年契約または 3 年契約で使用し、従量課金制の料金を大幅に削減します。 完了時間またはリソース消費の時間が予測できないワークロードの場合は、従量課金制オプションを検討してください。

Azureスポット VM を使用して、中断される可能性があり、事前に定義された期間内または SLA 内で完了を必要としないワークロードを実行します。 Azureは、使用可能な容量がある場合にスポット VM をデプロイし、容量を戻す必要があるときに削除します。 スポット仮想マシンに関連するコストは著しく低いです。 次のワークロードには、スポット VM を検討してください。

  • ハイ パフォーマンス コンピューティングのシナリオ、バッチ処理ジョブ、またはビジュアルなレンダリング アプリケーション。
  • 継続的インテグレーションおよび継続的デリバリー ワークロードを含むテスト環境。
  • 大規模ステートレスアプリケーション。

Azure料金計算ツールを使用してコストを見積もります。

詳細については、Microsoft Azure Well-Architected Framework のコストに関するセクションを参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「 オペレーショナル エクセレンスの設計レビュー チェックリスト」を参照してください。

コードとしてのインフラストラクチャ (IaC) テンプレートを使用して、Azureリソースとその依存関係をプロビジョニングします。 これらは、Bicep、Azure Resource Manager テンプレート (ARM テンプレート)、または Teraform を使用して、設定と確立されたツールの選択に応じて記述できます。 これらのテンプレートを使用すると、リソースをデプロイおよび構成するための 自動化されたデプロイ 手法の一部として、継続的インテグレーション/継続的配置 (CI/CD) プロセスが可能になります。 このアプローチにより、アーキテクチャのバージョン管理が可能になり、環境間の整合性が確保され、再現性、セキュリティ、コンプライアンスが適用されます。

問題の監視と診断を支援するには、リソースで診断ログが有効になっており、リソースの分析と最適化に役立つAzure Monitorで使用できることを確認します。 これらのログを使用して、重要なイベントのアラートと通知を実装できます。場合によっては、IT サービス管理 (ITSM) システムで自動修復またはチケットのログ記録を行うことができます。

パフォーマンス効率

パフォーマンス効率は、速度、応答性、スケーラビリティのためにクラウド ワークロードを最適化することに重点を置いています。 詳細については、 パフォーマンス効率の設計レビュー チェックリストを参照してください。

主な目標には、待機時間の最小化、スケーラブルなアーキテクチャの確保、リソース使用率の最適化、システム パフォーマンスの継続的な向上などがあります。

前述のように、ワークロード アーキテクチャ、VM SKU、ディスク構成に関して行われた決定は、ワークロードの実行方法に大きな影響を与える可能性があります。 適切な選択を行えば、将来ソリューションを再設計する必要がなくなり、柔軟性が向上し、コストが節約される可能性があります。

アーキテクチャを開発するときは、次の点を考慮してください。

  • ワークロードに動的な負荷が存在する場合は、仮想マシン スケール セットを使用します。 たとえば、大量のトラフィックの時間でスケールアウトし、トラフィックが減少したときにスケールインします。 これにより、コストを管理しながら十分な処理能力を確保できます。
  • 処理中に必要な IOPS を満たす適切な VM とディスク SKU を選択します。 パフォーマンスをさらに向上させるためにキャッシュを構成します。
  • ワークロードの待機時間が異常に大きい場合は、 近接通信配置グループ (PPG) を 使用して、パフォーマンスを向上させるために、複数の VM が物理的に近くに配置されるようにします。 PPG を可用性セットと組み合わせて使用して、1 つの物理データセンター内で低待機時間と高可用性を組み合わせることもできます。
  • 可能であれば、高速ネットワークを有効にして、コンポーネント間の待機時間を最小限に抑えます。
  • 不要なホップを最小限に抑えるようにネットワーク アーキテクチャを設計します。
  • Azure Monitor、VM Insights などのツールを使用して、メトリックを継続的に分析し、更新されたパフォーマンス ベースラインを作成します。 パフォーマンス情報を使用して、変更を実装する場所を決定し、それらのベースラインに対してテストします。

貢献者達

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

主要著者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ