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 の一部が仮想化の管理に回る構造でした。
Nitro カード - I/O を専用ハードウェアにオフロードする
Nitro System の核心は、従来ホスト CPU で処理していたネットワーク、ストレージ、セキュリティの機能を、専用の ASIC (Application-Specific Integrated Circuit) チップにオフロードしたことです。Nitro カードは用途ごとに種類が分かれており、たとえば次のものが使われています。Nitro Card for VPC はネットワーク処理 (VPC のカプセル化、セキュリティグループのフィルタリング、ENA のパケット処理) を担当します。Nitro Card for EBS はブロックストレージの I/O (EBS ボリュームへの読み書き、暗号化 / 復号) を担当します。Nitro Card for Instance Storage はローカル NVMe ストレージの管理を担当します。これらの処理をホスト CPU から切り離したことで、ホスト CPU のリソースの多くをゲスト VM に回せるようになりました。仮想化の管理に使う CPU は、Xen の時代と比べて Nitro System で減りました。この差は、大規模なクラウドインフラではコストに響きます。サーバーの台数が多いほど、CPU の節約はコストの面で積み上がります。
Nitro ハイパーバイザー - 軽量化の極致
Nitro ハイパーバイザーは、KVM (Kernel-based Virtual Machine) をベースにした軽量なハイパーバイザーです。Xen の Dom0 が汎用の Linux カーネルを実行していたのに対し、Nitro ハイパーバイザーは仮想化に必要な最小限の機能だけを持つカスタムカーネルです。ネットワークスタック、ストレージスタック、ファイルシステムなど、従来のハイパーバイザーが持っていた機能は Nitro カードにオフロードされているため、ハイパーバイザー自体の役割は限られています。この軽量化は、セキュリティの観点でも意味を持ちます。コードが少なければ脆弱性も少なく、攻撃対象面が縮小します。AWS は、Nitro System には EC2 のホストにログインしたり、インスタンスのメモリにアクセスしたりする仕組みが無いと説明しています。Xen の Dom0 は、ゲスト VM のメモリにアクセスする権限を持つ特権ドメインでした。この制限は Nitro System 自体に備わっており、AWS の運用者も回避できない設計になっています。
ベアメタルインスタンスの実現 - 仮想化なしの 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 (仮想ソケット) と呼ばれるローカル通信チャネルのみです。この隔離により、親インスタンスのプロセスやユーザーは、root や管理者であっても、Enclave 内のデータとアプリケーションにアクセスできない仕組みになっています。Enclave の整合性は、暗号学的な証明 (Attestation) で検証できます。Enclave の起動時に、Nitro System が Enclave のコードとデータのハッシュ値を含む署名付きの証明書を生成します。外部のサービス (KMS など) は、この証明書を検証してから Enclave にデータを提供できます。ユースケースとしては、個人情報の処理 (PII のトークン化)、暗号鍵の管理、マルチパーティ計算 (複数の組織がデータを共有せずに共同で計算する) などがあります。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。