Azureで Linux VM を実行する

Azure Backup

Azure Bastion

Azure Blob Storage

Azure Resource Manager

Azure Storage

Azure Virtual Machines

Azureで仮想マシン (VM) をプロビジョニングするには、VM 自体よりも多くのコンポーネントが必要です。完全なデプロイには、ネットワークリソースとストレージリソースが含まれます。この記事では、Azureでセキュリティで保護された Linux VM を実行するためのベストプラクティスについて説明します。

アーキテクチャ

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

Workflow

この例では、1 つの VM に必要なコンポーネントを使用する基本的なデプロイを示します。 VM はワークロードを実行し、外部の脅威に直接触れないようにしながら、パブリックインターネットに到達できます。このアーキテクチャでは、次のことを行います。

VM 上のワークロードでは、インターネットに直接公開されません。アクセスは、ハブアンドスポーク構成など、同じ仮想ネットワーク内のリソースまたはピアリングされた仮想ネットワーク内のリソースに制限されます。
VM は、Secure Shell (SSH) 経由のAzure Bastionを使用して管理します。管理のためにパブリックインターネットから VM に直接アクセスする必要はありません。
ネットワークアドレス変換 (NAT) ゲートウェイとそれに関連付けられているパブリック IP アドレスは、送信外部インターネットアクセスを提供します。

Components

このアーキテクチャでは、次のコンポーネントを使用します。

リソースグループ

リソースグループは、関連するAzure リソースを保持する論理コンテナーです。リソースグループを使用すると、関連するリソースをまとめてデプロイ、監視、削除し、そのコストを 1 つの単位として追跡できます。

一般に、共有ライフサイクルと所有権によってリソースをグループ化します。リソースの識別と理解を容易にするために、一貫性のあるわかりやすい名前をリソースに使用します。詳細については、「名前付け規則を定義する」を参照してください。

仮想マシン

VM は、公開されたイメージの一覧、カスタムマネージドイメージ、または Azure Blob Storage にアップロードされた仮想ハードディスク (VHD) からプロビジョニングできます。 Azureでは、Debian、Red Hat Enterprise Linux (RHEL)、Ubuntu などの一般的な Linux ディストリビューションがサポートされています。詳細については、動作保証済み Linux ディストリビューションを参照してください。

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

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

az vm list-sizes --location <location>

発行された VM イメージの選択については、「Azure Marketplace イメージ情報の検索」を参照してください。

ディスク

ディスク入出力 (I/O) のパフォーマンスを最大限に高めるには、ソリッドステートドライブ (SSD) にデータを格納する Premium SSD をお勧めします。プロビジョニングされたディスクの容量によって、コスト、IOPS、スループット (データ転送速度) が決まります。ディスクサイズを選択するときは、3 つの要素をすべて考慮してください。 Premium SSD には無料バーストが含まれています。これは、オーバープロビジョニングなしでピーク需要を満たすのに役立ち、ワークロードパターンの理解と組み合わせると未使用の容量のコストを削減します。

注意

Premium SSD v2 ディスクと Ultra ディスクは、データディスクにのみ使用できます。オペレーティングシステム (OS) ディスクではサポートされていません。

マネージドディスクでは、ストレージが自動的に処理されることでディスク管理が簡素化されます。マネージドディスクにはストレージアカウントが必要ありません。ディスクのサイズと種類を指定すると、可用性の高いリソースとしてデプロイされます。また、マネージドディスクは、オーバープロビジョニングなしで必要なパフォーマンスを提供することでコストを削減します。これにより、未使用のプロビジョニング容量の支払いを回避できます。

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

既定では、多くの Linux イメージではスワップ領域が設定されません。ワークロードにスワップが必要な場合は、OS ディスクまたはデータディスクではなく cloud-init を使用して一時ディスクに作成します。

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

ディスクを作成すると、フォーマットが解除されます。 VM にサインインしてディスクのフォーマットを行います。 Linux シェルでは、データディスクはシリーズの /dev/sdc、 /dev/sdd、およびそれ以降の文字として表示されます。 lsblk を実行すると、ディスクなどのブロックデバイスの一覧を表示できます。データディスクを使用するには、パーティションとファイルシステムを作成し、ディスクをマウントします。次に例を示します。

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

