豆寄席第43回『Fastly Computeで学ぶ Wasm(WASI) ベースのサーバレス開発技法と勘所』開催報告
本稿は、豆寄席第43回の開催報告です。
開催概要
| タイトル | Fastly Computeで学ぶ Wasm(WASI) ベースのサーバレス開発技法と勘所 |
| 講演者 | 澤田 径氏(Senior Enterprise Serverless Architect, Fastly) |
| 開催日時 | 2025年6月26日（木）18時30分～20時00分 |
| 講演概要 |
2015年に発表されて以来目覚ましい発展を遂げてきたWebAssemblyは、2019年にはバージョン1.0がW3C勧告となり、今日ではブラウザ上のみならずブラウザ外でも幅広い用途で採用される標準技術へと進化を遂げています。 サーバ環境における活用もその一例で、各種コンテナランタイムがWasmサポートを実装するなど活用の幅が広がる中、WebAssemblyを基盤としたサーバ環境構築ツールやサービスも次々と登場しています。 本セッションでは、Wasmベースのサーバレス開発環境の中でも特にエッジ環境で動作するFastly Computeを題材にして、WebAssemblyの基礎的な部分からWasm(WASI) をサーバ構築に利用する際の特徴や制約条件、実際に運用する際のテクニックなどの実践的で応用的な範囲まで、デモや事例を含めてご紹介します。 |
講演の流れ
この講演はFastlyのアーキテクトである澤田氏にご登壇いただき、下記の流れでお話しいただきました。
- WebAssembly (Wasm) とサーバレスの基礎
- Fastly Computeとエッジサーバレスの実例
1. WebAssembly (Wasm) とサーバレスの基礎
はじめに、WebAssembly (Wasm) とサーバレスの基礎についてお話いただきました。
Wasmとは
Wasmは、.wasm拡張子で表されるスタックベース仮想マシン用のバイナリ命令フォーマットです。「1回ビルドすればどこでも動かせる」という言語非依存の思想が特徴で、Java、JVMの「Write Once, Run Anywhere」に似ていますが、Go、Rust、Rubyなど、より多様な言語で記述できる点が優れています。これは、OSやライブラリの層を意識せず、アプリケーションコードに集中できるという大きなメリットをもたらします。
WebAssembly Core Specification，Editor’s Draft, 24 June 2025，
Wasmの実行環境
Wasmバイナリを実行するには「Wasmランタイム」が必要です。主要ブラウザ（Chrome、Firefox、Safariなど）には既にWasmランタイムが搭載されています。
WASI (WebAssembly System Interface)
WASIは、WebAssemblyをブラウザ外で利用するためのインターフェース定義です。ファイルシステムアクセスなど、サンドボックス化されたWasm環境でIO操作を可能にするための重要な役割を担います。仕様策定も進んでおり、Preview 1 (2019年) からPreview 2 (2024年) へと進化しています。
WASI
Wasmtime
Wasmtimeは、WASIの高性能かつ安全な参照実装であり、Bytecode Allianceによって開発されています。Rust言語で実装され、実行性能、セキュリティ、ポータビリティが特徴です。これにより、Wasmバイナリを高速かつ安全に実行できる環境が提供されます。
Wasmtime
Component Model
Component Modelは2024年に登場した新しい概念で、WebAssemblyの「どこでも動く」思想をさらに進化させます。このモデルでは、異なる言語で書かれた複数の関数を、単一のWasmモジュールとして結合することが可能になります。澤田氏はこれを「非常に面白い」点として強調しており、各言語の得意分野を活かして組み合わせることで、より高い生産性を目指せる可能性を秘めていると述べています。
The WebAssembly Component Model
その他の話題
上記以外にもWasm全般にわたって重要な説明がありました。
・Wasmtime CLIの機能
・Wasmに対応する主要言語
・Wasmのセキュリティ
2. Fastly Computeとエッジサーバレスの実例
ここでは、Fastly Computeとエッジサーバレスの実例を紹介していただきました。
Fastly Computeの概要と沿革
Fastly Computeは、WebAssembly (Wasm) を活用したエッジサーバレスプラットフォームです。2011年に創業されたFastlyは、CDN（コンテンツデリバリーネットワーク）を提供し、特に変更の即時反映（平均150ミリ秒でパージ可能）で業界最速レベルを実現しています。WASI（WebAssembly System Interface）が登場した同じ時期に、FastlyはCompute@Edge (現在のFastly Compute) の提供を開始しました。Wasmコミュニティの立ち上げ時期からFastlyのエンジニアが深くコミットしてきたため、Wasmの進化と共にCompute@Edgeも発展を遂げています。
エッジサーバレスの利点と従来のサーバレスとの違い
エッジサーバレスは、静的ファイルの配信と同じように、動的な処理も「安心して夜眠れる」世界観を実現すると澤田氏は強調されました。従来のサーバレスでは、アクセスがないとインスタンスが停止し起動に時間がかかる「コールドスタート問題」や、これを回避するための「ウォームスタート」を採用すると発生するコスト増加、さらにはマルチリージョン展開やスケーリングの考慮といった様々な課題がありました。しかし、エッジサーバレスでは、デプロイ時にロケーションやメモリ・CPUの指定が不要です。Wasmバイナリ（モジュール）が世界中のエッジロケーションに自動的に分散配置されるため、コールドスタートが不要になります。開発者はコンカレンシーを考える必要がありません。これにより、サーバ管理の悩みが大幅に軽減されます。
WebAssembly (Wasm) による開発の簡素化
Wasmは「アプリケーションレベルの仮想化」を提供します。開発者はGoやRustなどのソースコードをWasmにビルドする際、OSやライブラリの層を意識する必要がなく、アプリケーションコードの記述に集中できます。澤田氏はこの「責務の削減」が非常に重要だと強調されました。不要な権限を持たせない設計によって、「塩漬けのコンテナ」のようなメンテナンスが困難なインフラを減らしたいという思いを語っています。これは、長期的なプロジェクトや引継ぎの際にもメリットが大きい点です。
Fastly Computeの技術的特徴と対応言語
Fastly Computeは、最大100MBのWasmバイナリをアップロードでき、これはエッジコンピューティングサービスとしては業界最大級のサイズです。これにより、簡単なDBや設定ファイル、ライブラリなどをバイナリに含めることが可能になり、開発の自由度が高まります。澤田氏は、非公式SDKも自分で作成できる点が面白いと述べています。
Fastly ComputeにおけるWAF機能の統合 (関数呼び出し)
Fastly Computeでは、WAF（Web Application Firewall）をコード中の関数として呼び出すことが可能です。これは澤田氏が非常に面白いと強調する特徴です。通常はサーバの前段で処理されるWAFを、リクエスト処理のロジックに組み込めることで、より詳細で柔軟な制御が可能になります。例えば、WAFの検査結果（ブロック/許可）やボット検出結果に基づいて、アプリケーションの振る舞いを動的に変更するといった高度な処理が、エッジのプログラム内で実現できます。
Developer guides
主要なユースケース/導入事例
Fastly Computeは多くの企業で活用されています。例えば日本経済新聞社様の事例では、もともとEC2のインスタンス400台以上で構築していたシステムをFastly Computeに移行することでデプロイ時間を劇的に短縮することに成功しています。
事例
質疑応答
質疑応答1：PoP（Points of Presence）の数について
質問: Fastlyが全世界に約100箇所しかPoPを持たないのはなぜか。数が多い方が有利に思えるが、システムアーキテクチャ的にどのような意図があるのか。
回答: Fastlyは意図的に必要最小限のPoP数に抑える戦略を取っています。これは、各PoPのキャッシュヒット効率を最大限に高めるためです。全国に広がるコンビニのような小規模店舗ではなく、デパートのような大規模で豊富な在庫を持つ拠点を要所に配置するイメージに例えられます。この戦略により、キャッシュミスが減り、結果として顧客へのコンテンツ提供がより迅速に行われます。
Points of presence
質疑応答2：Go言語とLLM（Copilot）の互換性について
質問: Fastly Computeで使用されるGo言語は、LLM（大規模言語モデル）やCopilotのようなAIツールと連携して、コード生成やコンパイルが可能かどうか。
回答: 澤田氏は、Go言語でのコンパイルは可能であり、LLMとの相性は非常に良いと考えています。GoはLLM界隈でコードの書きやすさが評価されており、個人的にFastly ComputeでGoが使いやすいと感じる理由の一つに、その標準ライブラリの充実度が挙げられます。WebAssembly (Wasm) 環境はサンドボックス化されており、通常はファイルシステムへのアクセスなどI/Oに制限がありますが、Goの標準ライブラリは外部I/Oをうまく抽象化しており、Wasm環境に適した設計のライブラリが多いため、外部ライブラリの導入がスムーズであると強調されました。
Go on the Compute platform
質疑応答3：Config StoreおよびSecret Storeのパフォーマンスについて
質問: Config StoreやSecret Storeのパフォーマンス（読み書き速度）は、KV（Key-Value）ストアに近いのか、それとも異なるのか。
回答: Config StoreやSecret Storeは、KVストアよりも高速です。KVストアの読み込みレイテンシーが約5〜6ミリ秒であるのに対し、Config Storeは桁違いに速く、マイクロ秒レベルで読み込めます。ただし、Config Storeはサイズ制限（約8KB）や書き込み頻度に制約があります（1時間あたり約100回）。高速な読み込みが必要ですが、データ量が小さく更新頻度が低い設定情報などに適しています。より大きなデータを高速に扱いたい場合は、Wasmバイナリ自体にデータを埋め込む方法（最大100MB）も有効です。さらにKVストアのパフォーマンスを向上させるには、Simple Cacheなどのキャッシュ層を前段に配置することで、読み込み速度を短縮することも可能だと説明されました。処理が高速であるほど、Computeの使用時間が短縮され、結果的にコストも抑えられることが強調されました。
Edge Data Storage
所感
本セッションを通じ、澤田氏はWebAssemblyとEdge Computingが今後の開発を変革すると強調しました。Wasmのコンポーネントモデルは複数言語の強みを活かし高生産性開発を可能にします。これにより開発者は本質的なコードに集中できます。
今回は議論の時間が取れませんでしたが、Edge Computingは生成AIとも密接な関係があります。Edgeでの生成AI利用により、これまで考えられなかったきめ細かなサービスが可能になるかもしれません。
今後の 豆寄席 へのご参加もお待ちしております！