Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会
Search
iWonder118
June 21, 2025
0
7
花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会
iWonder118
June 21, 2025
Tweet
Share
More Decks by iWonder118
See All by iWonder118
我々はなぜ中間表現を作るのか
iwonder118
0
730
OODAループを回すVibe_Coding.pdf
iwonder118
0
12
Reactで見る!純粋関数で深ぼる副作用
iwonder118
0
540
SSG___CSRで乗り切るiframe内ルーティング_AIコーディング拡張版_in_Funabashi.dev.pdf
iwonder118
0
42
SSG + CSRで乗り切るiframe内ルーティング in React Tokyo LT 2025_05_17
iwonder118
0
4
React ToDoアプリをClineで作りながら考える フロントエンドエンジニアは AIによってなくなるのか?
iwonder118
1
1.1k
手軽に始めるDuckDB
iwonder118
0
34
開発においての気配り
iwonder118
1
18
Featured
See All Featured
Building an army of robots
kneath
306
46k
Six Lessons from altMBA
skipperchong
29
4.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
We Have a Design System, Now What?
morganepeng
54
7.9k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
A designer walks into a library…
pauljervisheath
210
24k
Statistics for Hackers
jakevdp
799
230k
Producing Creativity
orderedlist
PRO
348
40k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
690
Transcript
花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会
自己紹介 社内システムを改修したり、インフラを作ったり、APIを生やしたり...etc 趣味:トンチキ技術グッズを作ったり 河村 直樹(@iwonder118) かわむら なおき
グッズ①:Rustyなカニペンホルダー
グッズ②:Pug(Data dogの置物) ※余談:名前は「STRIKE JADE」Pug記法で JADE
グッズ新作!:ラバーDuckDB 上か見るとロゴに
WASMを知っている人✋
WebAssembly(Wasm)とは? • 高速起動・高パフォーマンス ネイティブに近い速度で動作 • プラットフォーム非依存 CPUやOSに依存せず様々な環境で動く • セキュアなサンドボックス環境 ホストと分離され安全に実行可能
• 多言語対応 Rust, C/C++, Goなど多くの言語からコンパイル可能
デメリット システムAPIの制限 • Wasm単体ではファイルやネットワークへの直接アクセスができない • ホスト側のAPI提供に依存するため、環境によって差異が生じる 開発・デバッグの難しさ • デバッグツールやプロファイリング環境がまだ成熟していない。 (ローカル環境での開発難しい
....) • ソースマップやトレース情報の対応が言語やツールチェーンで限定的 対応していない言語機能や環境 • マルチスレッドや一部のシステムコールを完全サポートしていない • レガシーなC/C++コードの移植には制約や書き換えが必要な場合が多い ランタイムの多様化と互換性課題 • 複数のWasmランタイム間での完全な互換性や挙動保証がまだ課題 • WASIの標準化が進行中で、現時点で仕様差分が存在する
エッジランタイムとしての Wasmの強み ライブマイグレーションの実現 • 実行中の状態を保持したままエッジノード間でワークロード移動が可能 • 従来のコンテナよりも高速かつ軽量に切り替えられる > ライブマイグレーションについて 動作中のプログラムやワークロードの実行状態(メモリの内容や
CPUレジスタの状態など)を保持したまま、一つの実行環境 (ノード)から別の実行環境へ移動させる技術 サービスの停止時間をほぼゼロに抑えつつ、負荷分散やメンテナンスが可能 エッジ特化のシステムAPI拡張 • WASIを拡張し、エッジ環境固有のリソース(センサーや ローカルストレージ)へ安全にアクセス • 多様なエッジノードで同一の Wasmモジュールが動作可能
エッジランタイムとしての Wasmの問題点 ARM x86 リソース制約の厳しさ • メモリ・CPUが限られているため重い処理に不向き Cloudflare WorkersではCPUが10〜30ms上限、メモリが最大128MB •
大規模データ処理や複雑なアルゴリズムはパフォーマンス低下の可能性 状態管理の難しさ • ライブマイグレーションや分散状態の同期が技術的に複雑 • 状態を持つアプリケーションは設計・運用コストが増加 ランタイム互換性の課題 • Wasmランタイム間での挙動差異や APIの非標準化が存在 • 実行環境ごとに微妙な差異がバグや障害の原因になることも ランタイムA ランタイムB
Open Telemetryとのコラボレーション うまく切り分けて動かせる分、監視が難しい • 一貫した監視・ロギング基盤の構築 OpenTelemetryはクラウドネイティブ標準で、多様なバックエンド( Jaeger, Prometheus, New Relic等)に対応
• パフォーマンスボトルネックの特定が容易に Wasm特有の起動遅延や API呼び出しのコストを詳細に計測可能 • 運用の効率化・信頼性向上 エッジ環境の多数ノードにまたがる挙動の集約・分析が容易に そこでOpen Telemetry 一言でいうと共通規格でログを送れるやつ
可能性 • どこでも同じ動作をする安心感 OSやデバイスに依存せず一貫した動作を提供できるため、動作不良や環境差異を気にしなくてよい • エネルギー効率とコストの最適化 必要な場所で必要な処理だけを行うため、ネットワーク負荷・クラウドコスト・電力消費の削減に寄与 IoTの未来を感じる • 柔軟なアップデート・メンテナンス
リモートで実行中のワークロードを停止せずに更新やパッチ適用が可能に • 省エネ・効率的なリソース活用 デバイス近くの最適なノードに処理を動的に振り分けることで、無駄な通信や遅延を削減
参考 https://speakerdeck.com/chikuwait/beyond-portability-live-migration-for-evolving-web assembly-workloads beyond-portability-live-migration-for-evolving-webassembly-workloads