Microsoftはオープンソースプロジェクトである「Hyperlight」と「Nanvix」を統合した次世代軽量VM技術の取り組みを公式ブログで解説した。数十ミリ秒の高速起動と安全な隔離を両立する環境にPOSIX互換性を追加し、既存アプリを改修なしで実行可能にするという。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Microsoftは2026年1月28日(米国時間)、オープンソースプロジェクトである軽量VMM(仮想マシンモニター)「Hyperlight」とマイクロカーネル「Nanvix」を組み合わせ、クラウドにおけるサーバレスインフラの「トリレンマ」を解消するための取り組みについて公式ブログで解説した。
クラウドアーキテクトは長年、サーバレスインフラの構築において、根本的なトレードオフに直面してきた。それは「高速なコールドスタート」「安全な隔離」「ランタイムの互換性」という3つの要素のうち、同時に満たせるのは2つだけであり、全てを満たすことはできないという課題だ。
コンテナやWebAssemblyサンドボックスは、セキュリティ隔離よりも起動速度を優先している。ただし、ハードウェアレベルの境界ではなく、ソフトウェアによる論理的な保護境界に依存する。ソフトウェアによる保護境界は、カーネルやランタイムに脆弱(ぜいじゃく)性があると、隔離領域を突破されるリスクがある。これに対し、ハードウェア境界は不変(イミュータブル)であり、プロセッサレベルで厳格にセキュリティが確保される。
従来の仮想マシン(VM)はハイパーバイザーによる隔離を提供する。ただし、OS全体の起動が必要なため、コールドスタートには数百ミリ秒を要する。
既存のアプリケーションを実行するには、通常、システムコールやファイルシステム、標準ライブラリを利用できる完全なPOSIX(Portable Operating System Interface for UNIX)環境が必要だ。だが、軽量のベアメタルマイクロVMは、POSIX環境を提供しない。
CNCF(Cloud Native Computing Foundation)のプロジェクトとして開発されているHyperlightは、OSを完全に排除することで、ハードウェア隔離と極めて高速なコールドスタートを実現し、より高速で安全かつ軽量のワークロード実行環境をクラウドネイティブエコシステムに提供する。だが、Hyperlightのゲスト環境ではシステムコールを利用できないため、アプリケーションは、そのベアメタル環境専用に記述する必要がある。つまり、Hyperlightはランタイムの互換性に課題があった。
この課題を解消するためのアプローチが、HyperlightとNanvixの統合だ。Microsoft Researchが開発したRustベースのマイクロカーネルであるNanvixは、Hyperlightと連携して動作するように設計されており、以下の特徴を持つ。
HyperlightとNanvixの統合により、ハイパーバイザーレベルの隔離を維持し、数十ミリ秒でのコールドスタートを実現しながら、HyperlightマイクロVM内でファイルシステム、システムコール、言語ランタイムを用いて既存のアプリケーションを実行できるようになるという。
HyperlightとNanvixは、役割を分担してトリレンマに対処する。Hyperlightは信頼されたホストの代理として、ゲストVMができることを全て制御し、ハードウェアによる隔離を提供する。Nanvixの最適化されたマイクロカーネルは、Hyperlightゲスト内で動作し、アプリケーションが期待するPOSIXシステムコールとファイルシステムインタフェースを提供する。
HyperlightとNanvixの統合における核心は、「分割OS設計」(split OS design)にある。これは、VM内でモノリシックなOSを実行するのではなく、コンポーネントを以下の2つのグループに分け、それぞれに役割(責任)を分割する。
ハードウェアによる隔離を必要とするアプリケーションコード、ランタイム、POSIX互換レイヤー、Nanvixカーネル。信頼できないコードやテナント固有のコードを実行するものは、全てHyperlight VM内で動作する。
ホストシステムで管理されるI/O(Input/Output)、ネットワーク、共有状態。Hyperlightがゲストとこれらのサービスの間のやりとりを仲介する。
この分割アーキテクチャにより、アプリケーションからは一般的なPOSIX環境が見える一方で、I/O操作はホストが処理し、高密度、高速コールドスタート、呼び出し間での必要に応じた状態共有が実現される。
HyperlightとNanvixの統合による強力な機能の一つとして、システムコール介入がある。ゲストアプリケーションがシステムコール(ファイルを開くopenatのような)を発行すると、そのリクエストはNanvixを経由し、Hyperlightのメカニズムを介してVMの境界を越え、ホストに送られる。ホストはこの境界で以下のように制御できる。
これにより、ゲストアプリケーションに変更を加えることなく、例えば、「ファイルの読み取りは許可するが、ネットワークアクセスはブロックする」といった詳細な制御がシステムコールレベルで可能になる。
HyperlightとNanvixの統合は、脅威モデルに応じて以下の3つのデプロイ(展開)アーキテクチャをサポートしている。
VMMとI/Oサブシステムを単一のホストプロセスで実行する。高速かつシンプルであり、信頼できない小規模なワークロードをハードウェアで隔離して実行するのに適している。
ホストOSで動作するI/OスレッドとVMMスレッド(単一ホストプロセスを形成)が、Hyperlight VM(アプリケーションとNanvixカーネルを含む)と共に、ハイパーバイザーレイヤー上で動作する(提供:Microsoft)VMMとI/O処理を別々のプロセスに分離する。脆弱性の悪用によって攻撃者がVMの境界を越えても、I/Oリソースへの直接アクセスを防ぎ、被害範囲を限定する。同一テナントの複数同時インスタンス間でシステムI/Oプロセスを共有することもできる。
ホストOS上で動作するシステムI/OプロセスとHyperlight VMMプロセスおよびHyperlight VM(アプリケーションとNanvixカーネルを含む)が、全てハイパーバイザーレイヤー上で動作する(提供:Microsoft)ホストハイパーバイザー上で2つの独立したVMを実行する(「Hyper-V」または「KVM」〈Kernel-based Virtual Machine〉を使用)。システムVMは全てのI/Oシステムコールを処理し、複数のHyperlight VMの共有バックエンドとして機能する。Hyperlight VMはI/Oリクエストをハイパーバイザー境界を越えてシステムVMに転送し、複数のハイパーバイザー境界による多層防御を実現する。
システムVMMプロセスとHyperlight VMMプロセスがホストOS上で動作し、2つの独立したVMがハイパーバイザーレイヤー上で動作。左がI/O操作を処理するシステムVM、右がHyperlight VM(アプリケーションとNanvixカーネルを含む)(提供:Microsoft)実アプリケーションを使って、HyperlightとNanvixの組み合わせを他の隔離技術と比較する初期ベンチマークテストを実施したところ、有望な結果が得られたという。
HyperlightとNanvixの統合によってPOSIX互換レイヤーが提供される。これにより、あらゆる言語のアプリケーションを実行できる。
AI(人工知能)コーディングの普及が進む中、インフラを危険にさらすことなく、AI生成コードを実行できる安全な環境が必要となっている。AIが生成したコードは信頼できないコードとして扱うべきだが、HyperlightとNanvixを利用することで、以下が可能になる。
AI生成コードに、言語ランタイムを標的とした攻撃コードが含まれていても、攻撃者は、ハードウェアによる隔離の壁に阻まれることになるとしている。
AWS Lambdaでチェックポイントや最長1年間無料で待機できる機能、EC2インスタンスを選んだ関数実行も
世界で急成長して市場規模190億ドルの「サーバレス」、その位置付けはどう変わったのか? Omdia調査レポート
マイクロサービスをサーバレスで構築するのが適しているケースとは?Copyright © ITmedia, Inc. All Rights Reserved.