Closed2023/12/13にクローズ15

WASM Component Model

WebAssembly

wasi

乳牛

Component Modelに興味があるけど何者かもわからない

まずはComponent Modelの仕様策定をしているGitHubリポジトリのREADMEを読む

乳牛

WASM Component Modelが何を目指しているかはHigh Level Goalsを理解するのが良さそう。

超意訳してみました（以下）。しかしいまいち理解できない。

Component Modelが目指すゴール

"ポータブル"なバイナリフォーマットを定義
- 個別のWASMのコアモジュールから作られる => 言語を超えた移植性のあるコンポーネント
- ロードとランタイムのための効率的なフォーマットである
上記"ポータブル"の定義をサポートする
- 仮想化可能
- 静的解析可能
- ケイパビリティセーフ（WASMのコアコンセプトの一つ）
- 言語にとらわれないインターフェース（特にWASIによって定義されているもの）
WASM独自の価値提案を維持・強化する
- 言語中立性：特定の言語に依らない
- 埋め込み：様々なホスト実行環境に埋め込み可能（ブラウザ、サーバーサイド、小さな端末など）
- 最適化：早い起動。AoTコンパイラの静的解析情報を最大限利用。
- 形式的セマンティクス：コアWASMと同じセマンティックフレームワークでコンポーネントモデルを定義する。
- WEBプラットフォームとの統合：ブラウザでのネイティブサポート。既存のJS-API, WEB-API, ESM Integrationの延長線上の技術
段階的な定義：初期想定のユースケースからはじめて、フィードバックによる優先順をつけながら徐々に広げていく

ゴールとはしないこと

WASM埋め込みシナリオを100%カバーするものではない
- 上記に掲げたゴールと矛盾するようなシナリオもあるだろう => そういうのはスコープに入れない
ツールチェーンやプラットフォームなど上位レイヤーで解決できることは範囲外
- パッケージ管理、バージョン管理
- デプロイメント、ライブアップグレード、動的再構成
- 永続化保存
- 分散コンピューティングにおける部分的失敗
"コンポーネントサービス"のセットを指定しない
- ホスト実行環境によって実装されるべきことはWASI側の範囲

WASIとの関係性

WASIはコンポーネントモデルの上に位置付けられている。コンポーネントモデルはWASIのインターフェースを定義するために使われているから。

型定義をする文法（witのことだろう）
WASIの各インターフェースは分離され、別個のモジュールとして扱われ、リンクされる
コンパイルするときWASMのツールチェーンがWASIをターゲットにできる（いまいち何言ってるのかわからん）

従来のOSを引き合いに出すと、

コンポーネントモデルはOSのプロセスモデルみたいな役割
- プロセスがどの様に立ち上がり、お互いにどう通信するかを定義するという意味で
対してWASIはOSのI/Oインターフェースの役割

しかし、WASIを使う＝クライアントがコンポーネントモデルをターゲットにすることを強制されるわけではない。コアWASMのプロデューサーは単にコンポーネントモデルによって定義されたコアWASMのABIをターゲットにすることができる。

乳牛

コンポーネントモデルはOSのプロセスモデルみたいな役割

もう少し深掘りするためにこの記事から引用してみる。

（記事の著者はspinというwasmを利用したフレームワークとサービスを提供するFermyonという会社）

A Native Code Analogy

コンポーネントモデルはネイティブ（LinuxやWindows）における従来の考え方と良く似ているらしい。

executable
processes
shared library

Component <-> Executable

コンポーネントは実行可能ファイル（*.exeとか）に似ている。

Module <-> Shared Library

モジュールは*.soや.dllなどの共有ライブラリに似ている。
（他のコードからのリンク、シンボルのエクスポート/インポート）

Component Instance <-> Process

コンポーネントのインスタンスはプロセスに似ている。

コンポーネントがロードされて実行中
ステートフルで動的
親子プロセスツリーのように複数のコンポーネントインスタンスをオーガナイズできる（マジ？）
複数のコンポーネントインスタンスはお互いにメモリやリソースを共有しない

※ソケットやパイプを使ったプロセス間通信があるように、コンポーネントインスタンス間通信も将来的に考えられてそうな書き方（後述）

Module Instance <-> Loaded Shared Library

