エッジで動く WebAssembly のパフォーマンス最適化事例

エッジコンピューティングの普及にともない、より低レイテンシな処理をユーザーの近くで実現したいというニーズが高まっています。本記事では、Rust で実装した WebAssembly（Wasm）モジュールをエッジノードにデプロイし、API レスポンスタイムを平均 68% 削減した実践事例を紹介します。

課題：従来のオリジンサーバー処理の限界

従来のアーキテクチャでは、ユーザーのリクエストはエッジを素通りしてオリジンサーバーまで到達していました。日本国内のユーザーでも、海外リージョンのオリジンまで往復するケースでは RTT が 200ms を超えることがあり、体感速度に大きく影響していました。画像リサイズや認証トークン検証のような「軽量だが頻繁に行われる処理」をオリジンでやる必要はないはずです。

アプローチ：Rust → Wasm → エッジ

選択した言語は Rust です。理由は三つあります。第一にランタイムが不要で Wasm バイナリが小さいこと（今回は 180KB）、第二に GC ポーズがなく予測可能なレイテンシが得られること、第三にメモリ安全性がコンパイル時に保証されることです。

処理フローは次のとおりです。Rust コードを `wasm32-wasi` ターゲットでクロスコンパイルし、生成した `.wasm` ファイルをエッジランタイム（Fastly Compute）にデプロイ。エッジノードはリクエストを受け取ると Wasm モジュールを即座にインスタンス化し、処理結果をそのままレスポンスとして返します。コールドスタートは初回のみ発生し、以降はウォームインスタンスが再利用されます。

計測結果

• P50 レイテンシ：312ms → 98ms（68% 削減）

• P99 レイテンシ：890ms → 210ms（76% 削減）

• オリジンへのリクエスト数：月間 4.2億回 → 0.9億回（78% 削減）

• エラー率：変化なし（0.03%）

得られた知見

Wasm をエッジで動かす際の最大の落とし穴は、ファイルシステムや外部ネットワークへのアクセス制限です。今回は処理を「ステートレスな変換処理」に限定することでこの制約を回避しました。DB アクセスや外部 API 呼び出しが必要な処理はオリジンに残し、エッジは純粋な計算処理に徹するというアーキテクチャが現時点では最も安定します。

Wasm のエッジ活用はまだ発展途上ですが、適切なユースケースを選べば今すぐ大きな効果を得られます。NodeFlare では Wasm モジュールのエッジデプロイもサポート予定です。