More than 1 year has passed since last update.

Cloud Native Wasm Day EU 2023 参加レポート

Last updated at 2023-06-01Posted at 2023-06-01

はじめに

2023年4月の KubeCon + CloudNativeCon Europe 2023 の Co-Located Events として開催された Cloud Native Wasm Day の参加レポートです。Wasm Day は Cloud Native エコシステム全体で注目度が高まっている WebAssembly にフォーカスしたイベントとなっています。

Welcome + Opening Remarks - Kelsey Hightower, Google

Kubernetes をはじめとした Cloud Native コミュニティで著名な Kelsey Hightower さんによるオープニングです。オープニングの冒頭に「Wasm は新しいユニバーサルコンピューターを構築できると思いますか？」と参加者に質問していたのが印象的でした。Kelsey さんは Wasm のメリットとして、開発者が様々な言語でコードを書けることと、どこにでもデプロイできることを挙げていました。

Evolution of Wasm: Past, Present, Future - Bailey Hayes, Cosmonic

Wasm コミュニティがこれまでに取り組んできたこと、現在取り組んでいること、そして Wasm の将来について紹介するセッションです。

Wasm の始まりは、C や C++ で書かれたコードを Javascript に変換する asm.js というテクノロジーで、そこから2015年に設計が開始されて、2017年に Firefox などのメジャーなブラウザで利用が可能になり、2019年に 1.0 がリリースされた、という流れで Wasm は進化してきたそうです。ちなみに、2015年の設計時点で既にユースケースとしてサーバーサイドでの実行が挙げられていたようで、そういった設計上の目標もあり WASI が策定されて、現在のサーバーサイドでの Wasm 実行が実現されたという話が興味深かったです。

2020年から2022年は、Google Meet と Zoom での背景ぼかしやストリーミングアプリケーションで Wasm が利用されるなどユースケースが増加したり、ユースケースが増えたことにより初期の仕様には含まれていなかった提案がされたりと、Wasm の改善に繋がる出来事が多かったそうです。また、Wasm を利用して Envoy を機能拡張できることを例に挙げて (過去に別の記事で解説しています)、Wasm はプラグインモデルとしても有用だということも話されていました。

WASI Preview 2 で策定中のコンポーネントモデルについての話もありました。コンポーネントモデルは、C++ や Rust など様々な言語で書かれた Wasm コンポーネントを組み合わせてアプリケーションが作成できるようになるもので、コンポーネント同士が通信するためのインターフェースを WIT (WebAssembly Interface Type) という独自の IDL (Interface Definition Language) で定義して、その定義から C++ や Rust など任意の言語のソースコードを自動生成して実装するといった仕様になっているそうです。発表者はコンポーネントモデルはユニバーサルコンピューターの実現に繋がる、というようなことも話されていました。

Wasm コンポーネントを利用することのメリットも紹介していて、自由な言語でコードを書けること、どこでも実行ができること、安全なサンドボックス内で実行できること、コンポーネント間でリソースを共有しないこと、などをリストアップしていました。

The Road to Winch - Saúl Cabrera, Shopify

Wasmtime の新しいベースラインコンパイラである Winch を紹介するセッションですが、自分は参加を見送ったので興味がある方は録画をご参照ください。

セッションの内容はチェックしていませんが、ベースラインコンパイラの意味が気になり調べたメモがあるので残しておきます。ベースラインコンパイラは、最適化されたコードを減らす代わりにコンパイル性能を向上させて Wasm の起動時間を速くするもので、Wasmtime では Cranelift がデフォルトのコンパイラとして使用されますが、Cranelift はコードの最適化を行うためにコンパイルの速度を犠牲にしていて、Wasm の JIT コンパイルで性能が求められるケースでは不向きとされていました。そういった背景からコンパイルと起動時間の高速化などを目的に開発されたのが Winch (WebAssembly Intentionally Non optimizing Compiler and Host の頭文字を取ったもの) のようです。詳細は Winch の RFC をご参照ください。

WASI and the Cloud - Jiaxiao Zhou, Microsoft & Dan Gohman, Fastly

WASI の次のメジャーバージョン WASI Preview 2 を紹介するセッションです。

