Wasm 標準の進化: コンポーネント モデルの構築

WebAssembly (Wasm) 分野では、ソフトウェア アプリケーションを作成する新しい方法であると考えられるものを含め、いくつかの新しい標準化の取り組みが行われています。この新しいモデルを説明することによって、私たちがどこに向かっているのかを説明する方法として、Wasm の歴史の一部を掘り下げてみたいと思います。

WebAssembly (Wasm) の設計は、2019 年に正式に Web の 4 番目の言語となる数年前の 2015 年に始まりました。多くの技術者はブラウザ テクノロジとして Wasm に精通していますが、Wasm 自体は JavaScript や Web API に依存しません。

Wasm の前身であるasm.js 、2013 年に有名になりました。ブラウザ向けに高度に最適化可能で、C やC++ などの言語のコンパイル ターゲットとして機能する JavaScript のサブセットです。私の最も好きな講演の 1 つである「JavaScript の誕生と死」では、 asm.jsからインスピレーションを得た架空の未来について取り上げています。 PyCon 2014 での彼の講演を見て、Wasm で最終的に切り開く未来と Gary の予測の類似点に注目してください。

私はよく、 asm.js史上最高のハック (最も愛情深い方法で) と呼んでいます。高級スクリプト言語が A")" コンパイル ターゲットであり、B")" 信じられないほど高速であるとは誰が想像したでしょうか? 2012 年に、私はいくつかの C++ ライブラリをasm.jsに移植し、ポータブルな世界への秘密コードのロックを解除したと感じました。

このテクノロジーはいくつかのことを証明しました。まず、他の言語を Web に導入する必要性と要望がありますが、開発者はそこで止まりたくありませんでした。移植されるアプリケーションの種類は、データ視覚化ツール (SAS で取り組んだコンポーネントなど) から、 Unityや Unreal Engine で構築されたゲーム (UE3 は4 日で移植されました) まで、計算とグラフィックスを要求するものでした。

2015 年にW3C WebAssembly コミュニティ グループとそれに対応する WebAssemblyデザイン リポジトリが作成されたとき、Mozilla、 Google 、 Microsoft 、 Appleなどのブラウザ ベンダーがこの取り組みに最初に貢献し、具体的な機会を最初に認識したのはそのためです。この設計では、ポータブルなコンパイル ターゲットとして使用できるバイナリ形式の言語、高速ダウンロードを可能にするサイズの最適化、およびダウンロードされたモジュールのほぼ瞬時のインスタンス化を可能にするストリーミング コンパイルのサポートが必要でした。最も重要なことは、ブラウザで実行される任意のコードと同様に、これらのモジュールはサンドボックス化された [実行環境] を容易にする必要があるということです。

なぜブラウザを超えて Wasm を使用するのでしょうか?

ブラウザ側の展開で学んだことの多くは、Wasm がブラウザを超えてその可能性を発揮できるさまざまな方法への手がかりを与えてくれました。 「クラウド」は、世界規模の機械ネットワークにおけるコンピューティング アーキテクチャ、オペレーティング システム、およびシステム制約の異種セットを構成します。

Wasm の主要なプロパティのいくつかは、コンパクトなバイナリ形式のおかげで高速でサンドボックス化され、簡単に配布できるポータブルなコンパイル ターゲットとして考えてください。 Wasm のこれらの特性により、Wasm はクラウドの完璧な分散可能なコンピューティング単位になります。さらに、企業はさまざまな環境向けにアプリケーションを構築したいと考えていますが、毎回リファクタリングする必要はありません。 Wasm はこれらの障壁を取り除きます。

初めてasm.jsについて知ったとき、私は既存の Flash アプリケーションを HTML5 に移行する方法のソリューションを探していました。この ActionScript/Flex アプリは、C で書かれた同じビジネス ロジックの以前のバージョンを移植した Java 対応アプリを書き直したバージョンです。大企業で働いたことがない人には、この話は突拍子もないように思えるかもしれませんが、次のことがわかります。幸運にも時の試練を生き延びたすべての組織では、コンピューティングの各時代の間でこの種の移植が行われています。

Wasm を使用すると、ブラウザ、FaaS 専用のランタイム、または IoT 用の小さなアーキテクチャで実行するように設計されたランタイムを含む、あらゆる Wasm 準拠のランタイムへの完全な移植性が可能になります。 Web では、Wasm モジュールは JavaScript の「接着」コードを使用して WebGL などの Web API、ネットワーキング、デバイスにアクセスし、純粋な計算を超えた処理を行うことができます。結局のところ、Wasm プログラムは実際には数値でのみ動作します。別の言い方をすれば、Wasm モジュールはトレンチコートを着た i32 の束です。興味深いことを行うためには、Wasm モジュールがホスト ランタイムから関数を呼び出すことができる必要があります。