データディスクを追加すると、ディスクに論理ユニット番号 (LUN) の ID が割り当てられます。たとえば、ディスクを交換して同じ LUN ID を保持する場合や、特定の LUN ID を検索するアプリケーションがある場合に、LUN ID を指定することもできます。ただし、LUN ID はディスクごとに一意である必要があります。

Premium Storage ディスクの場合は、SSD のパフォーマンスを最適化するために I/O スケジューラを変更できます。一般的な推奨事項は、SSD に No Operation (NOOP) スケジューラを使用することですが、 iostat などのツールを使用して、ワークロードのディスク I/O パフォーマンスを監視する必要があります。

多くの VM は、ホストコンピューター上の物理ドライブに格納される一時ディスクを使用して作成されます。ストレージには保存 されず 、再起動やその他の VM ライフサイクルイベント中に削除される可能性があります。ページファイルやスワップファイルなどの一時的なデータにのみ、このディスクを使用してください。 Linux VM の場合、一時ディスクは /dev/disk/azure/resource-part1 であり、/mnt/resource または /mnt でマウントされます。

ネットワーク

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

仮想ネットワーク: すべての VM は、サブネットにセグメント化される仮想ネットワークにデプロイされます。
ネットワークインターフェイスカード (NIC): NIC は VM を仮想ネットワークに接続し、すべての受信トラフィックと送信トラフィックを処理します。各 VM サイズでは、NIC の最大数が定義されます。
パブリック IP アドレス:パブリック IP アドレスを使用して、SSH 経由で外部Azureから VM と通信できます。ただし、このオプションは潜在的なセキュリティリスクであるため、推奨されません。

Warning

パブリック IP アドレスを VM に直接接続しないでください。極端な状況でのみ行い、ネットワークセキュリティグループ (NSG) を使用してトラフィックをフィルター処理するなど、他のセキュリティ対策を含めます。

VM への管理アクセスには、ブラウザーベースの SSH アクセスにAzure Bastionを使用するか、VPN またはAzure ExpressRoute経由でプライベートに接続します。
- パブリック IP アドレスは、動的でも静的でもかまいません。既定では、動的になっています。変更されない固定 IP アドレスが必要な場合 (たとえば、DNS 'A' レコードを作成する必要がある場合や、IP アドレスをセーフリストに追加する必要がある場合など) は、静的 IP アドレスを予約します。
- IP アドレスの完全修飾ドメイン名 (FQDN) を作成することもできます。これにより、その FQDN を参照する DNS で CNAME レコードを登録できます。詳細については、「VM の完全修飾ドメイン名を作成する」を参照してください。
Nsg：NSG を使用して、VM とサブネットへのネットワークトラフィックを許可または拒否します。それらをサブネットに関連付けるか、VM に接続されている個々の NIC に関連付けます。

すべての NSG には、すべての受信インターネットトラフィックをブロックする規則を含む、既定のセキュリティ規則のセットが含まれています。既定のルールは削除できませんが、他のルールでオーバーライドすることはできます。たとえば、HTTPS のポート 443 など、特定のポートへの受信インターネットトラフィックを許可する規則を作成できます。
Azure ネットワークアドレス変換 (NAT) ゲートウェイ:Azure NAT Gatewayでは、プライベートサブネット内のすべてのインスタンスが、完全にプライベートな状態でインターネットに送信接続できます。 NAT Gateway を通過できるのは、アウトバウンド接続への応答パケットとして到着するパケットのみです。インターネットからの未承諾の受信接続は許可されません。

注意

既定のセキュリティを向上させるために、すべての新しい仮想ネットワークで暗黙的な送信インターネットアクセスが非推奨になります。 NAT ゲートウェイ、Azure Standard Load Balancer、ファイアウォールなどの他のリソースを使用して、送信インターネット接続を明示的に構成する必要があります。詳細については、「Azure での既定の送信アクセス」を参照してください。
Azure Bastion:Azure Bastion は、プライベート IP アドレスを介して VM に安全にアクセスできるフルマネージドサービスとしてのプラットフォーム (PaaS) ソリューションです。この構成では、インターネットに公開されるパブリック IP アドレスが VM に必要ないため、セキュリティ体制が向上します。 Azure Bastionでは、Azure ポータルやネイティブ SSH または RDP クライアントなど、さまざまな方法を使用して、トランスポート層セキュリティ (TLS) 経由で VM に安全なリモートデスクトッププロトコル (RDP) または SSH 接続を直接提供します。

