WebAssembly×Rustで構築するリアルタイム動画ストリーミングAPIプラットフォーム

プロジェクト背景

近年、リモート会議やオンラインイベント、ライブコマースなどリアルタイム動画配信の需要が急増しています。一方で、従来のソリューションはJavaScriptやGo、Javaなどのランタイム上で実装されることが多く、パフォーマンスやメモリ消費、並列処理の面でボトルネックを抱えがちです。本プロジェクトでは、WebAssembly（Wasm）を活用してクライアントサイドだけでなくサーバーサイドにもWasmモジュールを組み込み、高速かつ低レイテンシな動画エンコード・トランスコード処理をRustで実装することで、リアルタイムストリーミングAPIプラットフォームを構築しました。開発ノートとして、要件定義からアーキテクチャ設計、実装、テスト、運用に至るまでの技術的考察とベンダー選定時のポイントをまとめます。

技術スタックと全体アーキテクチャ

本プラットフォームは大きく「Wasm実行基盤」「Rustストリーミングエンジン」「APIゲートウェイ」「データプレーン」の四層で構成します。

• Wasm実行基盤：Wasmtimeをカスタムビルドし、サーバーサイドでWasmモジュールを安全にサンドボックス実行。クライアント側ではブラウザのWasmランタイムを利用し、エンコード前のプリプロセスを高速化。

• Rustストリーミングエンジン：FFmpegのRustバインディング（ffmpeg-next）を用い、動画パケットのデマルチプレクス・トランスコードを非同期tokioランタイム上で並列処理。Wasmモジュールの呼び出しAPIでビデオフィルタやエフェクトを動的適用可能。

• APIゲートウェイ：Envoy ProxyをL7プロキシとして配置し、gRPC-WebとREST両対応のフロントエンドを提供。Wasmフィルターを使った認証・認可処理やリクエストメトリクス収集を実装。

• データプレーン：NATS Streamingで動画セグメントを配信し、クライアントの再生バッファとのインタラクションを低レイテンシで実現。キャッシュにはRedis Streamsを組み合わせ、複数リージョン間でのフェイルオーバーをサポート。
  TerraformとHelmを用いたInfrastructure as Codeでクラウド環境を管理し、ステージングと本番で同一構成を保証。GitHub ActionsによるCI/CDパイプラインで、コード変更→Wasmビルド→コンテナイメージ作成→マニフェスト適用までを自動化しました。

WebAssemblyランタイムのカスタマイズ

サーバーサイドWasm実行基盤には、WasmtimeのEngineをカスタマイズビルドし、ホスト関数（WASI）からFFmpegバインディングへのブリッジを定義。Wasmモジュールは事前コンパイルしてバイナリキャッシュし、Cold Startを20ms以下に最適化。マルチテナント環境下では、各テナント専用のWasmモジュールレジストリを用意し、バージョン切り替えやロールバックをAPI経由で安全に管理できます。
また、Wasmモジュール内ではUnsafe Rustを極力排除し、メモリ安全性を確保。モジュール間呼び出しでは、Interface Typesを活用し、複雑なデータ構造（動画メタデータ、フィルタパラメータ）の効率的なシリアライズを実現。MVP段階ではSDPやHLSセグメントの動的生成をWasmで行い、クライアント側でWasmモジュールを直接呼び出して部分的にフィルタ処理を分散させるPoCも実施しました。

Rustストリーミングエンジンの設計パターン

動画デマルチプレクサー、デコーダー、エンコーダー、パケットマルチプレクサーをアクティビティ的に分離し、tokioのWorker Poolで並列フェーズ実行。各ステップごとにメトリクスをPrometheusへ出力し、Grafanaでリアルタイム監視。
エラーハンドリングには、ffmpeg-nextのResult型をラップし、NonRetryableErrorを定義。HLS配信時のセグメント生成失敗は自動リトライ、DRMキー取得エラーはフォールバック用のプレーンHLS URL返却するなど、フェイルセーフ設計を徹底しました。
非同期ストリーム処理ではfutures::Streamを用い、Batched Streamパターンで複数コマンドを同時実行。Backpressure制御はtokio::sync::Semaphoreでキュー長を調整し、メモリバーストを抑制。これにより、1,000同時セッション規模でも80ms以下のエンドツーエンドレイテンシを達成しました。

API設計とGraphQL統合

APIゲートウェイ層では、RESTとGraphQLを併存させ、クライアントの要件に応じて選択可能としました。GraphQLスキーマはコードファーストでRustマクロ（async-graphql）を活用し、動画ストリームのメタデータ、セグメントURL、再生状態を型安全に取得。RESTエンドポイントはnghttp2ベースのgRPC-Web対応として実装し、Protobuf定義から自動生成されたクライアントライブラリを提供しました。
APIにはRBACとJWT認証を組み込み、トークン内のカスタムクレーム（視聴権限、テナントID）をGraphQLコンテキストへ注入。リクエストごとに認可チェックを行い、未認可リクエストは401で即時拒否。ThrottleミドルウェアをEnvoyで設定し、1ユーザーあたりのAPI呼び出し上限を秒間10リクエストに制限することで、不正利用やDDoS攻撃を防止しました。

スケーラビリティと負荷分散アプローチ

動画配信プラットフォームの核心となるデータプレーンには、NATS Streamingクラスタを用い、各リージョンのEdgeサーバー間で動画セグメントをプッシュ配信。IngressはEnvoyのL4ロードバランサーでTCPレイヤーで分散し、HTTP/2グローバルLoad BalancerはGCPのTraffic Directorを採用。
StatefulなストリーミングエンジンはKubernetes StatefulSetでマネージし、PersistentVolumeClaimにはCeph RBDを利用してスケールアウトを実現。CDNキャッシュが温まるまでのバーストトラフィックはEdgeキャッシュ機構で吸収し、キャッシュヒット率90%以上を維持。Redis Clusterでセグメントメタをキャッシュし、DBアクセスを100ms以下に抑えることで、高い同時接続数にも耐えられるプラットフォームを実現しました。

