サイズ設定とネットワークを計画する

10 分

Azure VM は、Azure で一般的なサービスとしてのインフラストラクチャ (IaaS) コンピューティングリソースの種類です。 Azure VM は、サービスとしてのプラットフォーム (PaaS) コンピューティングサービスと比較して、VM オペレーティングシステム (OS) とその構成をより柔軟に制御できます。制御と柔軟性の向上には、最適な結果をサポートするより多くの計画が必要になります。

このユニットでは、Azure Linux VM のデプロイを計画する際の全体的な要因と考慮事項について説明します。計画プロセスでは、VM 構成のコンピューティング、ネットワーク、ストレージの各側面を検討する必要があります。これらの特性の一部は OS 固有であり、実装の詳細は Linux ディストリビューションによって異なります。

Microsoft は主要な Linux ベンダーと提携して、各社の製品を Azure プラットフォームに統合しています。この統合を十分に活用するために、SUSE、Red Hat、Ubuntu などのさまざまな一般的な Linux ディストリビューション用のビルド済みイメージから Azure VM を作成できます。必要に応じて、クラウド環境で実行する Linux ディストリビューションのカスタムイメージをビルドすることもできます。このような場合、Azure VM のプロビジョニングプロセスに手順が追加される場合があります。

どちらの場合でも、この学習モジュールは、結果として得られるデプロイをさらに最適化するのに役立ちます。最適化を行うには、Azure VM リソースとその依存関係を十分に理解している必要があります。

リソースの依存関係について

Azure VM を作成するときは、仮想化された OS に完全な機能を提供するために、Azure VM が依存する複数の関連リソースを作成する必要もあります。これらのリソースには次が含まれます。

OS、アプリケーション、データを格納する仮想ディスク。
Azure VM を他の Azure サービスまたはオンプレミスのデータセンターに接続するための 1 つ以上のサブネットを持つ仮想ネットワーク。
Azure VM を仮想ネットワークのサブネットに接続するためのネットワークインターフェイス。

Note

すべてのネットワークインターフェイスには、少なくとも 1 つのプライベート IP アドレスが動的または静的に割り当てられている必要があります。プライベート IP アドレスは個別の Azure リソースではないですが、サブネット構成に含まれます。
Azure VM をホストするリソースグループ。
必要に応じて、VM のネットワークインターフェイスに関連付けられているパブリック IP アドレス。インターネットから VM への直接受信アクセスを提供します。

Azure VM リソースの依存関係を理解したので、VM のサイズ設定の計画を開始できます。

サイズ設定の計画

Azure VM の適切なサイズを決定するには、その対象のワークロードを考慮する必要があります。選択したサイズによって、VM の次の特性が決まります。

処理能力
メモリ
ストレージの容量
パフォーマンス
高度なネットワーク機能のサポート

重要

Azure VM には仮想 CPU (vCPU) クォータ制限があり、計画では、これを考慮する必要があります。クォータ制限をデプロイ後に引き上げるには、要求をオンラインで Azure サポートに送信する必要があります。

Azure には、仕様と価格が異なる幅広いサイズが用意されており、非常にさまざまなニーズを満たすことができます。 VM のサイズは、最適化の対象となるワークロードの種類を表す複数のカテゴリにグループ化されています。各カテゴリには、1 つ以上のシリーズ、つまり "ファミリ" があります。これらは、基本となるハードウェアの一般的な特性は共通していますが、提供されるサイズの範囲が異なります。

次のリストは、ワークロードの種類と、各ワークロードの種類の一般的なユースケースを示しています。各ワークロードの種類には、さまざまなサイズを含む対応するファミリがあります。

汎用: テストと開発、小規模から中規模のデータベース、および低規模から中規模のトラフィックの Web サーバー。
コンピューティング集中型:トラフィックが中程度の Web サーバー、ネットワークアプライアンス、バッチ処理、アプリケーションサーバー。
メモリ集中型:リレーショナルデータベースサーバー、中規模から大規模のキャッシュ、インメモリ分析。
ストレージ集中型:高いディスクスループットと入出力 (I/O) を必要とするビッグデータ、SQL、NoSQL データベース。
グラフィックス処理装置 (GPU) 対応:負荷の高いグラフィックスのレンダリングやビデオ編集、ディープラーニングを使用したモデルトレーニングと推論。
ハイパフォーマンスコンピューティング (HPC): リモート直接メモリアクセス (RDMA) をサポートする高スループットネットワークインターフェイスをオプションで備えた最も高速で強力な CPU VM。

Azure VM のサイズを計画する場合は、次の要因も考慮してください。

Azure VM のシリーズやサイズの変更は簡単であり、一般的に行われることですが、OS の再起動が必要です。再起動を回避するには、可能な場合は最初から VM のサイズを適切に設定します。
VM サイズの可用性はリージョンによって異なるため、デプロイを計画するときにリージョンの可用性を考慮してください。
Azure VM にアタッチできるディスクの最大数は、VM のサイズによって異なります。

その他のサイズに関する考慮事項

ワークロードの種類、OS、インストールされているソフトウェア、デプロイリージョンに基づいて最適な VM サイズを決定するには、Microsoft Azure VM セレクターの使用を検討してください。

