引言
在雲原生時代，Serverless 架構因其自動擴縮容與低成本特性廣受歡迎，但其無狀態、短生命週期的特性也帶來了可觀測性挑戰。Shopify 為全球電商平臺，面對跨區域流量與高可用性需求，需建立強大的指標處理架構。本文探討其如何透過 CNCF 生態工具，整合 metrics instrumentation、ingestion 與 platform，實現 Serverless 環境下的可觀測性規模化。
技術與架構解析
Serverless 與可觀測性的核心挑戰
Serverless 架構中，應用程式以容器形式執行於雲端，其短暫生命週期與自動擴縮容特性，使傳統監控工具難以追蹤。Shopify 面對的關鍵需求包括：
- 高吞吐量：峰值時每秒處理 100GB 日誌、1200 萬 spans、3.5 億 metrics samples
- 跨區域一致性：需確保全球流量下的服務可用性與指標準確性
- 成本與效能平衡：在自動擴縮容模式下，避免資源浪費與資料遺失
指標處理架構設計
Shopify 以 Kubernetes 為基礎，結合 Cloud Run 建立 Serverless 應用，並透過以下技術實現指標處理：
1. 指標協議與轉換
- StatsD 與 OTLP 協議整合：現有 Ruby 應用使用 StatsD（text-based 協議），新服務則採用 OpenTelemetry（OTLP）。為解決協議差異，自建 otel-collector 分支實現 StatsD 轉換，後整合至 upstream 版本。
- D-Sketch 聚合技術：透過內存結構實現跨來源 histogram 數據合併，降低 cardinality 問題，支援跨服務指標聚合。
2. Sidecar 架構與資料傳輸
- Cloud Run 應用側車（sidecar）：應用透過 sidecar 收集指標，StatsD 透過 UDP 傳輸，OTLP 則使用 loopback 接口。資料經批處理與壓縮後，透過公共入口（public ingress）傳輸至集群。
- Delta 暫存機制：確保指標時序正確性，避免資料遺失。處理邏輯採用 delta 暫存而非 cumulative，並在傳送前進行聚合。
3. 指標路由與轉換
- Metric Router 整合 Kubernetes：轉換 StatsD 到 Prometheus 兼容格式，並透過 D-Sketch 進行聚合。OpenTelemetry 轉換庫（data dog mapping）實現 OTLP 到 D-Sketch 格式。
- 標籤控制策略：透過 otel-collector 刪除冗餘 label，保留關鍵標籤（如 ABC），降低指標複雜度。
CNCF 生態整合與擴展性
- Prometheus 生態兼容性：指標最終整合至 Prometheus 支援的伺服器，實現即時監控與分析。
- 背壓處理與自動擴縮容：事件驅動式 KDA（Kubernetes Dynamic Autoscaling）應對高流量場景，後續將增強背壓機制提升系統穩定性。
- MTLS 自動認證：取代現行 basic auth，提升日誌與指標平臺的安全性。
挑戰與解決方案
網路與資料傳輸問題
- 網路隔離：Cloud Run 服務位於非 peered 網路，需透過公共入口傳輸資料，導致傳輸效率下降。
- 資料遺失風險：Cloud Run 容器終止前 10 秒 grace period 可能導致資料未完全傳送，需優化 Collector 刷新間隔與容器啟動順序。
系統穩定性與效能
- Collector 調整：降低 otel-collector 刷新間隔，確保資料即時性。
- 容器啟動控制：確保 Collector 就緒後才啟動應用，避免資料處理中斷。
後續步驟與技術優化
可觀測性擴展
- 日誌平臺整合：將 observe 平臺整合至 Cloud Run，實現 logs/traces/metrics 全流程監控。
- 指標處理流程優化：直接於 otel-collector 層級處理 cardinality 控制，簡化轉換至 Prometheus 的步驟。
系統擴展性提升
- 事件驅動式自動擴縮容：改進 KDA 以應對異常流量。
- 完整 metrics pipeline：建立涵蓋 logs/traces/metrics 的端到端處理流程。
總結
Shopify 的 Serverless 指標處理架構體現了 CNCF 生態工具的強大整合能力。透過 D-Sketch 聚合、Delta 暫存、OTLP 轉換等技術，解決了 Serverless 環境下的可觀測性挑戰。未來需持續優化背壓機制與自動擴縮容策略，以確保系統在高流量場景下的穩定性與擴展性。此案例為雲原生架構下指標處理提供了可參考的實踐方向。