WASI: サーバーサイドWasmのフロンティア

WebAssembly 1.0 が推奨 Web 標準になったのとほぼ同時期に、WASI (WebAssembly Systems Interface) として知られる WebAssembly のシステム レベル インターフェイスを検討するために、W3C WebAssembly ワーキング グループ内の新しいサブグループが作成されました。それ以来、このグループは標準化されたインターフェイスのセットの作成に取り組んできました。

WASI は、ブラウザ内だけでなく、どこでも WebAssembly を適切に動作させるために存在します。しかし、WASI の重要な特徴は、その機能ベースのセキュリティ モデルです。機能ベースのセキュリティは 60 年代から存在していました ( Dennis & Van Horn、1966 年) が、 Dan Gohman はCloud ABIのアイデアに基づいてこれに対する新しい解釈を構築しました。

当然のことながら、このテクノロジーはすぐに Web の外で Wasm を実行することに興味のある企業の注目を集めました。 Fastly、Intel、Red Hat、Mozilla などの企業は、Wasm をクラウド、デバイス、エッジで動作させる機会を見出しました。これらの企業は、WASI などの標準を使用して Wasm の安全なソフトウェア基盤を構築する非営利組織である Bytecode Alliance (BA) の創設メンバーでした。ソフトウェア業界全体の主要企業を含む他の多くの組織がすぐに BA に参加し、現在メンバーは 30 を超えて成長しています。

ここ数年、私たちはクラウドネイティブアプリケーションで Wasm を実行するために必要なツールの構築に向けて大きな進歩を遂げてきました。コミュニティはこれらの初期の経験から多くのことを学び、これが私たちに影響を与え、現在コンポーネント モデルと呼ばれている新しい標準を作成しました。コンポーネント モデルは WASI よりも低いレベルにあり、WASI とうまく連携しますが、WASI には依存しません。これは、ポータブルなコンピューティング ユニットをベースとするだけでなく、構成可能で相互運用可能でプラットフォーム仮想化可能な WebAssembly モジュールを備えたまったく新しいソフトウェア エコシステムを私たちが構想した結果です。

それを詳しく見てみましょう:

• 構成可能性: 言語に依存しない方法でモジュール化されたコードの再利用が可能になります。

• プラットフォーム仮想化: コンポーネントが特定の環境で実行する必要があるプラットフォーム固有の部分を階層化する機能。プラットフォームの仮想化と構成可能性のための機能の以前の提案は、モジュールリンクと呼ばれていました。

• 相互運用性: 構成可能で仮想化可能なコンポーネントでは、コンポーネント間で情報を交換する方法が必要です。私たちはインターフェイス タイプと呼ばれる提案から始めましたが、これも現在ではコンポーネント モデル提案の重要な機能です。

  
  

これは、コンポーネント モデルがどのように形になり始めたかの物語です。以前の提案はそれぞれ、この包括的な標準に洗練されました。今年後半には、WASI 標準とコンポーネント モデルの次の主要な安定したバージョンが公開される予定です。

WASI 規格 - 私たちは今どこにいますか?

以下では、Wasm、WASI、およびコンポーネント モデルの開発の歴史を概略的に説明します。

2019 : 純粋なコンパイル ターゲット。syscall をホストに接続する初期インターフェイスを追加します。多くの点で、私たちは POSIX の WebAssembly バージョンに向かっているように見えました。非常に単純な CLI を作成し、デスクトップまたはサーバーレス関数で Wasmtime を使用して実行することができました。

2020 : WASI API は、システム クロックやファイル システムなど、CLI プログラムに必要な種類のものに焦点を当てています。 Fastly の Lucet Wasm ランタイムは Wasmtime (BA プロジェクト) と統合されました。

2021 : もちろん、これらすべての要素は進化し、改善され続けます。 2021 年には、新しいユースケース固有の WASI インターフェイス、たとえば、推論にハードウェア アクセラレーションが必要な場合のwasi-nnの開発が見られ始めます。また、この年は、 Luke Wagner がコンポーネント モデルの定義を開始した年でもあります。

2022 : Key-Value ストアやパブリッシュ/サブスクライブ メッセージング サービスの操作などの機能が必要なクラウド環境で Wasm モジュールを適切に実行できるようにするための、新しい高レベル API が登場し始めます。多くの作業を経て、ついに WASI ソケットが導入されました。 2023 : コンポーネント モデルと WASI 標準の安定性マイルストーンに向けて取り組んでいます。

2019 年からの歩みを見ると、ユースケースが急増し、ユーザーが必要なものと不要なものを選択し始めるにつれて、標準がどのように多様化したかがわかります。ユビキタスな 1 つのブロックから、柔軟なフレームワーク (コンポーネント モデル) 内で相互に動作するように設計された、成長を続ける小さなビルディング ブロックのスイートまで。

