Azure での仮想マシン

  • [アーティクル]

適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット

Azure Virtual Machines は、Azure で提供されるオンデマンドでスケーラブルなコンピューティング リソースの種類の 1 つです。 通常、コンピューティング環境を他の選択肢よりも細かく制御する必要がある場合に仮想マシンを選択します。 この記事では、仮想マシンを作成する前に検討する必要のある事項、仮想マシンの作成方法、仮想マシンの管理方法に関する情報を提供します。

Azure 仮想マシンは、VM を実行する物理的なハードウェアを購入して維持する手間を省き、仮想化がもたらす柔軟性を提供するものです。 ただし、仮想マシンのメンテナンス、つまり仮想マシン上で動作するソフトウェアの構成、修正プログラムの適用、インストールは必要です。

Azure の仮想マシンは、さまざまな方法で利用できます。 いくつかの例を次に示します。

  • 開発とテスト - Azure Virtual Machines は、アプリケーションのコーディングとテストに必要な特定の構成でコンピューターをすばやく簡単に作成する手段を提供します。
  • クラウドのアプリケーション - アプリケーションの需要は変動する可能性があるため、Azure の仮想マシンでアプリケーションを実行することは経済的に理に適っています。 追加の仮想マシンが必要になったらその分の料金を支払い、不要になったらシャットダウンします。
  • データセンターの拡張 - Azure 仮想ネットワーク内の仮想マシンは、組織のネットワークに簡単に接続できます。

アプリケーションで使用する仮想マシンの数は、ニーズに応じてスケールアップおよびスケールアウトできます。

仮想マシンの作成前に検討する必要のある事項

Azure でアプリケーション インフラストラクチャを構築する際には、多数の設計上の考慮事項が必ず存在します。 開始する前に、仮想マシンの次の側面を考慮することが重要です。

  • リソースの名前
  • リソースが格納される場所
  • 仮想マシンのサイズ
  • 作成できる仮想マシンの最大数
  • 仮想マシンが稼働するオペレーティング システム
  • 開始後の仮想マシンの構成
  • 仮想マシンに必要な関連リソース

VM のパーツとその課金方法

仮想マシンを作成すると、その仮想マシンをサポートするリソースも作成されます。 これらのリソースには独自のコストがかかるため、考慮する必要があります。

仮想マシンをサポートする既定のリソースとその課金方法について、次の表で詳しく説明します。

リソース 説明 コスト
仮想ネットワーク 仮想マシンが他のリソースと通信できるようにするために使われます Virtual Network の価格
仮想ネットワーク インターフェイス カード (NIC) 仮想ネットワークに接続するために使われます NIC に対しては、別個のコストはかかりません。 ただし、VM のサイズに基づいて使用できる NIC の数には制限があります。 それに応じて VM のサイズを設定してください。また、仮想マシンの価格を参照してください。
プライベート IP アドレスと、場合によってはパブリック IP アドレス。 内部ネットワーク上と外部ネットワークとの通信とデータ交換に使われます IP アドレスの価格
ネットワーク セキュリティ グループ (NSG) お使いの VM とのネットワーク トラフィックを管理するために使われます。 たとえば、SSH アクセスのためにポート 22 を開く必要があり、さらにポート 80 へのトラフィックをブロックする場合があります。 ポート アクセスのブロックと許可は NSG を介して行われます。 Azure のネットワーク セキュリティ グループに追加料金はかかりません。
OS ディスクと、場合によってはデータ用の別個のディスク。 お使いのオペレーティング システムとは別のディスクにデータを保存することがベスト プラクティスです。VM に障害が発生した場合でも、データ ディスクをデタッチして新しい VM にアタッチするだけで済みます。 すべての新しい仮想マシンには、オペレーティング システム ディスクとローカル ディスクがあります。
Azure では、ローカル ディスク ストレージには課金されません。
オペレーティング システム ディスクは通常 127 GiB ですが、イメージによってはさらに小さいサイズであり、ディスクに対して通常料金がかかります。
Premium (SSD ベース) と Standard (HDD) ベースのディスクを仮想マシンにアタッチするためのコストは、マネージド ディスクの価格に関するページで確認できます。
場合によっては、OS のライセンス 仮想マシンで OS を実行できるようにするために使われます コストは VM のコア数によって異なるため、それに応じて VM のサイズを設定します。 Azure ハイブリッド特典を使って、このコストを削減できます。

公開および秘密 SSH キーの作成と格納を Azure に許可することもできます。この場合、Azure はお使いの VM 内で公開キーを使います。お客様は SSH 経由でその VM にアクセスするときに秘密キーを使います。 それ以外の場合は、ユーザー名とパスワードが必要になります。

