KubeCon Europe 2025、CosmonicとMicrosoftによるWASMの事例解説セッションを紹介

KubeCon＋CloudNativeCon Europe 2025から、WebAssemblyの概要と事例紹介、そしてコントリビュータに助けを求めたセッションを紹介する。プレゼンテーションを行ったのはCosmonicのTylor Thomas氏とMicrosoftのDavid Justice氏だ。それぞれWasm Working GroupのCo-chairとして登壇した。

コンビでセッションを行うお馴染みの野球帽姿のThomas氏（左）とJustice氏（右）

セッションは以下の公式URLから可能となっている。

●動画：Wasm I Right or Wasm I Wrong? a Review of the Wasm Ecosystem

最初にThomas氏がWebAssemblyの歴史を簡単に振り返り、Mozillaのエンジニアによってasm.jsと言う名称で2014年にドラフトが作成されたことを説明。その後、W3Cのドラフトとして2018年にコアとなる仕様が作成され提案されたこと、2019年にW3Cのリコメンデーションとしての仕様が作成されたことを説明した。

asm.jsからWebAssemblyに至る簡単な歴史を振り返る

そしてブラウザーで稼働するプラットフォームを選ばない実行形式からクラウド、つまりサーバー側で実行される互換性が高く安全な実行形式に進化したことを、それぞれブラウザーとサーバー側の特徴を比較して説明した。ここではほぼ同じ特徴を持っていることが強調された形になっている。

ブラウザーのWebAssemblyとサーバーやエッジで動くWebAssemblyの共通点を解説

ここでは高い互換性、ファイルサイズが小さく高速、サンドボックスによって安全であること、複数のプログラミング言語から生成可能であることなどが挙げられている。

コンポーネントモデルを紹介

WebAssemblyのコンポーネントモデルは2024年にWASI（WebAssembly System Interface）の一部として公開された、複数のWebAssemblyで書かれたモジュールのインターフェースを統一するための仕組みだ。

複数のWasmモジュールのインターフェースを定めたコンポーネントモデル

これによって異なるプログラミング言語で書かれたモジュールを連携させることが容易になる。この例ではRustで書かれたファイルとGoで書かれたファイル同士で、データの交換や関数の呼び出しが可能になる。

コンポーネントモデルの記述例を見せて解説

具体的なプログラムコードを見せてインポートとエクスポートの例を解説。ここではコアな機能に加えて、ロギングや外部プログラムの実行が例として挙げられている。

WASIの進化を時系列で解説。2024年に始まったWASIは2026年に安定版として公開予定

ここからはWebAssemblyに関連したソフトウェアを列挙して説明する内容となった。

最初に挙げたのはMicrosoftのOBが起業したFermyonのSpin

このスライドで解説されているSpinは、WebAssemblyの特徴を活かしたサーバーレスのアプリを実行するためのプラットフォームだ。興味深いのはCosmonicもwasmCloudというプラットフォームを提供しているベンチャーだが、wasmCloudはジェネリックなPaaS的な立ち位置、Spinはよりサーバーレスに特化したプラットフォームということで競合しないという発想だろうか。

●Spin：https://www.fermyon.com/spin

Renderletのサイトを紹介

次に紹介されたのは、3Dグラフィックスを素早く生成するためのツールRenderletだ。デスクトップ（WindowsやmacOS）での3Dモデルを生成するためのツールだが、ブラウザーの部分にWebAssemblyが使われているようだ。具体的にはWanderという名称のWebAssemblyで書かれたレンダリングモジュールが存在している。

●Renderlet：https://www.renderlet.com/

次に紹介されたのはZedというエディターだ。

エディターを拡張する部分にWebAssemblyを使っているZed

ZedはRustで書かれたエディターとして公開されている。その拡張の部分がコンポーネントモデルということになる。

KubernetesのスケジューラーをWASMで実装するフレームワーク