セッションは Wasm の発明者が自ら Wasm の気に入ってる点を話すところから始まりました。様々な環境で実行できるポータビリティ、ソースとなる言語を多くサポートしていること、サンドボックス化されていること、そのサンドボックス化されたプログラムが Composable であることを挙げていました。

そして、Composable という特性を実現しているのは WASI Preview 2 から導入される WIT とコンポーネントモデルであり、WIT があることで自身が提供する振る舞いや自身が求める振る舞いを他のコンポーネントに伝えることができると話されていました。また、今後非同期処理のための型をサポートする予定もあるようで、コンポーネントモデルのマイルストーンを確認したところ、確かに WASI Preview 3 でサポートする予定があると書かれていました。

ここから wasi-cloud-core の話が展開されていくのですが、事前に World という仕組みを理解しておくのがベターなので補足を挟みます。WIT にはインターフェースを束ねて定義する World という仕組みがあり、例を挙げると、ファイルシステムやソケットや標準入出力にアクセスできるインターフェースなど CLI に必要な機能をまとめて提供する CLI World や、SQL データベースを操作できる機能をまとめた SQL World などを定義する取り組みが進められています。World があることで、より抽象的に Wasm の実行ホストやコンポーネントが提供する/必要とするインターフェースを示すことができます。この WIT により機能を提供する側とされる側のインターフェースがマッチする場合は互いを繋ぎ合わせることができるというのが、コンポーネントモデルの Composable という特性と自分は理解しています。

World の説明をしたのでセッションの紹介に戻ります。現在、そのような World の1つとして AWS のような Cloud Computing 上で Wasm を実行するための wasi-cloud-core を提案中のようです。wasi-cloud-core は wasi-keyvalue、wasi-messaging、wasi-http、wasi-runtime-config、wasi-distributed-lock-service、wasi-sql、wasi-blob-store で構成された World で、発表者が所属する Deis Labs では wasi-cloud-core のホスト実装も既に実験されているようでした。

wasi-cloud-core については Wasm I/O 2023 の wasi-cloud: The Future of Cloud Computing with WebAssembly でも紹介されているので、興味がある方はそちらもご参照ください。

ZeroTrust Microservices with Wasm & WireGuard - Jordan Rash

ゼロトラストアーキテクチャと Wasm を組み合わせるアプローチを紹介するセッションです。

はじめに、安全なソフトウェアを構築するには、サンドボックス化された環境、認証と認可、TLS が重要で、ゼロトラストは信頼のマイクロセグメンテーションであるという話があり、Wasm の特徴であるサンドボックス化 (これをセグメンテーションとも表現していた) のデモが行われました。意図的に悪質なコードを含んだ Go プログラムを例に挙げ、そのコードを元に生成した通常のバイナリと Wasm モジュールをそれぞれ実行して、通常のバイナリが悪意を持った振る舞いをする一方で、Wasm モジュールの方はサンドボックスによって悪質なコードがブロックされることを実演されていました。

補足をすると、Wasm はホスト環境が許可した API しか触ることができないサンドボックス環境で実行されるので、プラットフォーム側が期待しない処理は実行することができない仕組みになっています。この仕様は Capability-based Security として WASI の設計ドキュメントにも記載されています。

デモを終えてからは wasmCloud の簡単な紹介がされていましたが、基本機能のピックアップだけだったので個人的に調べたメモを残します。wasmCloud は、クラウドからエッジまで広い範囲に分散したアプリケーションの構築を支援するもので CNCF の Sandbox プロジェクトとして開発が進められています。wasmCloud には Wasm ランタイムの機能に加えて、Wasm を Actor という単位にまとめてアプリケーションとしてデプロイする機能などが実装されていて、Wasm のオーケストレーターという立ち位置と自分は理解しました。基本機能をピックアップした後は wasmCloud に実装されているセキュリティ機能として、Signed modules、Contract driven RPM、Policy Enforcement、Signed invocations が紹介されていたので興味がある方は内容をチェックすると良いでしょう。

そして、最後にゼロトラストの考え方に基づいて開発された VPN サービスである Tailscale と wasmCloud を組み合わせたライブデモが行われてこのセッションは終了となりました。