既定では、これらのリソースはその VM と同じリソース グループに作成されます。

場所

Azure リソースを作成できる地理的地域は、世界各地に複数あります。 通常、この地域は仮想マシンの作成時には場所と呼ばれます。 仮想マシンの場合、この場所によって仮想ハード ディスクの格納場所が指定されます。

次の表に、利用可能な場所の一覧を取得する方法の一部を示します。

Method 説明
Azure portal 仮想マシンを作成するときに一覧から場所を選択します。
Azure PowerShell Get-AzLocation コマンドを使用します。
REST API 場所の一覧表示操作を使用します。
Azure CLI az account list-locations 操作を使用します。

可用性

Azure で仮想マシンの可用性を管理するためのオプションがいくつかあります。

  • Availability Zones は、Azure リージョン内の物理的に分離されたゾーンです。 Availability Zones では、同じ Azure リージョン内の 2 つ以上の Availability Zones に 2 つ以上のインスタンスがデプロイされている場合、少なくとも 99.99% の時間で、少なくとも 1 つのインスタンスへの仮想マシン接続が保証されます。
  • Virtual Machine Scale Sets では、負荷分散が行われる仮想マシンのグループを作成して管理することができます。 需要または定義されたスケジュールに応じて、仮想マシン インスタンスの数を自動的に増減させることができます。 スケール セットは、アプリケーションの高可用性を実現します。また、多数の仮想マシンの一元的な管理、構成、更新を可能にします。 スケール セット内の仮想マシンは、複数の可用性ゾーン、1 つの可用性ゾーン、またはリージョンにデプロイすることもできます。

詳細については、「Azure 仮想マシンの可用性オプション」と Azure 仮想マシンの SLA に関するページを参照してください。

サイズと価格

使用する仮想マシンのサイズは、実行するワークロードによって決まります。 さらに、選択したサイズによって、処理能力、メモリ、ストレージの容量、ネットワーク帯域幅などの要素が決まります。 Azure では、さまざまな種類の使用をサポートするために、さまざまなサイズを用意しています。

Azure では、仮想マシンのサイズおよびオペレーティング システムに基づいて時間単位の料金が請求されます。 時間単位を満たさない場合は、分単位でのみ請求されます。 ストレージは別料金で、別個に請求されます。

仮想マシンの総コア数の制限

サブスクリプションにはそれぞれ既定のクォータ制限が設けられており、プロジェクトで多数の仮想マシンをデプロイする場合に、その点が影響する可能性があります。 現在は、リージョンあたり 20 個の仮想マシン総コア数の制限がサブスクリプションごとに設けられています。 制限は、サポート チケットで引き上げを依頼することによって引き上げることができます。

Managed Disks

Managed Disks により、Azure Storage アカウントの作成および管理はバックグラウンドで処理されるため、ストレージ アカウントのスケーラビリティの制限について心配する必要がありません。 ディスク サイズとパフォーマンス レベル (Standard または Premium) を指定すると、Azure によってディスクが作成および管理されます。 ディスクの追加や仮想マシンのスケールアップとスケールダウンを行うときに、使用されているストレージについて心配する必要はありません。 新しい仮想マシンを作成する場合は、Azure CLI または Azure portal を使用して、管理 OS とデータ ディスクで仮想マシンを作成します。 アンマネージド ディスクに仮想マシンが配置されている場合でも、仮想マシンをマネージド ディスクでバックアップするように変換できます。

また、Azure リージョンごとに 1 つのストレージ アカウントでカスタム イメージを管理することができます。このカスタム イメージを使用すると、同じサブスクリプション内で何百もの仮想マシンを作成することができます。 Managed Disks の詳細については、Managed Disks の概要に関するページをご覧ください。

ディストリビューション

Microsoft Azure では、さまざまな Linux ディストリビューションと Windows ディストリビューションがサポートされています。 利用可能なディストリビューションは、マーケットプレースや Azure portal で見つけるか、CLI、PowerShell、REST API を使用して結果をクエリすることができます。

次の表に、イメージに関する情報を見つける方法をいくつか示します。

Method 説明
Azure portal 値は、使用するイメージを選択する際に自動的に指定されます。
Azure PowerShell Get-AzVMImagePublisher -Location location
Get-AzVMImageOffer -Location location -Publisher publisherName
Get-AzVMImageSku -Location location -Publisher publisherName -Offer offerName
REST API イメージ発行元の一覧表示
イメージ プランの一覧表示
イメージ SKU の一覧表示
Azure CLI az vm image list-publishers --location 場所
az vm image list-offers --location 場所 --publisher 発行元名
az vm image list-skus --location 場所 --publisher 発行元名 --offer プラン名