次に紹介されたのはKube-scheduler-wasm-extensionと呼ばれるプロジェクトで、KubernetesのSIGで議論され開発されているという。これはeBPFがLinuxのカーネルで実行したいモジュールを安全に組み込むために利用されていることと同様の発想だ。本来、Kubernetesに独自のスケジューリングアルゴリズムを組み込むためには、Goでアルゴリズムを開発し、スケジューラーをビルドすることで組み込む必要があるが、アルゴリズムをWebAssemblyで実装し外部のモジュールとして組み込むことで、スケジューラーをビルドする手間をなくすという発想だ。

詳細は以下のスケジューラーのSIGのGitHubページを参照して欲しい。

●WASMベースのスケジューラー：https://github.com/kubernetes-sigs/kube-scheduler-wasm-extension

AzureのRustライブラリーHyperlightの紹介

事例の最初にFermyonのSpinがWebAssemblyの利用例として紹介されたが、HyperlightはMicrosoftのパブリッククラウドであるAzureチームが開発し、CNCFにサンドボックスとして寄贈したプロジェクトになる。Spinも2024年3月にサンドボックスとして寄贈されているのでほぼ競合するソフトウェアということになる。

GoogleのService Extensionもプラグインの部分はWebAssemblyで実装

GoogleもGoogle Cloudのサービスを拡張する機能の部分をWebAssemblyで実装している。

Inspektor GadgetもeBPFとWasmで拡張可能なデータ検証用のツール

Inspektor GadgetはKubernetesクラスターの監視のためのデータ収集ツールとして開発され、これもCNCFのサンドボックスとして採用されている。Inspektor Gadgetは検証のためのプログラムをeBPFで開発し、OCIの形でパッケージ化し利用するというもので、その中にWasmのレイヤーを実装可能ということになる。

次はNGINXのUnitだ。Unitのバージョン1.34.2ではWebAssemblyのランタイム、wasmtimeを使ってアプリケーションを実装できると説明されている。

NGINXの軽量なアプリケーションサーバーUnitでもWebAssemblyが実行可能

●nginx unit：https://unit.nginx.org/

次に紹介されたのはKubernetesのポリシーエンジンであるKubewardenだ。セキュリティの観点からKubernetes上で実行されるアプリケーションの行いを制御するAdmission Controlの実装例としてKeyvernoやOPAなどが知られているが、KubewardenもポリシーエンジンとしてRANCHERを手掛けるSUSEによって開発され公開されている。これもCNCFのサンドボックスプロジェクトだ。

WebAssemblyでポリシーを実装するKubernetesのポリシーエンジン、Kubewarden

ここまでWebAssemblyが広く採用されていることを紹介したが、プラグインという発想で機能を拡張するということはセキュリティの意味からは危険であり、コンポーネントモデルによって権限を制限したうえで安全に実行する形式に変わって欲しいと訴えた。

コンポーネントモデルで危険なプラグインモデルを終わらせたい

ここで例として挙げられているBuildpackは、Herokuによるコンテナイメージ生成ツールである。PaaSの実行形式として公開され、Dockerを使わずにコンテナイメージを生成できることが主な利点として紹介されている。

Buildpackについては以下の公式サイトを参照されたい。

●参考：https://buildpacks.io/

ここではデベロッパーがコンテナイメージ生成のために面倒なDockerfileを作成しなくても、適切な依存関係を理解してイメージを生成できるという開発現場のユーザー体験を再現したいという意味が込められていると思われる。

マンダロリアンのセリフを使ってGoのコンポーネントモデルを実装するエンジニアを募集

最後にGo言語からコンポーネントモデルをサポートするランタイムが必要であり、その開発に協力してくれるエンジニアを募っていることを強く訴えてセッションを終えた。このスライドではStar Warsのマンダロリアンの決めセリフ「This is the way」を使って「Go言語でもコンポーネントモデルサポートが存在するべきだ」という意味を伝えようとしていた。

Go言語でコンポーネントモデルを実装して欲しいと強く訴えた

このセッションの本当の目的はGoのコンポーネントモデル開発のエンジニア募集ではなかったかと思わせる切実な声で、他のWebAssembly関連のセッションでも最後の部分では同じ訴求内容となっていたことからも、Go言語のコンポーネントモデルサポートを実装するエンジニアが足りていないことを感じさせる内容となった。