Nitro System が変えた EC2 の歴史 - Xen から KVM へ、仮想化オーバーヘッドをゼロに近づけた革命
EC2 が Xen ハイパーバイザーから Nitro System に移行した技術的背景、Nitro カード・Nitro ハイパーバイザー・Nitro Enclaves の 3 層構造、ベアメタル並みの性能を実現した設計思想を解説します。
EC2 の最初の 10 年は Xen の時代だった
2006 年に EC2 がローンチされた際、仮想化技術には Xen ハイパーバイザーが採用されました。Xen はケンブリッジ大学で開発されたオープンソースのハイパーバイザーで、当時最も成熟した仮想化技術の一つでした。Xen の準仮想化 (Paravirtualization) モードでは、ゲスト OS のカーネルを修正して Xen と直接通信させることで、完全仮想化よりも高い性能を実現していました。しかし、Xen ベースの EC2 にはいくつかの構造的な問題がありました。第 1 に、ネットワークとストレージの I/O がホスト OS の CPU で処理されるため、I/O 負荷が高いワークロードではホスト CPU がボトルネックになりました。第 2 に、ホスト OS (Dom0) がセキュリティ上の攻撃対象面を広げていました。Dom0 は特権ドメインとしてすべてのゲスト VM のメモリにアクセスできるため、Dom0 が侵害されると全ゲスト VM が危険にさらされます。第 3 に、ハイパーバイザーのオーバーヘッドにより、物理サーバーの CPU の 10〜30% が仮想化の管理に消費されていました。
Nitro カード - I/O を専用ハードウェアにオフロードする
Nitro System の核心は、従来ホスト CPU で処理していたネットワーク、ストレージ、セキュリティの機能を、専用の ASIC (Application-Specific Integrated Circuit) チップにオフロードしたことです。Nitro カードは 3 種類あります。Nitro Card for VPC はネットワーク処理 (VPC のカプセル化、セキュリティグループのフィルタリング、ENA のパケット処理) を担当します。Nitro Card for EBS はブロックストレージの I/O (EBS ボリュームへの読み書き、暗号化・復号) を担当します。Nitro Card for Instance Storage はローカル NVMe ストレージの管理を担当します。これらの処理がホスト CPU から完全に分離されたことで、ホスト CPU のほぼ 100% をゲスト VM に割り当てられるようになりました。Xen 時代には物理サーバーの CPU の 10〜30% が仮想化管理に消費されていたのが、Nitro System ではほぼゼロになったのです。この差は、大規模なクラウドインフラでは莫大なコスト差に直結します。数百万台のサーバーで 10% の CPU を節約できれば、数十万台分のサーバーコストに相当します。
Nitro ハイパーバイザー - 軽量化の極致
Nitro ハイパーバイザーは、KVM (Kernel-based Virtual Machine) をベースにした極めて軽量なハイパーバイザーです。Xen の Dom0 が汎用の Linux カーネルを実行していたのに対し、Nitro ハイパーバイザーは仮想化に必要な最小限の機能だけを持つカスタムカーネルです。ネットワークスタック、ストレージスタック、ファイルシステムなど、従来のハイパーバイザーが持っていた機能はすべて Nitro カードにオフロードされているため、ハイパーバイザー自体のコードベースは極めて小さくなっています。この軽量化は、セキュリティの観点でも大きな意味を持ちます。コードが少なければ脆弱性も少なく、攻撃対象面が縮小します。AWS は Nitro ハイパーバイザーのセキュリティモデルを「ハイパーバイザーからゲスト VM のメモリにアクセスする手段がない」と説明しています。Xen の Dom0 はゲスト VM のメモリに自由にアクセスできましたが、Nitro ハイパーバイザーにはその機能自体が存在しません。これにより、AWS の従業員であってもゲスト VM のデータにアクセスすることが技術的に不可能になっています。
ベアメタルインスタンスの実現 - 仮想化なしの EC2
Nitro System の副産物として生まれたのが、EC2 のベアメタルインスタンス (例: m5.metal) です。Nitro カードがネットワークとストレージの処理を担当するため、ハイパーバイザーを完全に排除しても EC2 の管理機能 (起動・停止、モニタリング、セキュリティグループ) が維持できます。ベアメタルインスタンスでは、物理サーバーの CPU とメモリがそのままゲストに提供され、仮想化のオーバーヘッドは文字通りゼロです。ベアメタルインスタンスが必要なユースケースは限定的ですが、重要な場面があります。第 1 に、ライセンスの制約です。Oracle Database や Windows Server の一部のライセンスは、物理コア数に基づいて課金されるため、仮想化環境では物理コアの特定が困難です。ベアメタルインスタンスなら物理コア数が明確です。第 2 に、ネストされた仮想化です。VMware ESXi や KVM をゲスト OS として実行する場合、ベアメタルインスタンスが必要です。AWS の Elastic VMware Service (EVS) は、ベアメタルインスタンス上で VMware vSphere を実行するサービスです。第 3 に、パフォーマンスクリティカルなワークロードです。HPC (High Performance Computing) や金融のリアルタイムトレーディングでは、仮想化のわずかなオーバーヘッドも許容できない場合があります。
Nitro Enclaves - ハードウェアレベルの機密計算
Nitro Enclaves は、Nitro System の隔離機能を活用した機密計算 (Confidential Computing) 環境です。Enclave は、親インスタンスから CPU とメモリを分離した隔離された仮想マシンで、永続ストレージ、ネットワークアクセス、外部からのインタラクティブアクセスを一切持ちません。親インスタンスとの通信は、vsock (仮想ソケット) と呼ばれるローカル通信チャネルのみです。この極端な隔離により、Enclave 内で処理されるデータは、親インスタンスの OS、ハイパーバイザー、AWS の従業員のいずれからもアクセスできません。Enclave の整合性は、暗号学的な証明 (Attestation) で検証できます。Enclave の起動時に、Nitro System が Enclave のコードとデータのハッシュ値を含む署名付きの証明書を生成します。外部のサービス (KMS など) は、この証明書を検証してから Enclave にデータを提供できます。ユースケースとしては、個人情報の処理 (PII のトークン化)、暗号鍵の管理、マルチパーティ計算 (複数の組織がデータを共有せずに共同で計算する) などがあります。AWS の仮想化技術とセキュリティ設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。