跳到主要內容
AI News HubLIVE
站內改寫1 分鐘閱讀

基於Pingora、Envoy和Spanner的無服務器服務器路由

文章摘要

Modal團隊深入介紹了其新型超低延遲Serverless Servers的設計原理和實現細節,該服務針對LLM推理等對延遲敏感的應用進行了優化。文章解釋了為何選擇構建自己的代理層fprs,以及如何通過Pingora庫、Envoy邊緣代理和Spanner全局數據庫實現無網絡調用熱路徑、動態域名關聯和自動縮放。

基於Pingora、Envoy和Spanner的無服務器服務器路由
報告錯誤

更正渠道尚未開通,可先複製下方文章資訊留存。

查看更正說明
直接讀正文

Modal近日發佈了其新型Serverless Servers服務,旨在為超低延遲應用(如大型語言模型推理)提供支持。該服務允許用户在Modal上運行HTTP、WebSocket和gRPC服務器,並實現區域化自動縮放。

與Modal已有的Web Functions不同,Servers採用了更輕量級的架構。Web Functions內置了排隊和重試機制,類似於TCP協議;而Servers則更接近UDP,犧牲了這些可靠性特性以換取更低的延遲。如果所有副本都不可用,客户端將直接收到503錯誤,而不是等待隊列。這種設計對於LLM推理等對延遲極其敏感的應用場景尤為合適。

Modal團隊在構建Servers時遵循了兩條核心原則:最大化資源共享同時最小化干擾,以及確保請求路徑上沒有網絡調用。這意味着路由層不能訪問元數據存儲或鍵值存儲,配置信息必須本地緩存。團隊通過精細的微觀調整,將代理資源的使用與宏觀目標對齊,避免了因資源池化導致的干擾問題。

具體實現上,請求首先到達AWS NLB(四層負載均衡器),然後由Envoy代理終止TLS並統一轉換為HTTP/2流。接下來,Modal自研的fprs代理負責將域名映射到具體的Server應用,並在副本之間進行負載均衡。fprs基於CloudFlare的Pingora庫構建,利用Rust的Tokio運行時實現高效的流複用和資源隔離。團隊還解決了因域名頻繁更換導致的隱藏DNS解析問題,通過仔細緩存來保證尾延遲。

配置信息存儲在Google Spanner中,但fprs維護了一個內存緩存,並通過Spanner的變更流保持同步,從而避免了熱路徑上的數據庫查詢。該層還負責向Modal自動縮放器發送指標(每個容器的正在處理請求數),以及實現代理層身份驗證,防止大量無效請求觸發昂貴的GPU實例啓動。

Modal表示,雖然系統針對LLM推理進行了優化,但設計上並不侷限於這一場景。未來他們計劃在路由層添加可選的排隊和重試功能,讓用户能夠根據需求在低延遲和可靠性之間取得平衡。

展開要點與分析

文章情報

工程師進階

要點

  • Modal推出Serverless Servers,專為超低延遲HTTP/WebSocket/gRPC流量設計。
  • 與Web Functions不同,Servers犧牲了排隊和重試以換取更低延遲。
  • 架構包括AWS NLB、Envoy邊緣代理、基於Pingora的自研代理fprs,以及Spanner配置存儲。
  • 核心原則:最大化資源共享同時最小化干擾,並且在請求路徑上不進行網絡調用。

要點與分析由自動化流程生成,可能有誤,請結合原始來源核實。