WASM、新しいCGI技術

 (roborooter.com)
3 ポイント 投稿者 GN⁺ 2024-10-11 | 1件のコメント | WhatsAppで共有

Wasmは新しいCGI

  • Wasmの役割: Wasm（WebAssembly）は、Webアプリケーションモデルに新たな変化をもたらす準備が整っている。これは、高性能なアプリケーションを簡単に構築・維持できるようにすることに重点を置いている。
  • 過去のWebアプリケーションモデル: CGIは、Webをドキュメントアーカイブからアプリケーションネットワークへと変えた。FastCGIは性能問題を解決するために開発され、その後サーバーレスコンピューティングへと発展した。
  • サーバーレスコンピューティング: Amazon Lambdaのようなサーバーレスコンピューティングでは、サーバー管理の代わりに「関数」を管理する。これにより、リクエスト量に応じて素早くスケールできる利点がある。

サーバー上のWasm

  • Wasmの拡張性: Wasmはブラウザーだけでなくサーバー上でも実行でき、サーバーサイドアプリケーションにより軽量な分離モデルを提供する。
  • Wasm実行環境: Wasmモジュールは仮想マシン上で実行され、さまざまな言語からコンパイル可能である。これはサーバーレス環境での性能向上に寄与する可能性がある。

Wasmのトレードオフ

  • スレッドとJITコンパイル: Wasmはスレッドを標準ではサポートしておらず、JITコンパイルも不可能である。これは性能に影響を与える可能性がある。
  • メモリーインターフェース: Wasmモジュールとホスト間のデータ移動ではコピーが必要になることがあり、これが性能に影響する可能性がある。

将来展望

  • Wasmの発展: Wasmの実行環境と開発ツールが発展するにつれて、スクリプト言語もWasmランタイムを備えるようになるだろう。これにより、アプリケーションの実行速度を大きく向上させられる可能性がある。
  • エッジコンピューティング: Wasmはエッジコンピューティングを通じて、ユーザーの近くで計算を実行できるようにし、性能を向上させる。

# GN⁺の要約

  • WasmはWebアプリケーションモデルの新たな変化を牽引しており、高性能なアプリケーションを簡単に構築・維持できるようにする。
  • サーバーレスコンピューティングとWasmの組み合わせは、サーバー管理の複雑さを減らし、リクエスト量に応じて素早くスケールできる利点をもたらす。
  • Wasmはブラウザーだけでなくサーバー上でも実行でき、サーバーサイドアプリケーションにより軽量な分離モデルを提供する。
  • Wasmの発展により、スクリプト言語がWasmランタイムを備えるようになり、アプリケーションの実行速度を大きく向上させられる可能性がある。
  • エッジコンピューティングを通じてユーザーの近くで計算を実行できるようになり、性能向上につながる。

関連記事

1件のコメント

 
GN⁺ 2024-10-11
Hacker Newsのコメント

  • Amazon は Lambda によってサーバーレスコンピューティング時代を切り開いた。Google App Engine は Lambda より 6 年早くリリースされていた。

  • WASM と、Java Applets、ActiveX、Silverlight、Macromedia Flash のような過去の技術との違いを理解するのは難しい。Web ブラウザーで信頼できないサードパーティのコンパイル済みコードを実行することについて、私たちはすでに教訓を学んだと思っていた。

  • JIT コンパイルは、セキュリティ上の理由で動的な WASM コード生成が許可されていないため不可能だ。これはコードのホットリロードのような作業をきれいに行ううえで不可欠な機能だ。

  • セキュリティに関する主張は信頼できないと思う。ランタイムで JS をホットリロードしたりコード生成したりできるし、WASM ランタイムを動的にリロードしてメモリを維持することもできるが、ユーザー体験は不便になるだろう。

  • 技術的に不可能な理由は見つからなかった。セキュリティ対策だとしても、簡単に回避できるはずだ。

  • WASM バイトコードは、.NET IL や Java バイトコードなど、JIT コンパイル向けに設計されたものと概念的に似ている。

  • WASM プロジェクトには明確な方向性と成功への意志が欠けていると思う。基本的な機能がまだ不足している。

    • ホットリロード、ハック不要のスレッディング、DOM とのネイティブインターフェース、低オーバーヘッドのグラフィックス／コンピューティング API のサポート、低レベルのオーディオアクセスなどが含まれる。

  • WASM は、特定の言語向け VM を汎用 VM に置き換えるものだ。つまり、コンパイラーやインタープリターでほぼ何でも実行できる。

    • 一般的には JavaScript エンジンの一部として実装され、サンドボックス化と API アクセスを継承している。標準化は進行中だ。

  • WASM は JavaScript の代替、Docker の代替、Java の代替、CGI の代替などとして語られている。つまり何にでもなろうとしている。

  • WASM は PHP アプリケーションのように簡単にホスティングおよびデプロイできるべきだと思う。まだそこまでにはなっていないだろう。

  • ソフトウェアの古い法則を思い出させる。十分に大きく古いアプリケーションは、最終的に実行中のソフトウェアスタック全体を再実装することになる。

  • サーバー側 WASM の大きな約束は、定期的な更新を必要としない永続的なプラットフォームを提供することだ。

    • Node.js や Python のバージョンがサポート終了になるたびに AWS Lambda アプリを更新して再デプロイするのは大きな問題だ。

  • ローカルファーストこそ未来だと思う。アプリは主にユーザーのブラウザー内で動作し、サーバーの助けはほとんど必要としない。

    • Figma、Linear、Superhuman のようなアプリがこのモデルをうまく使っている。

  • WASM はユーザーのブラウザーで成功できる。Microsoft はこれを C#/Blazor に使っている。

  • JVM とそのエコシステムを再発明しているように見える。

  • WASM はクラウドでラムダ関数の実行コードを置き換える方向に進むと思う。

    • WASM は伝統的にホストプラットフォーム上で実行されるものと見なされているが、必ずしもそうである必要はない。

    • WASM のサンドボックス特性のおかげで、オペレーティングシステムの外部や ring0 で実行できる。