モジュールインスタンスはプロセスにリンクされてロードされた状態の共有ライブラリのようなもの。

Wasm Runtime <-> Operating System

WASMランタイムはOSみたいなもの。

コンポーネントをインスタンス化して起動する
コンポーネントのロードとリンク
コンポーネント間通信の仲介

WASMランタイムが提供するコンポーネント間通信はインターフェースタイプと標準ABIに基づく単一の高レベル通信方法。
（パイプ、stdin/stdoutなどとは全然考え方が違うものらしい）

乳牛

意外なところにComponentとModuleの違いが定義されていたので意訳

Component

静的解析可能、機能的に安全、言語非依存なインターフェースを持つ
WASMコアモジュールから作られるポータブルなバイナリ
コンポーネントパッケージはその内容がComponentであるパッケージのタイプ（どういう意味？？）
- Registoryの文脈だと以下の３つのパッケージタイプが想定されていてその一つ、という意味っぽい
  1. Component
  2. WIT
  3. Library
Moduleと違って、
- インターフェース定義（コアWASMのi32を超えた）をサポートする
- Componentは、低レベルの状態をカプセル化し、言語に依存しない方法でインターフェースを自己記述するマイクロサービスのようなもの

Module

WASMコアモジュールのことでWASM1.0と互換がある
ネイティブシステムの .dll のようなもので共有メモリへのポインタの低レベルの共有を可能にしますが、分離を提供せず、再利用のための追加の情報が必要です

Component

A component is defined by the (emerging) W3C WebAssembly Component Model specification which defines a component as a portable
binary built from WebAssembly core modules with statically-analyzable, capability-safe, language-agnostic interfaces.

A component package is a type of package whose contents are a component.

Module