テスト戦略とCI/CD統合

ユニットテストでは、Rust版のffmpeg-nextラッパーやWasmブリッジ関数をmockallでモックし、映像フォーマット変換とパラメータ適用ロジックを網羅的に検証。GraphQL APIはasync-graphqlのIntegration Test機能でミドルウェアや認可チェックを含めたエンドツーエンドテストを実行。
CIパイプラインはGitHub Actionsを採用し、cargo fmt、cargo clippy、cargo test、wasmtime test、docker build、helm lint、kustomize buildを並列実行。プルリクエスト合格条件にE2E Smoke Test（Playwrightで再生サンプル動画の再生確認）を設定し、マージ前に必ず動作確認が完了するフローを構築しました。

パフォーマンスチューニングとキャッシュ戦略

サーバーサイドWasmモジュールの起動コストを抑制するため、インスタンスプールを維持し、モジュールのプリウォームを行います。特定の動画処理モジュールは、常駐ワーカーとして定期的に呼び出しテストを実施し、Cold Startを防止。さらに、WasmバイトコードはContent Addressable Storageにキャッシュし、各ノードで高速に取得できる仕組みを導入しました。
動画セグメントについては、エンコード後の HLS/DASH セグメントをEdge キャッシュ（CDN）に配置し、HTTP/3＋QUIC を使ったプッシュ機能でクライアント側バッファを即時ウォームアップ。キャッシュヒット率が向上すると、オリジンへの負荷が急激に下がり、ピーク時でも安定した配信性能を維持できます。

セキュリティ設計とアクセス制御

Wasm モジュールはサンドボックス内で実行されるものの、ハイパフォーマンスを重視するため、ホスト関数との境界を厳格に定義。WASI 標準インターフェースを限定し、ファイルシステムやネットワークアクセスを必要最小限に抑えています。
API レイヤーでは、Envoy の JWT フィルターで OAuth2.0 トークンを検証し、各リクエストの「再生権限」「テナント境界」をチェック。Abuse Detector ミドルウェアでリクエスト頻度を監視し、攻撃検知時には動的に IP ブロックリストを適用します。

モニタリングとログ集約

Wasm 実行レイヤーからは Prometheus メトリクスをエクスポートし、「モジュールロード時間」「アクティビティ呼び出し数」「メモリ使用量」を可視化。Rust ストリーミングエンジンは OpenTelemetry でトレースを送出し、Jaeger ダッシュボード上で処理パスを可視的に把握できます。
ログは構造化 JSON 形式で Fluentd を使い収集、Elasticsearch／Kibana に集約。動画配信エラーやセグメント欠落は Kibana アラートルールで即時通知し、障害の兆候を SRE チームへリアルタイムにフィードバックします。

運用保守とSRE体制構築

オンコール体制は 4 週間ローテーションで、Runbook を Confluence に集約。ノード障害発生時の kubectl drain／cordon 手順や、Wasm モジュールキャッシュクリアスクリプトを具体的に掲載しています。
四半期ごとにゲームデイ（故障注入演習）を実施し、Temporal を用いたワークフローと同様に「Wasm 実行基盤の再起動」「キャッシュ不整合の修復」をテスト。インシデント管理ツール（JIRA）と連動し、振り返りを必ず実施します。

コストシミュレーションと予算管理

初期構築費用は要件定義300万円、アーキテクチャ設計400万円、Rust＋Wasm 実装800万円、CI/CD 自動化200万円、テスト＆POC300万円の合計約2,000万円を想定。
ランニングコストは、クラウド Compute（Fargate/EKS）30万～50万円／月、CDN キャッシュ10万～20万円／月、モニタリングツールライセンス5万～10万円／月で、年間約600万～960万円と試算。AWS Budgets でタグ別に配賦し、月次レポートを Slack 連携で通知します。

システム 開発会社 選び方 予算 費用 相場 発注

Wasm×Rust ベースの動画ストリーミング基盤開発を依頼する際は、以下のポイントで複数社に見積もり依頼を行いましょう。

1. Wasm 実行基盤実績：Wasmtime カスタマイズやサンドボックス運用例

2. Rust 並列処理力：tokio／FFmpeg バインディング運用経験

3. CDN／Streaming 知見：HTTP/3、QUIC、NATS／Redis Streams 統合事例

4. CI/CD 自動化：Wasm ビルド、コンテナイメージ最適化パイプライン

5. 可観測性設計：Prometheus＋OpenTelemetry 導入実績

6. 契約モデル：固定価格・時間単価の双方提示可否

費用相場は、小規模（1,000万～1,500万円）、中規模（2,000万～3,000万円）、大規模（3,500万～5,000万円）をベンチマークし、開発予算と費用対効果を比較検討しましょう。

まとめと今後の展望

WebAssembly×Rust によるリアルタイム動画ストリーミング API プラットフォームは、高性能かつ低レイテンシな動画配信を実現し、従来のランタイムに比べメモリ消費やホットパスのボトルネックを大幅に改善します。
今後は、WASI-HTTP の普及や Edge Compute×Wasm の融合が進み、エンコーダーを CDN エッジで動かす「エッジトランスコード」や、AI ベースのリアルタイムフィルタリング（顔認識／モザイク処理）をサーバーレスで組み込むことも現実的になります。まずは PoC を通じて性能・運用性を検証し、複数社の見積もりを比較して最適パートナーと本格導入を進めましょう。見積もり依頼はこちらからどうぞ。