Lightning Talk: Where the Server Goes, Nobody Knows! - Brooks Townsend, Cosmonic

Dr.Seuss の世界観で描かれた絵本で Wasm を紹介する LT です。
内容は入門編という感じで、テンポも良くて面白いセッションでした。

Lightning Talk: WebAssembly and Syscalls: A Story in Tool-Building - Daniel E Phillips, Loophole Labs

ホストに依存しないシステムコールのレイヤーを Wasm アプリケーションに追加するツールを紹介する LT です。

少なくとも UNIX エポックが終わる2038年までは (いわゆる2038年問題)、POSIX インターフェースに大きく依存するレガシープログラムを Wasm で扱えるようにしておく必要がある気がするという話から、Wasm でシステムコールを扱う方法の紹介がありました。

1つ目の方法がホストの関数にパッチを当てることやプラットフォーム向けの関数を無視すること、2つ目の方法が WASI のようにホストへのスコープ付きアクセスを許可すること、3つ目の方法が基盤システムのように動作する Wasm コンポーネントやそういったレイヤーを提供すること (例として libc を挙げていた) とのことでした。この話に絡めて、Wasm モジュールが呼び出すシステムコールなどを簡単に識別する方法として wasm-toolkit の strace 機能を紹介されていました。命名のとおり strace の Wasm 版という理解で良いかと思います。

ここまでの話を踏まえて、ホストに依存しないシステムコールのレイヤーを Wasm アプリケーションに追加する marcotte-wasm というプロジェクトの紹介がありました。最後にデモもされていたので、興味がある方はチェックしてみてください。

Lightning Talk: Why You Need a Universal Plug-In System - Benjamin Eckel, Dylibso

プラグインシステムの未来について考えていることを話す LT です。

1996年に発表されて現在でも標準的に使われている VST というオーディオプラグインの規格の優れている点 (音楽制作ソフトにおけるユニバーサルプラグイン的な立ち位置だった様子) の紹介から始まり、多くのソフトウェアベンダーが SaaS アプリケーションに拡張性を持たせる際に独自の DSL を採用することで、プラグインシステムの仕様がベンダーごとに独立する現状を説明した上で、今後は Wasm がプラグインシステムの標準になり、業界ごとにプラグインシステムの WIT を定義するような流れになってくるのではないかという予測を立てていました。決済業界のプラグインシステムを標準化するなら決済に必要な API をまとめた payments.wit を定義するようなイメージだそうです。短い時間でしたが面白い未来予想だなと思いました。

Scratching an Itch: Running Policy in Hard to Reach Places with WASM & OPA - Charlie, Styra

OPA を Wasm コンポーネントとして稼働させる PoC を紹介するセッションです。

ビジネスはポリシーに基づいて構築されているため、アプリケーションにはポリシーを元にデータを評価するモジュールが必要だという話から始まり、そこから OPA と Rego の基本説明や、OPA を Server として配置するよりは、Wasm モジュールとしてアプリケーションに組み込んだ方がデータの評価結果をより早く取得できるのではないか？という、今回の PoC に至ったモチベーションを話した後でデモが行われました。

デモの後は OPA コミュニティでの Wasm に関する取り組みの紹介がありました。2018年から様々な取り組みが始まり、現在は公式やコミュニティから npm-opa-wasm、dotnet-opa-wasm、python-opa-wasm、java-opa-wasm、rust-opa-wasm といった Wasm SDK が公開されているとのことでした。参考資料として、OPA Wasm Docs、Awesome OPA の Wasm カテゴリー、OPA PoC Blog (2019) も紹介されていたので、Wasm での OPA 活用に興味がある方は参照してみるのが良いでしょう。

このセッションを聞いて、Wasm コンポーネントとして OPA を動かすための土壌は既に整っているので、Wasm でアプリケーションを開発していて認可レイヤーが必要になった場合は、安心して OPA を採用できるなと思いました。

Future of Component Tooling - Peter Huene & Guy Bedford, Fastly

