Pingora、Envoy、Spannerを使ったサーバーレスサーバーのルーティング

Modalは、超低遅延アプリケーション（特に大規模言語モデル推論）向けに、新たなServerless Serversサービスをリリースしました。このサービスにより、ユーザーはModal上でHTTP、WebSocket、gRPCサーバーを実行し、リージョナルな自動スケーリングを利用できます。

既存のModal Web Functionsとは異なり、Serversはより軽量なアーキテクチャを採用しています。Web Functionsはキューイングとリトライを内蔵し、TCPプロトコルに似ています。一方、ServersはUDPに近く、信頼性機能を犠牲にして低遅延を実現します。すべてのレプリカが利用不可の場合、クライアントはキュー待ちではなく503エラーを直接受け取ります。このトレードオフは、低遅延LLM推論のようなアプリケーションにおいて特に有効です。

ModalチームはServersを構築するにあたり、2つの基本原則に従いました。リソース共有を最大化しつつ干渉を最小化すること、そしてリクエストパス上でネットワークコールを行わないことです。そのため、ルーティング層はメタデータストアやキーバリューストアにアクセスできず、設定情報はローカルにキャッシュする必要があります。チームは、接続プールやストリーム多重化による干渉を避けるため、徹底的な微調整を行いました。

具体的な実装としては、リクエストはまずAWS NLB（L4ロードバランサー）に到達し、次にEnvoyプロキシがTLSを終端してHTTP/2に統一します。その後、Modal独自のfprsプロキシがドメインを特定のサーバーアプリケーションにマッピングし、レプリカ間で負荷分散を行います。fprsはCloudFlareのPingoraライブラリ上に構築され、RustのTokioランタイムを活用して効率的なストリーム多重化とリソース分離を実現しています。さらに、ドメインの頻繁な変更に伴う隠れたDNS解決の問題を解決するため、注意深いキャッシュ戦略を採用しました。

設定情報はGoogle Spannerに保存されますが、fprsはメモリ内キャッシュを維持し、Spannerの変更ストリームを使用して同期を保つことで、ホットパス上のデータベースクエリを回避しています。この層はまた、Modalのオートスケーラーに指標（コンテナあたりの処理中リクエスト数）を送信し、プロキシレベルでの認証を実装して、高価なGPUインスタンスの無駄な起動を防ぎます。

Modalは、本システムはLLM推論向けに最適化されているものの、特定のワークロードに限定されるものではないと述べています。将来的には、ルーティング層にオプションのキューイングとリトライ機能を追加し、ユーザーが低遅延と信頼性のバランスを選択できるようにする計画です。