Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
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
6
花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会
iWonder118
June 21, 2025
Tweet
Share
More Decks by iWonder118
See All by iWonder118
我々はなぜ中間表現を作るのか
iwonder118
0
340
OODAループを回すVibe_Coding.pdf
iwonder118
0
11
Reactで見る!純粋関数で深ぼる副作用
iwonder118
0
490
SSG___CSRで乗り切るiframe内ルーティング_AIコーディング拡張版_in_Funabashi.dev.pdf
iwonder118
0
38
SSG + CSRで乗り切るiframe内ルーティング in React Tokyo LT 2025_05_17
iwonder118
0
4
React ToDoアプリをClineで作りながら考える フロントエンドエンジニアは AIによってなくなるのか?
iwonder118
1
1.1k
手軽に始めるDuckDB
iwonder118
0
31
開発においての気配り
iwonder118
1
17
Featured
See All Featured
Visualization
eitanlees
148
16k
Thoughts on Productivity
jonyablonski
70
4.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
GraphQLとの向き合い方2022年版
quramy
49
14k
KATA
mclloyd
32
14k
Fireside Chat
paigeccino
40
3.6k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Speed Design
sergeychernyshev
32
1.1k
Producing Creativity
orderedlist
PRO
347
40k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
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