Bytecode Alliance が公開する便利ツールを利用して WebAssembly Component を動かすまでの一連の流れを紹介するセッションです。

セッションは WebAssembly Component と World の定義の説明から始まりました。WebAssembly Component は WebAssembly 仕様の拡張で、実装としての WebAssembly Module が内包されていて、他の Component と組み合わせて実行できる仕組みであり、World は WIT 形式で定義した Component が提供してほしい機能と提供できる機能を定義したものと説明されてました。また、Component Registry のためのプロトコルとして warg というものを開発しているという紹介もありました。

基本的な説明を終えてから WebAssembly Component のデモに移りました。はじめに ComponentizeJS を使用して JavaScript ファイルと World の定義から Component をビルドして、jco というツールを利用してテストした後に Component Registry にアップロード。そして、cargo-component を利用して Rust コードを元にビルドした Component から、Component Registry にアップロードした Component を呼び出すまでの一連の流れを紹介していました。

また、Component を視覚的に繋ぎ合わせるツールとして https://wasmbuilder.app の紹介もありました。いずれのツールも Bytecode Alliance で開発が進められている OSS で、どれも Wasm 開発をする際には便利そうなものばかりでした。

Wasm + Kubernetes: Beyond Containers - Sean Isom, Adobe & Colin Murphy, Adobe

Kubernetes ベースのプラットフォームで Wasm ワークロードをサポートした取り組みを紹介するセッションです。

セッションは Adobe でのクラウドサービスの歴史の紹介から始まりました。Adobe では CI/CD を改善するために、2014年から2015年にかけて Apache Mesos ベースのコンテナ実行環境の運用が始まり、2016年にはサービス開発者の負担を軽減するために Ethnos というマルチテナント型の CaaS (Container as a Service) プラットフォームが開発され、現在では Kubernetes を中心としたインフラになっているそうです。

一方、マルチテナント型で運用は上手くいっているものの、大規模なサービスや小規模なサービスや特殊な要件のサービスなど、様々なサービスの稼働が増えていくにつれて余剰リソースが増えてコストがかかるという課題があるそうです。その課題を解決するために、既存の Kubernetes ベースのプラットフォームで Wasm ワークロードをサポートする取り組みを開始したとのことでした。

Adobe では稼働しているワークロードの大半が Java アプリケーションのようで、それらのコンテナにリソースを必要最低限だけ付与することが難しく、どうしても余剰リソースが発生してしまっていたようです。Wasm は起動が早くトラフィックの増加に応じて柔軟にスケールできるので、Kubernetes でコンテナで稼働させているサービスと Wasm ワークロードを共存させることでリソースを有効活用したい狙いがあるように聴こえました。

ちなみに Adobe では Lightroom Web、Acrobat Web、Photoshop Web などの製品で Wasm を活用していたのもあり、ブラウザ側での Wasm 利用について多くのナレッジを持っているとも話されていました。

プラットフォームでどのように Wasm 実行をサポートしているかですが、Kubernetes と wasmCloud を併用して双方のクラスタで稼働するワークロードを Kubernetes Service Applier Actor を利用して連携させているそうです。ちなみにこの方法は wasmCloud の Kubernetes Integration で紹介されている方法と同じものでした。

そこからエッジで稼働させた Wasm の事例として、署名画像の背景除去や、編集ツールや AI によって加工された画像を判定する Content Authenticity Proxy の紹介があり、セッションは終了となりました。

今回のセッションで紹介された事例は、CNCF のブログ記事 "Better together: A Kubernetes and Wasm case study" でも紹介されているので、興味がある方はそちらもご参照ください。

Calling OPA from eBPF, Through WASM, in the Kernel? You've Gone Mad! - Nandor Kracser, Cisco

eBPF と Wasm を連携させてカーネルレイヤーで Wasm モジュールを実行する実験的な取り組みを紹介するセッションです。

近年盛り上がりを見せている eBPF と Wasm をカーネルレイヤーでどのように連携できるのかという話から、wasm-kernel-module という実験的なプロジェクトの紹介が始まりました。wasm-kernel-module は Wasm ランタイムを実行するカーネルモジュールで、これを利用することでカーネル空間で Wasm が実行できるそうです。