Microsoft はパートナーと連携し、利用可能なイメージが Azure ランタイム用に更新、最適化されたことを確認します。 Azure パートナーのプランの詳細については、Azure Marketplace を参照してください。

cloud-init

Azure は Linux ディストリビューションの多くで、cloud-init をサポートしています。 Microsoft は、Linux パートナーと協力して、cloud-init 対応のイメージを Azure Marketplace で利用できるようにする作業を行っています。 これらのイメージによって、cloud-init のデプロイと構成が、仮想マシンおよび仮想マシン スケール セットとシームレスに動作するようになります。

詳細については、Azure Linux 仮想マシンに対する cloud-init の使用に関する記事を参照してください。

ストレージ

ネットワーク

サービスの中断

Microsoft では、必要なときにサービスがいつでも使用できるように取り組んでいますが、 やむを得ない事情により、計画されていないサービス中断が発生することがあります。

Microsoft は、稼働時間と接続に関するコミットメントとして、サービスのサービス レベル アグリーメント (SLA) を提供しています。 個々の Azure サービスの SLA については、 Azure サービス レベル アグリーメントに関するページを参照してください。

Azure には、可用性の高いアプリケーションをサポートするさまざまなプラットフォーム機能が既に組み込まれています。 これらのサービスの詳細については、 Azure アプリケーションのディザスター リカバリーと高可用性に関する記事をご覧ください。

この記事では、大きな自然災害や広範囲にわたるサービス中断により、リージョン全体で障害が発生した場合の真のディザスター リカバリーのシナリオについて説明します。 こうした状況はほとんど発生しませんが、リージョン全体で中断が発生する可能性に対して準備する必要があります。 リージョン全体でサービス中断が発生した場合、データのローカルにおける冗長的なコピーは、一時的に使用できなくなります。 geo レプリケーションを有効にする場合は、Azure Storage の BLOB とテーブルのコピーがさらに 3 つ、別のリージョンに格納されます。 地域的な停電や災害が発生し、プライマリ リージョンを復旧できない場合は、すべての DNS エントリが、geo レプリケートされたリージョンに再マッピングされます。

こうした状況はほとんど発生しませんが、Azure 仮想マシンのアプリケーションがデプロイされているリージョン全体でサービス中断が発生した場合は、Azure 仮想マシンに関する次のガイダンスに従って対応してください。

オプション 1: Azure Site Recovery を使用してフェールオーバーを開始する

VM に Azure Site Recovery を構成して、1 回のクリックによってわずか数分でアプリケーションを復旧できるようにします。 任意の Azure リージョンにレプリケートでき、ペア リージョンに限定されません。 仮想マシンのレプリケートから始めます。 復旧計画を作成して、アプリケーションのフェールオーバー プロセス全体を自動化できます。 運用アプリケーションや実行中のレプリケーションに影響を与えることなく、事前にフェールオーバーをテストできます。 プライマリ リージョンでの中断が発生した場合は、フェールオーバーを開始して、アプリケーションをターゲット リージョンに移すだけです。

オプション 2: 復旧を待つ

この場合、ユーザーによる操作は必要ありません。 サービスを利用できるようにするために鋭意取り組んでいることをご理解ください。 現在のサービスの状態は、 Azure サービス正常性ダッシュボードで確認できます。

中断前に Azure Site Recovery、読み取りアクセス geo 冗長ストレージ、または geo 冗長ストレージを設定しなかった場合は、このオプションの使用をお勧めします。 VM 仮想ハード ドライブ (VHD) が格納されているストレージ アカウントに対して geo 冗長ストレージまたは読み取りアクセス geo 冗長ストレージを設定した場合は、基本イメージ VHD の回復を当てにして、そこから新しい VM のプロビジョニングを試みることができます。 データの同期が保証されないので、このオプションはお勧めできません。 そのため、このオプションの動作は保証されません。

Note

ユーザーはこのプロセスを制御できないこと、およびリージョン全体のサービス中断の場合にのみ行われることに注意してください。 そのため、最高レベルの可用性を実現するには、アプリケーション固有の他のバックアップ戦略にも依存する必要があります。 詳細については、 ディザスター リカバリーのためのデータ戦略に関するセクションをご覧ください。

サービスの中断に関するリソース

データの保存場所

Azure では、顧客データを 1 つのリージョンに格納できるようにする機能は現在、アジア太平洋地域の東南アジア リージョン (シンガポール) と、ブラジル地域のブラジル南部リージョン (サンパウロ州) でのみ使用できます。 その他のすべてのリージョンでは、顧客データは geo 内に格納されます。 詳細については、セキュリティ センターに関するページを参照してください。

次のステップ

最初の仮想マシンを作成します。