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
22
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会
iWonder118
June 21, 2025
More Decks by iWonder118
See All by iWonder118
多摩川.dev OP&ED
iwonder118
0
260
今更RSCについてのお話 Full RSC vs RSC as Data Next.jsとTanStack Start比較
iwonder118
0
31
React Tokyo フェス 2026 の裏側
iwonder118
1
550
頑張ります!2026
iwonder118
0
74
イベント参加ふっかるになるための多摩川周辺.pdf
iwonder118
0
41
我々はなぜ中間表現を作るのか
iwonder118
0
870
OODAループを回すVibe_Coding.pdf
iwonder118
0
21
Reactで見る!純粋関数で深ぼる副作用
iwonder118
0
640
SSG___CSRで乗り切るiframe内ルーティング_AIコーディング拡張版_in_Funabashi.dev.pdf
iwonder118
0
54
Featured
See All Featured
How to Ace a Technical Interview
jacobian
281
24k
Design in an AI World
tapps
1
240
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Amusing Abliteration
ianozsvald
1
200
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Between Models and Reality
mayunak
4
340
New Earth Scene 8
popppiees
3
2.3k
A Tale of Four Properties
chriscoyier
163
24k
Writing Fast Ruby
sferik
630
63k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
230
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
840
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