仕組みとしては eBPF プログラムが kfuncs (BPF Kernel Functions) を介して wasm-kernel-module 内の Wasm モジュールを実行するというもので、Wasm ランタイムとしては wasm3 を採用しているようでした。wasm-kernel-module のデモもあり、OPA を Wasm モジュールにコンパイルしてカーネルレイヤーで特定のポリシーを満たすパケットをカウントするデモを実演されて、最後に今後の展望を話してセッションを終了となりました。

Serverless WebAssembly: Roundtrip Scaling from 0 to 10k in 10 Seconds - Kate Goldenring & Joel Dice, Fermyon

WebAssembly がサーバーレスプラットフォームに最適な理由を紹介するセッションです。

セッションはサーバーレスの説明から始まりました。サーバーレスは高速なスケーリングとハードウェアリソースの有効活用を可能にするもので、コスト削減と Green Software Foundation が掲げる持続可能なソフトウェアの構築にも繋がると話していて、ハードウェアリソースが少なくて済む理由としてマルチテナント型であることを挙げていました。

そこから、Firecracker の論文を引用して Firecracker MicroVM に実装されている理想的なサーバーレスの6つの特性の説明がありました。1つ目がワークロードが分離可能であること、2つ目がオーバーヘッドの小ささと単一マシンに多くのワークロードを詰め込めること、3つ目がイベントドリブンでネイティブに近いパフォーマンスを出せること、4つ目が自由なマシンで動かせる互換性、5つ目が高速な起動と停止、6つ目がリソースをオーバーコミットできること、と説明されていました。

そして、Wasm もそれらの特性を持っていて、Firecracker MicroVM よりも更に高速な起動と停止ができると紹介した上で、Wasm は自分達が待ち望んでいたサーバーレスのワークロードの理想的な単位であると話していました。実際に発表されてる方の会社では WebAssembly ベースのサーバーレスサービスを提供しているようです。

次に、サーバーレスのワークロードに対して要求する分離モデルの話がありました。そこではテナントごとの分離に加えてリクエストごとの分離も重要であると話されていて、そのような細かな分離ではパフォーマンスが犠牲になると説明した上で、Wasmtime で HTTP サーバーを呼び出すまでの各処理を高速化した実験 (関数呼び出しまで 6.6ms!) の紹介がありました。

その後、コンテナや Firecracker と比較して、WebAssembly ベースで分離したワークロードのパフォーマンスが如何に優れているかを数値で示して、最後に Wasmtime と Nomad を使った Wasm プラットフォームのパフォーマンステストのデモが実施されてセッションは終了となりました。

WebAssembly のユースケースとして、サーバーレスプラットフォームでの採用が有用であることを知れてとても勉強になりました。

How Small Can You Go? Customizing Interpreted Languages for Wasm Environments - Rafael Fernandez Lopez, VMware & Oscar Spencer, Suborbital

Ruby、Python、PHP などのインタプリタ言語で作成した Wasm モジュールのサイズを小さくすることを目的に VMware Labs が進めている WebAssembly Language Runtimes (WLR) プロジェクトを紹介するセッションですが、自分は参加を見送ったので興味がある方は録画をご参照ください。

Lightning Talk: Fun with SQLite and Wasi-Libc - Jesús González Martí, VMware

SQLite を Wasm として動かす際に得た教訓を紹介する LT です。

SQLite は、スマートフォン、タブレット、ブラウザ、IoT デバイス、自動車など様々な環境でデータベースを動かす重要な技術であることから、Wasm で多様なアプリケーションを動かすためにも SQLite を Wasm コンポーネントとして動かすことには価値があると考えて実際にやってみたという話から始まりました。

SQLite を Wasm としてビルドする際には WASI SDK というツールチェーンを利用したようで、WASI SDK が初耳だったので調べたところ、C/C++ のコードを Wasm としてビルドするために必要な Clang、LLVM、wasi-libc のツールをパッケージングした SDK のようでした。ちなみに wasi-libc は Wasm 用の libc で POSIX 互換の API (WASI 準拠) を豊富に提供するライブラリでした。

