引言
隨著生成式 AI（GenAI）技術的快速發展，企業對 AI 平臺的依賴度持續提升。然而，隨著系統規模擴展與多租戶需求的增加，認證與授權（Authentication and Authorization）成為影響平臺穩定性與安全性的關鍵因素。本文探討 SAP AI 基礎設施在 GenAI 平臺中面對的認證與授權挑戰，並分析其解決方案與技術選型策略，為企業在 CNCF 生態中構建可擴展的 AI 平臺提供參考。
平臺架構與技術基礎
SAP AI 基礎設施分為三個核心模組：訓練、服務、生成式 AI（GenAI），並依賴 CNCF 生態中的多項技術實現高效運作。
技術棧與架構設計
- 訓練模組：租戶提供容器鏡像與 GPU 資源，於 Kubernetes 節點執行模型訓練，結果儲存於 S3。
- 服務模組：租戶使用預訓練模型進行推理，透過 Kubernetes GPU 節點執行。
- 生成式 AI 模組：整合超過 40 個大型語言模型（LLM），提供統一介面，支援自建模型與合作夥伴模型。
- 集群管理：使用 Gardener 管理 Kubernetes 集群，支援多雲環境（Azure、AWS、Google Cloud 等）。
- 流量管理：ISTTO 負責流量管理與安全策略，Argo Workflows 管理訓練流程，KServe 支援模型服務。
認證與授權的挑戰與解決方案
1. Ingress Gateway 的 JWT 處理效能問題
- 問題：使用 JWT 進行租戶識別時，高負載下出現 60 毫秒延遲，影響每秒請求量（<20 req/s）。初始方案透過 Lure Filter 提取租戶資訊，但 Go SDK 支援終止導致不穩定。
- 解決方案：使用 Envoy 並配置外部 gRPC 服務處理 JWT 解析，獨立於 Lure Filter。透過外部處理器執行原生 Go 程式，提升效能。
- 教訓：Envoy Filter 在中低負載下表現良好，但高負載需外部處理器支援原生程式。
2. JWKS URI 查詢效能與資源消耗
- 問題：每個租戶使用不同 JWKS URI，初始方案透過授權策略（Authorization Policy）管理，導致 Sidecar 資源消耗過高（16GB 記憶體 + 5 核），高負載下延遲顯著增加。
- 解決方案：使用 OPA（Open Policy Agent） 進行策略邏輯外部化，搭配資料庫查詢與快取機制。
- 教訓：大量授權策略會導致資源浪費與延遲，需改用外部策略引擎。
3. LLM 訂閱與路由規則擴展性問題
- 問題：訂閱 LLM 時需透過 ID 查詢模型資訊，初始方案使用 Virtual Service 路由，導致 Envoy 資源消耗與延遲增加（數萬個 Virtual Service）。
- 解決方案：使用外部資料庫查詢 ID 對應資訊，並注入請求頭部。
- 教訓：路由規則數量與延遲呈線性關係，需改用資料庫查詢提升效能。
4. 日誌系統的 MTLS 與加密效能
- 問題：日誌系統使用 MTLS 進行通訊，高負載下（每日 1TB 資料）出現不穩定。關閉 MTLS 後系統正常，但安全性受影響。
- 解決方案：使用 Ambient 將加密下推至網路層（L4），避免 Sidecar 加密開銷。
- 教訓：高吞吐量系統避免 Sidecar 加密，改用原生協議（如 Ambient、WireGuard）。
5. 訓練流程的節點資源爭用
- 問題：Kubernetes Job 並行啟動時，CNI 初始化與 Pod 啟動存在競爭條件。主容器完成但 Sidecar 仍在執行，導致 Job 被視為未完成。
- 解決方案：
- 方案一：使用 Kubernetes 原生 Sidecar（Init Container）確保主容器完成前 Sidecar 並未啟動。
- 方案二：改用 ISTTO Ambient 模式移除 Sidecar 容器。
- 教訓：避免 Sidecar 與主容器並行執行，改用 Init Container 或 Ambient 模式。
6. 模型服務的初始化順序衝突
- 問題：Kserve 初始化容器下載模型時，Sidecar 未啟動導致無法訪問外部資源（如 S3）。
- 解決方案：
- 方案一：調整 Init Container 執行順序，確保 Sidecar 先啟動。
- 方案二：改用 Ambient 模式移除 Sidecar。
- 教訓：初始化順序衝突需透過 Taints/Tolerations 協調，或改用無 Sidecar 架構。
總結與技術選型建議
五項主要教訓
- 標準配置的限制：標準配置在低負載下表現良好，但高負載時可能出現異常。需根據工作負載和擴展需求進行定製化設置。
- 競態條件風險：ISTTO 初始化與工作負載初始化的順序可能導致預期外行為。需明確依賴關係，並透過 Taints/Tolerations 協調執行順序。
- 臨時解決方案的風險：當前 hacky 解決方案（如開放所有端口）可能引入安全漏洞，且在高負載下可能導致不穩定行為。建議長期優先使用原生解決方案。
- 持續更新與技術演進：釋出說明書中包含許多邊緣案例資訊，需持續關注。未來技術如 Ambient 模式和 Kubernetes 原生 Sidecar 是關鍵方向。
- 未來技術選型：對於高負載或 Jobs 類型工作負載，建議採用 Ambient 模式或 Kubernetes 原生 Sidecar，以提升可擴展性和安全性。
技術選型與實作建議
- 語言與協議：從 Go 轉為 Rust 提升程式碼維護性與穩定性，並透過 gRPC 整合外部處理器，實現高效資料查詢與標頭注入。
- 擴展性設計：避免 Sidecar 容器與主容器並行執行，改用 Init Container 或 Ambient 模式，降低資源消耗與延遲。
- 安全與效能平衡：在高吞吐量系統中，優先使用原生協議（如 Ambient、WireGuard）替代 Sidecar 加密，確保安全性與效能。
結語
GenAI 平臺的認證與授權設計需在安全性、效能與可擴展性之間取得平衡。透過 CNCF 生態中的技術（如 Envoy、OPA、Ambient 等），企業可有效應對多租戶與高負載挑戰。未來，隨著 Kubernetes 原生 Sidecar 與 Ambient 模式的成熟，將進一步推動 AI 平臺的穩定與可維護性。