Azure での Linux VM の実行

Backup
Blob Storage
Linux Virtual Machines
Storage
Virtual Machines

Azure での仮想マシン (VM) のプロビジョニングには、VM 自体の他に、ネットワーク リソースやストレージ リソースなどの追加コンポーネントがいくつか必要です。 この記事では、Azure 上で Linux VM を実行するためのベスト プラクティスを示します。

アーキテクチャ

Azure の Linux VM を示す図。

ワークフロー

Resource group

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

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

仮想マシン

VM は、発行されたイメージの一覧や、Azure BLOB ストレージにアップロードされたカスタム管理されたイメージまたは仮想ハード ディスク (VHD) ファイルからプロビジョニングできます。 Azure は、CentOS、Debian、Red Hat Enterprise、Ubuntu、FreeBSD など、現在普及しているさまざまな Linux ディストリビューションに対応します。 詳細については、「Azure と Linux」を参照してください。

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

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

az vm list-sizes --location <location>

発行された VM イメージの選択については、Linux VM イメージの検索に関するページを参照してください。

ディスク

最適なディスク I/O パフォーマンスを得るには、データがソリッド ステート ドライブ (SSD) に格納される Premium Storage をお勧めします。 コストは、プロビジョニングされたディスクの容量に基づきます。 また、IOPS とスループット (つまり、データ転送速度) もディスク サイズによって異なるため、ディスクをプロビジョニングする場合は、3 つの要素 (容量、IOPS、スループット) すべてを考慮してください。

Managed Disks を使用することもお勧めします。 マネージド ディスクでは、ストレージが自動的に処理されることでディスク管理が簡素化されます。 マネージド ディスクでは、ストレージ アカウントは必要ありません。 ディスクのサイズと種類を指定するだけで、可用性の高いリソースとしてデプロイされます

OS ディスクは Azure Storage に格納された VHD であるため、ホスト マシンが停止している場合でも維持されます。 Linux VM の場合、OS ディスクは /dev/sda1 です。 また、データ ディスクを 1 つ以上作成することもお勧めします。データ ディスクは、アプリケーション データ用に使用される永続的な VHD です。

作成した VHD は、フォーマットされていません。 その 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 アカウントで使用する VM のディスクは SSD なので、I/O スケジューラを変更して、SSD のパフォーマンスを最適化することができます。 一般的な推奨事項は、SSD に対して NOOP スケジューラを使用することですが、iostat などのツールを使用してワークロードのディスク I/O パフォーマンスを監視する必要があります。

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

ネットワーク

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

  • Virtual network。 すべての VM が、複数のサブネットにセグメント化できる仮想ネットワーク内にデプロイされます。

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

  • パブリック IP アドレス。 パブリック IP アドレスは、リモート デスクトップ (RDP) 経由などで VM と通信するために必要です。 パブリック IP アドレスは、動的でも静的でもかまいません。 既定では、動的アドレスになっています。

  • 変化しない固定 IP アドレスが必要な場合 (たとえば、DNS "A" レコードを作成するか、またはセーフ リストに IP アドレスを追加する必要がある場合) は、静的 IP アドレスを予約します。

  • IP アドレスの完全修飾ドメイン名 (FQDN) を作成することもできます。 これにより、その FQDN を参照する DNS で CNAME レコードを登録できます。 詳細については、Azure portal での完全修飾ドメイン名の作成に関する記事をご覧ください。

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

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

操作

SSH。 Linux VM を作成する前に、2048 ビット RSA 公開/秘密キー ペアを生成します。 VM を作成する場合は、公開キー ファイルを使用します。 詳細については、Azure 上の Linux または Mac における SSH の使用方法に関する記事を参照してください。

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

可用性。 VM が計画メンテナンスまたは計画外のダウンタイムの影響を受ける可能性があります。 VM の再起動ログを使用すると、VM の再起動が計画的なメンテナンスによるものかどうかを確認できます。 可用性を高めるには、複数の VM を可用性セット内にデプロイします。 この構成により、より高度なサービス レベル アグリーメント (SLA) が提供されます。

バックアップ。偶発的なデータ損失を防ぐには、geo 冗長ストレージに VM をバックアップする Azure Backup サービスを使用します。 Azure Backup では、アプリケーション整合性バックアップが提供されます。

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

VM の削除。 VM を削除しても VHD は削除されません。 つまり、データを失うことなく安全に VM を削除できます。 ただし、Storage に対して引き続き課金されます。 VHD を削除するには、BLOB ストレージからファイルを削除します。 誤って削除されないようにするために、リソース ロックを使用してリソース グループ全体をロックするか、または個別のリソース (VM など) をロックします。

考慮事項

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

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

使用法やワークロードに応じて、VM サイズにはさまざまなオプションがあります。 この範囲には、Bs シリーズの最も割安なオプションから、機械学習向けに最適化された最新の GPU VM までが含まれます。 使用可能なオプションについては、Azure Linux VM の料金に関するページを参照してください。

完了時間またはリソース消費の時間が予測できないワークロードの場合は、従量課金制オプションを検討してください。

仮想マシンの 1 年または 3 年間での使用をコミットできる場合は、Azure の予約を使用することを検討してください。 VM の予約は、従量課金制の料金と比較してコストを最大 72% 削減できます。

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

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

コストを見積もるには、Azure 料金計算ツールを使用します。

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

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

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

更新プログラムの管理。 有効になっている場合、Defender for Cloud はセキュリティ更新プログラムや緊急更新プログラムが不足しているかどうかをチェックします。

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

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

注意

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

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

データの暗号化。 OS ディスクとデータ ディスクを暗号化する必要がある場合は、Azure Disk Encryption を使用します。

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

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

1 つの Azure Resource Manager テンプレートを使用して、Azure リソースとその依存関係をプロビジョニングします。 すべてのリソースが同じ仮想ネットワークにあり、同じ基本的なワークロードに分離されています。このため、ワークロードの特定のリソースを DevOps チームに関連付けやすく、チームはそのリソースのすべての要素を個別に管理できます。 この分離により、DevOps チームは、継続的インテグレーションと継続的デリバリー (CI/CD) を実行できます。

また、各種 Azure Resource Manager テンプレートを使用して、それを Azure DevOps Services と統合することで、さまざまな環境を数分でプロビジョニングし、必要なときにのみ、たとえば疑似運用シナリオをレプリケートしたりテスト環境を読み込んだりできるため、コストを節約できます。

高可用性アーキテクチャについては、「Apache Cassandra を使用する Azure の Linux N 層アプリケーション」を参照してください。参照アーキテクチャには複数の VM が含まれており、各 VM が可用性セットに含まれています。

Azure Monitor を使用して、インフラストラクチャのパフォーマンスを分析および最適化することを検討してください。仮想マシンにログインせずに、ネットワークの問題を監視および診断できます。

次のステップ