Hyperlight WASM: 高速で、安全、そしてOS不要

 (opensource.microsoft.com)
9 ポイント 投稿者 GN⁺ 2025-04-09 | 2件のコメント | WhatsAppで共有
  • Hyperlight Wasmは、MicrosoftがCNCFに寄贈した**超軽量仮想マシン(VM)**技術 Hyperlight の最新拡張版で、**WebAssembly(Component Model ベース)**ワークロードを高速かつ安全に実行する
  • 従来のVMと異なり、OSや仮想デバイスなしでメモリスライスとCPUのみを公開し、1〜2msの高速な起動時間を実現
  • さまざまな言語(C、Rust、Go、Python、JS など)で書かれた wasm コンポーネントをハイパーバイザー保護下で実行可能

Hyperlight Wasmの主な特徴

  • 従来のVMより高速な性能

    • 従来のVM: デバイス初期化 → カーネル読み込み → OS起動 → アプリケーション実行 (約125ms)
    • Hyperlight Wasm: メモリスライスの作成 + Wasm のロードだけで実行可能 (1〜2ms、将来的には <1ms を目標)
    • 高速な実行速度はオンデマンドのサーバーレス実行や最小限の warm pool 構成に有利

  • OSなしでも多様な言語を実行可能

    • 標準である WASI と WebAssembly Component Model を基盤として、ほとんどの言語で書かれたコンポーネントを実行可能
    • wasmtime ランタイムを内蔵し、Python、JavaScript、C# などインタープリタ言語もランタイム同梱の形で実行可能
    • 開発者は単に wasm32-wasip2 ターゲット向けにコンパイルするだけで Hyperlight 上で実行可能

  • セキュリティ向上 (二重サンドボックス)

    • Wasm サンドボックス + ハイパーバイザー基盤のVMサンドボックスによる二重保護構造
    • 攻撃者が wasm から脱出しても、さらに VM サンドボックスを迂回する必要がある

開発例: Rust ベースの UDP Echo サーバー実行

  • wkg CLI で wasm バイナリをダウンロードしてコンパイル
  • WASI インターフェース定義ファイル(.wit)をバイナリに変換してバインディングを生成
  • hyperlight_component_macro と host_bindgen! を通じてWasm の import/export インターフェースのバインディングを自動生成
  • UdpSocket インターフェースの実装を通じて echo サーバーのロジックを定義
  • hyperlight-wasm サンドボックスを作成して wasm コンポーネントをロードおよび実行

  • Ahead-of-Time コンパイル

    • hyperlight-wasm-aot ツールを使って wasm を AOT コンパイルし、実行時間を短縮
    • cargo run でサーバーを実行し、nc -u コマンドで UDP テスト可能

拡張性と今後の計画

  • Hyperlight Wasmはx86だけでなく Arm64 アーキテクチャにも対応予定
  • 現在は WASI インターフェースを直接実装する必要があるが、今後は基本バインディングを提供予定
  • HTTP サーバーなどのシンプルなサービスを素早くサンドボックス化できるようにする計画

オープンソースコミュニティ参加案内

  • Hyperlight はApache 2.0 ライセンスで公開された Microsoft のオープンソースプロジェクトで、CNCF Sandbox に登録されている
  • Hyperlight Wasmはクラウドネイティブコンピューティングに適した高速で安全な実行環境の提供を目標としている
  • GitHub リポジトリを通じてコードの確認および貢献が可能

👉 GitHub リポジトリ: hyperlight-wasm

関連記事

2件のコメント

 
GN⁺ 2025-04-09
Hacker Newsの意見

  • 数か月前からWebAssemblyを本格的に使って、複数の言語で動作するバックエンド認証ライブラリを作り始めた

    • Extismをベースにしてインターフェースの複雑さを減らした
    • 魔法のような体験だった
    • WASMは興味深い立ち位置にある
    • 最小限のコア仕様で価値を証明した
    • 今ではWASIとComponent Modelのために、より大きなAPI表面を実装しようという大きな後押しがある
    • コミュニティの多くの人がこの方向性を懸念している
    • 個人的には、WASMが複雑になりすぎて、大手テック企業しか実装や実験ができないWebブラウザの道をたどらないでほしい

  • 数か月前にHyperlightという軽量VMMを発表した

    • 約1ミリ秒で新しいVMを生成できる
    • 今日、WasmtimeランタイムをベースにしたHyperlight Wasmゲストを発表できてうれしい
    • VMのゲストOSなしで、WASIインターフェース上でWasm Componentバイナリを実行できるようになった
    • この投稿では、その仕組みを説明し、例を交えて紹介している

  • とても期待している

    • WASM/WASIが90年代のJVMの夢のような存在へと成長してほしい
    • 複数のプラットフォームへ簡単に移植してテストできる、メモリ安全な開発ターゲットになり得る
    • WASMがブラウザ以外の多くの用途にも使われるようになってほしい

  • 面白そう

    • WASMでCloudflare WorkersやLambdaのようなものを自分で実装したいときに使えるユースケースなのか？

  • すばらしい

    • ここで付加される価値が何なのか理解しようとしている
    • wasmtime経由で実行するのとどう違うのか？

  • すべてのクールで興味深いプロジェクトを見ると、WASMはブラウザ以外のあらゆる場所で成功しているように思える

    • Web AssemblyからWebを外して別の名前を付けるべきかもしれない

  • これをPromoxのセットアップにどう組み込めるか、何かアイデアはある？

    • これはベアメタルで動作するよう設計されていると理解している
    • 予備のベアメタルx86がないので少し気まずい
    • 単にVMに入れてネストされた仮想化を受け入れるしかない気がする

  • インスタンスはどのように起動され、管理されるのか？

    • どのAPIを通じて行うのか？
    • Wasm ComponentバイナリにつながったWasm Componentsのツリーを実行し、機能を委譲し、ライフサイクルを管理できるような機能を提供できるのか？

  • 基本的には、ハードウェアVM内でプログラムをサンドボックス化するためのVM（wasm）があり、これはユーザー空間プロセス（Linuxプロセス）内でプログラムを分離するための抽象化だということか

    • プログラムを分離するためにUnixプロセスを使うことについて考えたことはあるか？

  • ユニカーネル／ライブラリOSなのか？