6月25日、Modalが「Routing for serverless servers with Pingora, Envoy, and Spanner」と題した記事を公開した。サーバーレス環境でHTTPリクエストをミリ秒単位で処理するために、Pingora・Envoy・Spannerを組み合わせて構築したルーティング基盤の設計と実装を詳しく紹介している。
LLM推論の普及によって、サーバーレスプラットフォームに求められる要件は大きく変わりつつある。チャットや補完APIのようなインタラクティブなユースケースでは、数十ミリ秒の差が体感品質を左右する。Modalがこのブログ記事を公開した背景には、既存のアーキテクチャでは対応しきれなかった「低レイテンシ」という要求がある。
Web FunctionsからModal Serversへ
Modalはもともと「Web Functions」というHTTPエンドポイントの仕組みを提供してきた。キューイング・リトライ・リクエストライフサイクル管理を含む堅牢な設計だったが、その分レイテンシが高かった。
新機能「Modal Servers」はその対極に位置する設計だ。記事中では「Web FunctionsをTCPに例えるなら、Modal ServersはUDP」と表現されている。リトライやキューイングはアプリケーション層に委ねる代わりに、ルーティングのオーバーヘッドを徹底的に削る。レプリカが空いていなければ503 Service Unavailableを即座に返す設計で、可用性よりレイテンシを優先する。
アーキテクチャを貫く2つの原則
新しいルーティング層の設計は、2つの原則に支配されている。
- リソースの共有を最大化しつつ、テナント間の干渉を最小化する
- リクエストパスでネットワーク呼び出しを一切行わない
2番目の原則が実装の難度を大きく引き上げた。メタデータのフェッチも、KVストアの参照もなし。その代わり、ルーティング層の内部にインメモリキャッシュを持ち、グローバルな状態と非同期に整合を取る構造になっている。
3層で構成されるルーティングスタック
L4層：AWS NLB
クライアントとの接続はAWS Network Load Balancer（NLB）で受ける。L4（TCP）レベルで動作し、シンプルな負荷分散のみを担う。
L7エッジ層：Envoy
EnvoyがTLSを終端し、全HTTPトラフィックをHTTP/2に正規化する。HTTP/2の多重化によって、複数のクライアントストリームを1本のTCP接続に束ねることができ、接続数のスケールをクライアント数ではなく総負荷に比例させる。
ただしEnvoyだけではModalが必要とする機能（ドメイン関連付け、動的レプリカへの振り分け、認証など）を実装できなかった。そこでEnvoyはエッジに留め、独自プロキシを別途構築した。
インテリジェントプロキシ層：fprs（Pingora製）
このアーキテクチャの中核がModalがRustで自社開発したプロキシfprsだ。CloudFlareが開発・OSS公開しているPingoraライブラリをベースに構築されている。PingoraはTokioランタイム上に構築されており、ワークスティーリングとRustの軽量コルーチンモデルの組み合わせが「共有リソースと共有障害を切り離す」のに適していると記事では説明されている。
NginxやHAProxyではなくPingoraを選んだ直接の理由は、ユーザーがサービスやレプリカを動的に作成・削除する際の急速なアップストリーム変動への対処という独自要件にある。NginxはModal規模の動的なアップストリーム変動に対応しきれず、Pingoraのプログラマブルなアーキテクチャが要件に合致した。
fprsが担う機能は多岐にわたる：
- ドメイン関連付けとロードバランシング：URLのドメインコンポーネントからModalのコンピュートプレーン上のレプリカへのマッピング
- オートスケーリングメトリクスの発行：コンテナごとのインフライトリクエスト数を計測し、Autoscalerに送信。
target_concurrencyを超えたらスケールアップ、下回ったらスケールダウン - プロキシ認証：リクエストがユーザーコンテナに到達する前に認証を行い、高価なGPUインスタンスを起動する前に401を返せるためDoS耐性の向上にも寄与する
- ミラーリング：A/Bテストや継続学習向けに本番トラフィックをシャドウ転送する機能をファーストクラスでサポート
設定管理にSpannerを選んだ理由
fprs自体はステートレス設計だが、url: hostのマッピングという「設定」は状態を持つ。しかもユーザーがサービスを頻繁に作成・破棄するため、この設定の更新頻度が非常に高い。設定ミスによる障害リスクが常に存在するという課題だ。
Modalはこの問題にGoogle Cloud Spanner（Googleの分散リレーショナルDB）を採用した。ホットパスではSpannerを参照せず、インメモリキャッシュを維持し、SpannerのChange Streamで非同期に更新する構成だ。Spannerの外部一貫性保証が、複数のfprsインスタンス間で設定の整合性を維持するために機能している。
実装中には予期しない問題も発生した。ドメインのターンオーバー速度が通常より速いため、DNSの隠れた解決パスが散発的なストールを引き起こすケースがあり、慎重なキャッシュ戦略で対処したという。
NVIDIA DynamoやNginxとの比較
記事では競合技術との比較も言及されている。NVIDIA Dynamoやllm-dはLLM推論に特化しており、他ワークロードへの対応が難しい。ModalはLLM推論だけでなく、汎用コンピュートプラットフォームとして多様なワークロードを処理する必要があるため、これらは選択肢にならなかった。NginxはAWS NLBとの組み合わせで運用経験はあったものの、動的なアップストリーム変動への対応という独自要件を満たせず、最終的にPingoraを選んで自社実装に踏み切った。
LLM推論の低レイテンシ要求がインフラ設計の「常識」を塗り替えつつある現在、Modalのこの取り組みはサーバーレスプラットフォームの進化を示す一つの事例として参考になる。
詳細はRouting for serverless servers with Pingora, Envoy, and Spannerを参照していただきたい。