サイズが同じまたは類似する Azure VM を同じ Azure リージョンで長期間にわたって使用することを計画している場合は、Azure Reservations の使用を検討してください。これにより、コンピューティングコストを最大 72% 削減できます。

中断を処理できるワークロード (バッチ処理ジョブなど) に対する Azure VM のコストを削減するには、Azure Spot VM を使用します。

ネットワークの計画

VM は、"仮想ネットワーク" を使用して外部リソースと通信します。 "仮想ネットワーク" は、Azure リージョン内のプライベートネットワークを表します。オンプレミスのデータセンターにあるネットワークを含む、他のネットワークに仮想ネットワークを接続し、トラフィックルールを適用することで受信および送信の接続を制御することができます。

各仮想ネットワークは、RFC 1918 で定義されているように、通常は 1 つ以上の "プライベートアドレス範囲" で構成される "IP アドレス空間" を指定します。オンプレミスネットワークと同様に、仮想ネットワークアドレス空間を複数の "サブネット" に分割して、Azure VM ワークロードを分離することができます。仮想ネットワーク内の各サブネットは、プライベートアドレス範囲を表します。ワークロードの分離を強制するには、"ネットワークセキュリティグループ (NSG)" を各サブネットに関連付けます。

すべての Azure VM には 1 つ以上の "ネットワークインターフェイス" が含まれており、各インターフェイスは同じ仮想ネットワーク内のサブネットに接続されます。 Azure では、サブネットのすべての VM に、サブネットの範囲から IP アドレスを自動的に割り当てます。 Azure では、各サブネットの最初の 4 つの IP アドレスと最後の IP アドレスが自身が使用するために予約され、これらは割り当てられません。

VM プロビジョニングプロセスの一環として仮想ネットワークとサブネットを作成できますが、推奨される方法は、ネットワーク環境を使用して Azure VM のデプロイ計画を開始することです。すべてのネットワーク要件を考慮し、対応する仮想ネットワークを作成したら、Azure VM のデプロイに進むことができます。

Azure 仮想ネットワークとサブネットを計画する際は、次の設計原則にご留意ください。

アドレス空間が重複しないようにします。仮想ネットワークとオンプレミスネットワークを接続する場合、IP アドレス空間は重複できません。
小規模の仮想ネットワークの数を増やすのではなく、数の少ない大規模な仮想ネットワークを使用します。この方法は、管理オーバーヘッドを最小限に抑え、スケーラビリティを促進するのに役立ちます。

ネットワーク帯域幅

Azure VM には複数のネットワークインターフェイスを含めることができますが、使用可能な帯域幅はそのサイズにのみ依存します。一般に、VM のサイズが大きいほど、小さいサイズよりも多くの帯域幅が割り当てられます。

割り当てられた制限に対して実際のネットワーク帯域幅の量を測定する場合、Azure ではエグレストラフィックのみを対象とします。 VM から送信されるすべてのネットワークトラフィックは、トラフィックの宛先に関係なく、その制限に算入されます。

Azure では、イングレス帯域幅は直接制限されません。ただし、ストレージやコンピューティングリソースの使用率などの要因は、Azure VM が処理できる受信データの量に影響します。

リモート接続の計画

デプロイ計画の一環として、リモート接続を提供するための最適なアプローチを検討してください。 Linux VM の場合、リモート接続には通常、Secure Shell (SSH) を使用してターミナルシェルセッションの転送中の暗号化を実装する必要があります。

SSH 接続を介して認証するには、ユーザー名とパスワード、または "SSH キーの組" を使用できます。 SSH 接続にパスワードを使用すると、VM はブルートフォース攻撃に対して脆弱になります。 SSH キーの使用は、SSH を使用して Linux VM に接続するためのより安全で推奨される方法です。

SSH キーを使用する場合でも、既定では、ターゲット Azure VM のネットワークアダプターに関連付けられているパブリック IP アドレスへの接続を開く必要があります。このパブリック IP は外部の脅威に対して脆弱であり、潜在的な攻撃ベクトルを表します。このリスクを軽減するには、Azure Bastion または Just-In-Time (JIT) VM アクセスの実装を検討してください。

Note

ハイブリッドシナリオでは、オンプレミス環境から Azure VM に接続するときにパブリック IP アドレスを不要にするために、サイト間仮想プライベートネットワーク (VPN) または Azure ExpressRoute を使用できます。

Azure Bastion

Azure Bastion サービスを、ターゲット VM に接続された仮想ネットワークの専用サブネットにデプロイします。 Azure Bastion は、Azure portal からのみ使用できる HTTPS 経由の外部 SSH 接続のブローカーとして機能します。 Azure Bastion を使用すると、ターゲット VM のネットワークインターフェイスにパブリック IP アドレスを割り当てる必要がなくなります。また、認証され、適切に許可されているユーザーのみが SSH 接続を開始できるようになります。

JIT VM アクセス

JIT VM アクセスとは Microsoft Defender for Cloud の機能であり、Azure VM のネットワークインターフェイスに関連付けられているパブリック IP アドレスへのアクセスを制限します。このような制限により、指定された時間枠内で指定された IP アドレス範囲からのみ着信接続を許可するように NSG が動的に調整されます。 Azure Bastion と同様に、ユーザーは、Azure portal から接続を開始する前に、認証を行う必要があります。