Upgrade to Pro — share decks privately, control downloads, hide ads and more …

花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会

Avatar for iWonder118 iWonder118
June 21, 2025
3

花開くWebAssembly(Wasm)の可能性 in 2025/06/21 まさるの勉強会

Avatar for iWonder118

iWonder118

June 21, 2025
Tweet

Transcript

  1. デメリット システムAPIの制限 • Wasm単体ではファイルやネットワークへの直接アクセスができない • ホスト側のAPI提供に依存するため、環境によって差異が生じる 開発・デバッグの難しさ • デバッグツールやプロファイリング環境がまだ成熟していない。 (ローカル環境での開発難しい

    ....) • ソースマップやトレース情報の対応が言語やツールチェーンで限定的 対応していない言語機能や環境 • マルチスレッドや一部のシステムコールを完全サポートしていない • レガシーなC/C++コードの移植には制約や書き換えが必要な場合が多い ランタイムの多様化と互換性課題 • 複数のWasmランタイム間での完全な互換性や挙動保証がまだ課題 • WASIの標準化が進行中で、現時点で仕様差分が存在する
  2. エッジランタイムとしての Wasmの強み ライブマイグレーションの実現 • 実行中の状態を保持したままエッジノード間でワークロード移動が可能 • 従来のコンテナよりも高速かつ軽量に切り替えられる > ライブマイグレーションについて 動作中のプログラムやワークロードの実行状態(メモリの内容や

    CPUレジスタの状態など)を保持したまま、一つの実行環境 (ノード)から別の実行環境へ移動させる技術 サービスの停止時間をほぼゼロに抑えつつ、負荷分散やメンテナンスが可能 エッジ特化のシステムAPI拡張 • WASIを拡張し、エッジ環境固有のリソース(センサーや ローカルストレージ)へ安全にアクセス • 多様なエッジノードで同一の Wasmモジュールが動作可能
  3. エッジランタイムとしての Wasmの問題点 ARM x86 リソース制約の厳しさ • メモリ・CPUが限られているため重い処理に不向き Cloudflare WorkersではCPUが10〜30ms上限、メモリが最大128MB •

    大規模データ処理や複雑なアルゴリズムはパフォーマンス低下の可能性 状態管理の難しさ • ライブマイグレーションや分散状態の同期が技術的に複雑 • 状態を持つアプリケーションは設計・運用コストが増加 ランタイム互換性の課題 • Wasmランタイム間での挙動差異や APIの非標準化が存在 • 実行環境ごとに微妙な差異がバグや障害の原因になることも ランタイムA ランタイムB
  4. Open Telemetryとのコラボレーション うまく切り分けて動かせる分、監視が難しい • 一貫した監視・ロギング基盤の構築 OpenTelemetryはクラウドネイティブ標準で、多様なバックエンド( Jaeger, Prometheus, New Relic等)に対応

    • パフォーマンスボトルネックの特定が容易に Wasm特有の起動遅延や API呼び出しのコストを詳細に計測可能 • 運用の効率化・信頼性向上 エッジ環境の多数ノードにまたがる挙動の集約・分析が容易に そこでOpen Telemetry 一言でいうと共通規格でログを送れるやつ