SQLite を Wasm としてビルドした際に出てきた注意点として、wasi-libc に実装されている API の中には POSIX の仕様を完全に満たしていないものがあることを挙げていました。例として getpid、mmap、clocks、signals の API は、他の API を組み合わせてエミュレートしている都合、利用する際に機能に制限があるので注意が必要とのことでした。

この話が気になって軽く調べてみたのですが、mmap (ファイルやデバイスをメモリーにマッピングするシステムコール) では malloc と read を利用してファイルの内容をメモリーにコピーして mmap のような振る舞いを実装しているみたいです。(参考: WebAssembly/WASI#304)

最後に C/C++ 製のソフトウェアを WASI に移植した際に得た教訓の紹介がありました。1つ目が WASI は POSIX の完全互換ではないので wasm-libc と glibc の API の違いを把握しておくこと、2つ目が Wasm としてビルドできたとしてもそれが必ずしも機能するとは限らないこと (WASI の API 実装は POSIX と微妙に異なるケースがある)、とのことです。

Wasm is not POSIX である理由が知れて非常に面白いセッションでした。

Lightning Talk: KWasm Operator - The Easy Way for Running WebAssembly on Kubernetes - Max Schmidt, Liquid Reply GmbH

Kubernetes クラスタに Wasm の実行環境をセットアップする KWasm Operator を紹介する LT です。

内容は LT ということもあり簡単な紹介とデモで終わってしまったので、ここでは自分の方で調べた情報をまとめておきます。KWasm Operator は Node リソースを Watch する Controller と Job リソースを Watch する Controller で構成された実験的な Operator です。カスタムリソースは提供されていません。

仕組みとしては、Node Controller が特定の Annotation が付与された Node に対して KWasm Node Installer を実行する Job を発行して、Wasm ランタイムをインストールするものになっています。Job Controller は Job のステータスを拾ってロギングするだけの実装でした。Node への Wasm ランタイムのインストールが終わったら、それらの Node に Pod をスケジューリングすれば Wasm ワークロードを稼働させることができます。

KWasm Node Installer は Wasm ランタイムである WasmEdge、Wasmtime、Spin いずれかのインストーラーとして機能しますが、オプションによってランタイムを指定できる作りにはなっておらず、それぞれイメージとして独立させている作りになっていました。ちなみに KWasm Operator では WasmEdge のインストーラーとして機能する KWasm Node Installer イメージがハードコートされています。

KWasm Operator はあくまで PoC な位置づけのように見えたので、自社で同じようなものを開発する際に1つの実装として参考にはするのが良いかなと思いました。

Lightning Talk: Everything You Wanted to Know to Adopt WASM Now! - Ivan Pedrazas, Docker Inc

Wasm を採用するために知っておくべきことを紹介する LT です。

Wasm でも Docker と同じように Build、Ship、Run を簡単にできるという話から始まりました。Build は使い慣れている Dockerfile と docker build コマンドで簡単にできて、Ship も OCI イメージとして扱えるので docker push コマンドなどで自身が管理しているコンテナレジストリにアップロードが可能で、Run も Kubernetes クラスタに Wasm ランタイムをインストールすれば簡単にデプロイできると話されていました。このように Wasm ワークロードを実行するまでのプロセスやツールは既に揃っているので、Wasm を採用するかは自分達次第という言葉で LT は終了しました。

Closing Remarks - Program Committee Member- Liam Randall, Cosmonic

クロージングです。イベントスポンサー、CNCF 関係者、スピーカーなどに感謝を述べて Wasm Day を締めくくっていました。話の中で KubeCon NA 2022 で Docker 社の CEO と Kelsey Hightower が Wasm についての対談 "Vertex Ventures Fireside Chat: WebAssembly, with Kelsey Hightower and Docker CEO Scott Johnston" がオススメだと言っていたので時間がある時にチェックしてみようと思います。

さいごに

今回は Cloud Native Wasm Day の各セッションの内容と感想をまとめました。通常のセッションと LT ともに面白い発表ばかりでとても良いインプットができました。国内外で Wasm が盛り上がっている空気を感じているので、今後も継続して Wasm の動向を追っていきたいと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up