オペレーション

このセクションでは、Azureで Linux VM を管理するための主要な運用方法について説明します。

Ssh： Linux VM を作成する前に、2048 ビット RSA 公開キーと秘密キーのペアを生成します。 VM を作成する場合は、公開キーファイルを使用します。詳細については、「 SSH 公開キーと秘密キーのペアを作成して使用する」を参照してください。
診断： 基本的な正常性メトリック、診断インフラストラクチャログ、ブート診断など、監視と診断を有効にします。ブート診断は、VM が起動できない状態になると、ブートエラーを診断するのに役立ちます。診断ログをストレージアカウントに格納します。診断ログには、標準のローカル冗長ストレージ (LRS) アカウントで十分です。詳細については、「監視と診断のベストプラクティス」を参照してください。
可用性:計画メンテナンスまたは計画外のダウンタイムが VM に影響する可能性があります。 VM 再起動ログを使用して、計画メンテナンスによって VM の再起動が発生したかどうかを判断できます。高可用性を実現するために、リージョン内の可用性ゾーン間で複数の VM をデプロイします。このデプロイでは、より高いサービスレベルアグリーメント (SLA) が提供されます。可用性ゾーンがサポートされていない場合、可用性セットは、ホストの障害やホストの更新に対する保護を提供するのに役立ちます。ただし、可能な場合は可用性ゾーンが推奨されるオプションです。
バックアップ：偶発的なデータ損失から保護するには、Azure Backup サービスを使用して VM をストレージにバックアップします。リージョンによっては、geo 冗長ストレージまたはゾーン冗長ストレージをバックアップに使用できます。 Azure Backupでは、アプリケーション整合性バックアップが提供されます。パフォーマンスに依存するワークロードや、従来のバックアップエージェントをサポートしていない特殊な Linux ディストリビューションの場合は、エージェントレスのマルチディスククラッシュ整合性バックアップ機能を使用して、アプリケーションのパフォーマンスに影響を与えずにバックアップ保護を自動化します。
VM の停止: Azureは、停止状態と割り当て解除状態を区別します。 VM の状態が停止すると課金されますが、VM の割り当てが解除された場合は課金されません。 Azure ポータルで、Stop ボタンによって VM の割り当てが解除されます。ログイン中に OS を介して VM をシャットダウンした場合、VM は停止されますが、割り当てが解除 されないため 、料金は引き続き発生します。
VM の削除: VM を削除する場合は、そのディスクを削除するか保持するかを選択できます。これにより、データを保持できます。ただし、ディスクの料金は引き続き発生します。他のAzure リソースと同様に、マネージドディスクを削除できます。誤って削除されないようにするには、リソースロックを使用して、リソースグループ全体をロックするか、VM などの個々のリソースをロックします。

代替案

Azure Virtual Machine Scale Setsは、ノード間でワークロードを分散する機能を提供します。ビジネス操作に不可欠なワークロードは、単一の VM に依存しないでください。 VM インスタンスは、需要に基づいて自動的に追加または削除できます。また、トラフィックの増加時にスケールアウトしたり、トラフィックが低い場合にスケールインしたりして、コストを最小限に抑えることができます。
Azure Load Balancerは、複数の VM または仮想マシンスケールセット間でトラフィックを分散します。また、NAT ゲートウェイの代わりに使用して、インターネットからワークロードへのアクセスを許可すると同時に、送信アクセスをサポートすることもできます。
Application Gateway は、Azure リージョン内の HTTP/HTTPS ワークロードのAzure Load Balancerに負荷分散機能を提供します。
エンタープライズレベルのデプロイについては、Azure ランディングゾーンAzure 仮想マシンベースラインアーキテクチャに関するページを参照してください。

シナリオの詳細

前の図は、仮想ネットワーク内の 1 つの VM の基本的なデプロイを示しています。このシナリオは、内部のみのユーザーに重要でないワークロードを提供する場合に役立ちます。

考えられるユースケース

このアーキテクチャは、パブリックインターネットの公開を必要とせず、時折のダウンタイムを許容できる単純なアプリケーションに適しています。基本的な内部レポートツールは、一般的なユースケースです。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。詳細については、「 Well-Architected Framework」を参照してください。