A common question is "What is the difference between a component and a module?". A Wasm module is a core Wasm module and compatible with Wasm 1.0 whereas a component adheres to
the evolving Component Model specification with support for interfaces definitions (beyond i32's in core Wasm). Modules are like .dlls in native systems, allowing low-level
sharing of pointers to a shared memory but not providing isolation and requiring additional out-of-band information to reuse. Components are more like microservices that
supply an OpenAPI: they encapsulate their low-level state and self-describe their interface in a language-agnostic manner. In the context of the registry, module packages are
useful for factoring low-level runtime code out of components that would otherwise be statically duplicated.

乳牛

リファレンス、資料まとめ

Component Modelの知識体系を知るのにあちこちに散った資料を読まないと全体像がわからん・・・

という悩みに対してまずはこの資料から入るのが良さそう。

乳牛

Component Modelが何をめざしているか

Cargo.toml の書き方とか

https://github.com/bytecodealliance/cargo-component/blob/main/docs/design/registries.md

乳牛

WASI関連が議論されているzulipチャンネル

https://bytecodealliance.zulipchat.com/#narrow/stream/219900-wasi

乳牛

こんなまとまった資料がbytecode allianceから公開されていたなんて…
網羅的な資料で一番最初に読むべきかもしれない。

乳牛

すごい良さげなチュートリアルが入っていた。

乳牛

cargo-component

cargo-componentはRustのパッケージ管理ツールであるcargoのサブコマンドとしてWASM Componentモデルを取り扱えるようにしたい、というモチベーションのものです。

いくつか機能があるのでここで紹介します。

乳牛

WITファイルの定義からのバインディング生成

下記のようなWITの定義があったとしましょう。

このWITが示すのは newgyu:comp1 というパッケージの random-generatorと名付けられたworldの定義で、

当該のworldはrandという i32を返すファンクションがexportしている
randはseed型の構造体を引数に取るので、そのSeed型の定義を含む

というものです。

依存する型をWITを元に生成

このコンポーネントを作る側としては「rand関数を実装したい」わけですが、rand関数が必要とするSeed型の生成をcargo_component_bindings::generate!() というマクロが助けてくれます。

上記の実装例では下記はbindings::generate!()を実行することにより、

Seedというstruct
Algorithmというenum

が暗黙に生成されており、それを利用するだけのコードになっています。

exportする関数を実装するためのtraitを生成

world random-generatorが実装すべきrand関数については RandomGenerator traitとしてbindingが生成され、そのtraitの未実装rand関数を実装するという形になります。

impl RandomGenerator for Component {
    fn rand(seed: Seed) -> u32 {
        //この関数を実装する
    }
}

自動生成されるバインディングコードの中身を確認してみる

cargo-expandを使用することで確認できます。

全文載せるのも膨大になるのでGistを見ていただくとして、大まかには

まず件のtraitが生成されます。

pub(crate) mod bindings {
    pub type Seed = newgyu::comp1::types::Seed;
    pub trait RandomGenerator {
        fn rand(seed: Seed) -> u32;
    }

そして、依存する Seed構造体とAlgorithm列挙（enum）も生成されます。

    pub mod newgyu {
        pub mod comp1 {
            #[allow(clippy::all)]
            pub mod types {
                #[repr(u8)]
                pub enum Algorithm {
                    Goblin,
                    Orge,
                }
                #[repr(C)]
                pub struct Seed {
                    pub value: u32,
                    pub algorithm: Algorithm,
                }

そして、export対象であるrand関数をwasmとしてexportするためのツナギのコードも生成されます。

    use super::Component as RandomGeneratorImpl;
    const _: () = {
        #[doc(hidden)]
        #[export_name = "rand"]
        #[allow(non_snake_case)]
        unsafe extern "C" fn __export_rand(arg0: i32, arg1: i32) -> i32 {
            #[allow(unused_imports)]
            use cargo_component_bindings::rt::{alloc, vec::Vec, string::String};
            let result0 = <RandomGeneratorImpl as RandomGenerator>::rand(newgyu::comp1::types::Seed {
                value: arg0 as u32,
                algorithm: newgyu::comp1::types::Algorithm::_lift(arg1 as u8),
            });
            cargo_component_bindings::rt::as_i32(result0)
        }
    };

乳牛

コンポーネントをコンパイルして生成する

上記のコードをWASMファイル、しかもコンポーネント化した形でコンパイルするためには通常のbuildとは一味違う cargo component buildコマンドを使用します。

$ cargo component build --release
    Encoding target for comp1 (/workspaces/wasm-component-example/comp1/target/bindings/comp1/target.wasm)
   Compiling serde v1.0.183
   Compiling serde_derive v1.0.183
     :
   Compiling cargo-component-bindings v0.1.0 (https://github.com/bytecodealliance/cargo-component#6af088a2)
   Compiling comp1 v0.1.0 (/workspaces/wasm-component-example/comp1)
    Finished release [optimized] target(s) in 8.07s
    Creating component /workspaces/wasm-component-example/comp1/target/wasm32-wasi/release/comp1.wasm

target/wasm32-wasiとして生成されるところがポイントです。

生成されたwasmファイルの中身を確認する

wasmファイルはwatと呼ばれる可読なテキスト形式に変換できますが、残念ながらcargo-component単独では確認できないのでwasm-toolsという別のツールのお世話になります。

$ wasm-tools print target/wasm32-wasi/release/comp1.wasm 
(component
  (type (;0;)
    (instance
      (type (;0;) (enum "goblin" "orge"))
      (export (;1;) "algorithm" (type (eq 0)))
      (type (;2;) (record (field "value" u32) (field "algorithm" 1)))
      (export (;3;) "seed" (type (eq 2)))
    )
  )
  (import (interface "newgyu:comp1/types") (instance (;0;) (type 0)))
  (alias export 0 "seed" (type (;1;)))
  (import "seed" (type (;2;) (eq 1)))
  (core module (;0;)
    (type (;0;) (func))
    (type (;1;) (func (param i32 i32) (result i32)))
       :
       :
  (core instance (;0;) (instantiate 0))
  (alias core export 0 "memory" (core memory (;0;)))
  (alias core export 0 "cabi_realloc" (core func (;0;)))
  (type (;3;) (func (param "seed" 2) (result u32)))
  (alias core export 0 "rand" (core func (;1;)))
  (func (;0;) (type 3) (canon lift (core func 1)))
  (export (;1;) "rand" (func 0))
  (@producers
    (processed-by "wit-component" "0.14.0")
    (processed-by "cargo-component" "0.1.0 (e57d1d1 2023-08-31 wasi:134dddc)")
  )
)

通常のwasmファイル（Componentに対してCore WASMと呼ばれている）は以下のようにmoduleから始まっているのに対して、componentという新たなキーワードが使われているところからして、従来のwasmファイルの形式とは全く異なるということがわかると思います。

(module
  (func $add (param $lhs i32) (param $rhs i32) (result i32)
    local.get $lhs
    local.get $rhs
    i32.add)
  (export "add" (func $add))
)

生成されたwasmファイルをWIT形式にリバースする

コンポーネントwasmファイルには型情報などが含まれているので、WIT定義をリバースすることもできます。

$ wasm-tools component wit target/wasm32-wasi/release/comp1.wasm 
package root:component

world root {
  import newgyu:comp1/types
  use newgyu:comp1/types.{seed}

  export rand: func(seed: seed) -> u32
}

乳牛

別のコンポーネントを参照したコンポーネント

先の例は「WITをもとにバインディングを生成する」という機能でしたが、今度はcomp1（先の例で作ったコンポーネント）を参照するcomp2を作ってみましょう。

コードにすると下記のようなもの。

comp2のhello-world関数の中でcomp1のrand関数を呼んでいる
comp1のrand関数に与える引数としてSeed構造体も必要

依存関係はCargo.tomlに書くのがcargo-componentの流儀

Cargo.tomlで定義可能な設定

こちらのドキュメントに記載がありますが以下のcargo-component独自の設定項目として以下があります。

[package.metadata.component]
[package.metadata.component.dependencies]
[package.metadata.component.registries]
[package.metadata.component.target]
[package.metadata.component.target.dependencies]

[package.metadata.component]

（意訳）
このテーブルはこのプロジェクトで作成されるコンポーネントに関する情報を記載するもの。
以下の2つのフィールドがサポートされる。

package - コンポーネントパッケージの名前を指定。コンポーネントがレジストリに発行されるときに使われる。
- （私見）現状ではまだレジストリがないのであまり意味がない。
target - 作成されるコンポーネントのターゲットworldの名前。ここで指定されたworldに対するバインディングが生成される。
- （私見）要するにwitファイルからバインディングを生成するときに、どのworldのバインディングを生成したいかを指定する
- [package.metadata.component.target]に書いても同じ意味になるとか

[package.metadata.component.dependencies]

ここがcargo-componentの作者が最も実現したかったこと - [dependencies]で依存するcrateを指定するのと同じような記法で依存するコンポーネントを指定できるようにしたい - だと思われる。

作者が思い描く未来では、コンポーネントは warg.io というレジストリ (= crates.io を意識したもの）に登録されて、依存性は以下の様に記述できるようになるとしている。

For example:

"my:component" = "0.1.0"

Which is equivalent to:

"my:component" = { package = "my:component", version = "0.1.0" }

しかしながら現状はレジストリは未サポートで、ローカルコンポーネントへの依存性解決しか実装されていないため以下の様にpath指定で書くことしかできない。

[package.metadata.component.dependencies]
"newgyu:comp1" = { path = "../comp1/target/wasm32-wasi/release/comp1.wasm" }

ここで path = "../comp1/target/wasm32-wasi/release/comp1.wasm" という記述方法はメインコミッターのpeterhuene氏も「イケてない」と思っており、path = "../comp1"と書けるようにしたいと言っている。

[package.metadata.component.target]

（個人的）targetという言い方が非常になじまない。どうやらcomponent.targetとはWITを指す様子。

ドキュメントにはこんな記載がある。

cargo-component will support expressing dependencies on the following package
types:

wit - a binary-encoded WIT document defining any number of interfaces and
worlds; a WIT package describes component model types.

component - a binary-encoded WebAssembly component; a component package
contains an implementation (i.e. code) in addition to describing component
model types.

package typeがcomponentの場合には前述通りcomponent.dependenciesに指定することから、component.targetと言う場合にはpackage type=witのケース想定なのだろう。

先に紹介したcomp1/Cargo.tomlでは下記の記述をしてローカルにあるwitの場所とバインディング生成対象のworld名を指定している。

Comp1のCargo.toml

[package.metadata.component.target]
path = "wit"
world = "random-generator"

これは下記の様に書いても同じ意味になるようだ。

[package.metadata.component]
target = { path = "wit", world = "random-generator" }

[package.metadata.component.target.dependencies]

component.dependenciesとの違いはtargetという言葉の解釈が前述通りならば、依存としてwitファイルを指定するのだろう。

ドキュメントの例としては

[package.metadata.component.target.dependencies]
"<package-id>" = "<version>" # or any of the other forms of specifying a dependency

としか書かれておらず詳細はわからない。

けれど、

The [package.metadata.component.target.dependencies] table is optional and
defines the WIT package dependencies that may be referenced in the local WIT
document.

こんな記述もあるのでlocal WITも参照できるのだと思う。
多分こう書けるのではないかなと思って試したものの良くわからない結果に終わった。

[package.metadata.component.target.dependencies]
"newgyu:comp1" = { path = "../comp1/wit/world.wit" }

で結局他のコンポーネントへの参照をCargo.tomlに書くとどうなるのか

例によってgenerateマクロがbindingsを生成してくれます。

comp2のCargo.toml

[package.metadata.component.dependencies]
"newgyu:comp1" = { path = "../comp1/target/wasm32-wasi/release/comp1.wasm" }

前回のcomp1の例との違いは「witファイルからではなく、component.dependencies（上記参照）に指定したwasmファイルからbindingsが生成される」というところです。

生成されるbindings

// Generated binding method for `rand` function that is defined in comp1
//comp1:rand 関数へのbinding
use bindings::comp1::rand;
// Generated types that `rand` function depends on
//rand関数が依存するAlgorithm列挙型とSeed構造体
use bindings::newgyu::comp1::types::{Algorithm, Seed};

モジュールのネームスペースが以下の様に微妙に異なる理由は良くわかりません。

bindings::comp1::rand
bindings::newgyu::comp1::types::{Algorithm, Seed}

乳牛

一旦のまとめ

cargo-componentは

witファイルをもとにbindingを生成できる
依存する別のコンポーネントのwasmファイルからもbindingを生成できる
コンポーネントの依存関係をCargo.tomlに書ける（まるで普通のRustのcrateのように）
Rustのコードから一気にコンポーネントモデル対応したwasmファイルをビルドできる
(wit-bindgenでは、一旦 --target=wasm32-wasiとしてコアモジュールwasmをビルドした後に、wasm-toolsでコンポーネントwasmに変換する必要があった）

乳牛

２つのコンポーネントをエイヤでガッチャンコはしてくれない

Composeは何？

When you compose components, you wire up the imports of one "primary" component to the exports of one or more other "dependency" components, creating a new component. The new component, like the original components, is a .wasm file, and its interface is defined as:

"primary"コンポーネントが依存するコンポーネントをくっつけて新しいコンポーネントwasmを作る、つまりスタティックリンクで一つのファイルにまとめるようなもの

現状はwasm-toolsでやる必要がある

$ wasm-tools compose path/to/component.wasm -d path/to/dep1.wasm -d path/to/dep2.wasm -o composed.wasm

wasm-tools compseの詳しい説明はこちら

このスクラップは2023/12/13にクローズされました

Component Modelに興味があるけど何者かもわからない

Component Modelが目指すゴール

ゴールとはしないこと

WASIとの関係性

A Native Code Analogy

Component <-> Executable

Module <-> Shared Library

Component Instance <-> Process

Module Instance <-> Loaded Shared Library

Wasm Runtime <-> Operating System

Component

Module

Component

Module

リファレンス、資料まとめ

Component Modelが何をめざしているか

Component Modelのフォーマット

WITの記法

コンポーネントにまつわる用語

cargo-component

cargo-component

WITファイルの定義からのバインディング生成

依存する型をWITを元に生成

exportする関数を実装するためのtraitを生成

自動生成されるバインディングコードの中身を確認してみる

コンポーネントをコンパイルして生成する

生成されたwasmファイルの中身を確認する

生成されたwasmファイルをWIT形式にリバースする

別のコンポーネントを参照したコンポーネント

依存関係はCargo.tomlに書くのがcargo-componentの流儀

Cargo.tomlで定義可能な設定

[package.metadata.component]

[package.metadata.component.dependencies]

[package.metadata.component.target]

[package.metadata.component.target.dependencies]

で結局他のコンポーネントへの参照をCargo.tomlに書くとどうなるのか

一旦のまとめ

２つのコンポーネントをエイヤでガッチャンコはしてくれない

Composeは何？

現状はwasm-toolsでやる必要がある