コンポーネントモデルとは何ですか?

このモデルでは、開発者は、さまざまな言語で実装されたアプリケーションの一部をさまざまな価値提案として選択できます。開発者が Wasm コンポーネント ライブラリの作成を開始すると、他の開発者はそれらを世界最大の「LEGO」箱として扱うことができます。

一周して、コンポーネント モデルが Web アプリケーションの作成方法に影響を与え始めると、新しいイノベーションが起こると私たちは信じています。 Web が非常にせっかちなユーザーを抱えるクールだが制約のある環境の 1 つであり、新たな実験の温床であることを考えると、これは当然のことです。

たとえば、コンポーネントによって、Web アプリケーション用の言語に依存しないプラグイン システムの設計がさらに容易になると私は期待しています。 Python などの言語ランタイムに必要な部分がある場合は、その言語ランタイムを利用する複数のコンポーネントでそれを使用できます。これを今日の世界と比較してください。そこでは Wasm モジュール (コンポーネントではありません) のみが存在し、これらは通常、コンパイル時のすべての依存関係が単一のバイナリに組み込まれて構築されます。大規模なアプリケーションがサードパーティのプラグインをサポートする場合、おそらく各 Wasm プラグインに重複した依存関係があり、サイズとメモリの肥大化とダウンロードの遅延につながります。

Web 用の Wasm コンポーネントの将来のシステムでは、単一のアプリケーションが任意の言語で記述されたコンポーネントを選択できるようになり、アプリケーションは必要なものを正確にダウンロードし、インポートを使用して他の ES モジュールと同様にコンポーネントと対話するだけで済みます。この世界では、最高のコンポーネントが頂点に上り詰めます。最高とは、最も高速な API または最もクリーンな API を意味しますが、最も重要なのは、その定義的な特徴はソース言語ではないということです。最高のコンポーネントが勝ちますように!

WASI とコンポーネントの安定した技術基盤の構築

WASI 標準とコンポーネント モデルを実現する上で大きな部分を占めるのは、使用可能な技術フレームワーク (SDK、ツール、コア コンポーネント) を作成する際に BA が果たす役割です。これらはすべて一貫した安全な方法で構築されており、ベスト プラクティスの例として誰でもアクセスできます。

同様に、BA の技術運営委員会 (TSC) の役割は、すべての BA プロジェクトに技術的なガバナンスとサポートを提供する上で重要になります。私たちは、W3C WebAssembly および WASI ワーキング グループで可能な限り最良の標準セットを設計している人々と協力して作業しています。つまり、すべてが実際に機能することを確認するために彼らと協力していることを意味します。 W3C WebAssembly および WASI グループはこれらの標準の最終決定に重点を置いており、BA はこれらの標準をコミュニティ内でできるだけ早く利用できるようにして、アクティブなフィードバック ループを確立することに重点を置いています。

BA の憲章のもう 1 つの重要な部分は、言語と環境の相互運用性を可能にすることです。 BA は、さまざまな言語の言語バインディングを生成するためのツールを提供しますが、言語の相互運用性を極度に高める方法の 1 つは、Wasm コンポーネントと相互運用するために、さまざまな言語エコシステムのレジストリとパッケージ マネージャーが必要であるということです。そのため、私たちはSIG-Registriesの一部としてレジストリ プロトコル (warg と呼ばれる) の設計に取り組んでいます。これにより、プロトコルを実装するレジストリが Wasm コンポーネントを公開、消費、保存、共有できるようになります。

おそらく、Wasm ソフトウェア スタックの中で最も重要な部分は Wasm ランタイムであり、BA は 2 つをホストします。 Wasmtime は Rust で書かれており、多くの場合、新しい WASI および WebAssembly 提案を実験するためのテストベッドとなります。 WebAssembly Micro-Runtime ( WAMR ) は C で書かれており、ESP32 のような小規模なアーキテクチャを含む多くのアーキテクチャをサポートしています。これらのランタイムは両方とも、Wasm ランタイムの優れたリファレンス実装として機能します。 Wasm モジュールを構築するための SDK とツールは Wasm 標準に準拠しているため、標準に準拠したあらゆる Wasm ランタイム (BA によってホストされていないものを含む) をこれらのソフトウェア基盤上に構築できます。

WASI、コンポーネント モデル、および Bytecode Alliance の実装を通じて進化する新しくエキサイティングな標準をすべて考慮すると、2023 年はエキサイティングな年になると予想しています。

今すぐ無料で Cosmonic を始めましょう:今すぐ起動してください!

ベイリー・ヘイズ著 | Bytecode Alliance TSC および Cosmonic のディレクター