Reliability

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

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

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

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

爆発半径を減らし、回復性を向上させるには、複数のリージョンにワークロードをデプロイし、Azureランディングゾーンのガイダンスを使用します。このデプロイは、アクティブ/パッシブ構成で、プライマリリージョンが使用できなくなった場合はセカンダリリージョンにフェールオーバーするか、両方のリージョンがコンシューマーにトラフィックを提供するアクティブ/アクティブアーキテクチャである可能性があります。

例については、高可用性とディザスターリカバリーのために構築された多層 Web アプリケーションを参照してください。この記事の例では、Azure Site Recoveryを使用して、個々の VM のディスクをセカンダリリージョンにレプリケートします。 Site Recoveryを使用すると、低い目標復旧ポイント (RPO) と目標復旧時間 (RTO) を使用して、これらの VM をセカンダリリージョンにフェールオーバーできます。

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

セキュリティ

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

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

Microsoft Defender for Cloud を使用して、Azure リソースのセキュリティ状態を一元的に確認します。 Defender for Cloudは、潜在的なセキュリティの問題を監視し、デプロイのセキュリティ正常性の包括的な図を提供します。 Azure サブスクリプションごとにDefender for Cloudを構成し、セキュリティデータの収集を有効にします。 Defender for Cloudは、そのサブスクリプションで作成された VM を自動的にスキャンします。
- パッチ管理:有効にすると、Defender for Cloudは不足しているセキュリティと重要な更新プログラムを識別します。
- マルウェア対策:有効にすると、Defender for Cloudはマルウェア対策ソフトウェアがインストールされているかどうかを確認します。 Defender for Cloudを使用して、Azure ポータルから直接マルウェア対策ソフトウェアをインストールすることもできます。
Azureロールベースのアクセス制御 (Azure RBAC) を使用して、Azure リソースへのアクセスを制御します。 Azure RBAC では、ユーザーに自分のジョブを実行するために必要なアクセス許可のみを付与します。たとえば、閲覧者ロールはAzureリソースを表示できますが、リソースの作成、管理、削除はできません。一部のアクセス許可は、Azureリソースの種類に固有です。たとえば、仮想マシン共同作成者ロールは、VM の再起動または割り当ての解除、管理者パスワードのリセット、新しい VM の作成を行うことができます。このアーキテクチャに役立つ可能性のあるその他の組み込みロールには、 DevTest Labs ユーザーとネットワーク共同作成者が含まれます。

注意

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

コストの最適化

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

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

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

Azureスポット VM は、大幅に削減されたレートで予備のAzure容量を使用します。 Azureは、容量を戻す必要があるときに、スポット VM を簡単に通知して削除できるため、厳密な完了期限のないフォールトトレラントなワークロードにのみ適しています。次の場合はスポット VM をご検討ください:

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

コストの見積もりには、Azure 料金計算ツールをご利用ください。

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

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

コードとしてのインフラストラクチャ (IaC) テンプレートを使用して、Azureリソースとその依存関係をプロビジョニングします。これらのテンプレートは、Bicep、Azure Resource Manager、または Terraform を使用して記述できます。これらのテンプレートは、自動デプロイを使用して、継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインの一部として使用できます。このアプローチでは、アーキテクチャのバージョン管理が提供され、環境間の一貫性が確保され、再現性、セキュリティ、コンプライアンスが適用されます。

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

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。詳細については、「パフォーマンス効率のための設計レビューチェックリスト」を参照してください。

パフォーマンス効率により、待機時間を最小限に抑え、スケーラブルなアーキテクチャを実現し、リソース使用率を最適化し、システムパフォーマンスを継続的に向上させることができます。ワークロードアーキテクチャ、VM サイズ、ディスク構成に関して行う決定は、ワークロードのパフォーマンスに大きく影響する可能性があります。適切な選択を行うと、将来的にソリューションを再設計し、柔軟性を高め、コストを節約する必要を防ぐことができます。

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

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

貢献者達

Microsoft では、この記事を保持しています。この記事を書いた当初の寄稿者は次のとおりです。

主要著者:

ドニー・トランパワー |シニアクラウドおよび AI ソリューションアーキテクト

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

次のステップ

フィードバック

このページはお役に立ちましたか?