雲原生體系下 Serverless 彈性探索與實踐

語言: CN / TW / HK

作者:競霄

Serverless 時代的來臨

1.png

Serverless 顧名思義,是一種“無服務器”架構,因為屏蔽了服務器的各種運維複雜度,讓開發人員可以將更多精力用於業務邏輯設計與實現。在 Serverless 架構下,開發者只需要關注於上層應用邏輯的開發,而諸如資源申請,環境搭建,負載均衡,擴縮容等等服務器相關的複雜操作都由平台來進行維護。在雲原生架構白皮書中,對 Serverless 的特性有以下概括:

  • 全託管的計算服務, 客户只需要編寫代碼構建應用,無需關注同質化的、負擔繁重的基於服務器等基礎設施的開發、運維、安全、高可用等工作;

  • 通用性, 能夠支撐雲上所有重要類型的應用;

  • 自動的彈性伸縮, 讓用户無需為資源使用提前進行容量規劃;

  • 按量計費, 讓企業使用成本有效降低,無需為閒置資源付費。

2.png

回顧整個 Serverless 的發展歷程,我們可以看到從 2012 年首次提出 Serverless 概念為起點,再到 AWS 推出 Lambda 雲產品的這段時間內,人們對 Serverless 的關注度出現了爆發式的增長,對無服務器的期待和暢想逐漸引爆整個行業,但 Serverless 的推廣和生產落地的過程卻不容樂觀,Serverless 理念與實操生產的過程中存在 Gap,挑戰着人們固有的使用體驗和習慣。

阿里雲堅信 Serverless 將作為雲原生之後確定性的發展方向,相繼推出了 FC、SAE 等多款雲產品來覆蓋不同領域,不同類型的應用負載來使用 Serverless 技術,並且不斷在推進整個 Serverless 理念的普及與發展。

3.png

就當前 Serverless 整個市場格局而言,阿里雲已經做到了 Serverless 產品能力中國第一,全球領先,在去年 Forrester 評測魔力象限中可以明顯的看到阿里雲在 Serverless 領域已經與 AWS 不相上下,於此同時,阿里雲 Serverless 用户佔比中國第一,在 2020 年中國雲原生用户調研報吿中整個阿里雲 Serverless 用户佔比已經達到了 66%,而在 Serverless 技術採用情況的調研中表明,已經有越來越多的開發者和企業用户將 Serverless 技術應用於核心業務或者將要應用於核心業務之中。

Serverless 彈性探索

4.png

彈性能力作為雲的核心能力之一,所關注的問題是容量規劃與實際集羣負載間的矛盾,通過兩幅圖的對比可以看到,如果採用預先規劃的方式進行資源安排,會由於資源準備量和資源需求量的不匹配導致資源浪費或者資源不足的情況,進而導致成本上的過多開銷甚至業務受損,而我們期望極致彈性能力,是準備的資源和實際需求的資源幾乎匹配,這樣使得應用整體的資源利用率較高,成本也隨業務的增減和相應的增減,同時不會出現因容量問題影響應用可用性的情況,這就是彈性的價值。

彈性其實現上分為可伸縮性和故障容忍性,可伸縮性意味着底層資源可以參照指標的變化有一定的自適應能力,而故障容忍性則是通過彈性自愈確保服務中的應用或實例處於健康的狀態。 上述能力帶來的價值收益在於降成本的同時提升應用可用性,一方面,資源使用量貼合應用實際消耗量,另一方面,提升峯值的應用可用性,進而靈活適應市場的不斷髮展與變化。

下面將對當前較為普遍的三種彈性伸縮模式進行闡述和分析。

5.png

首先是 IaaS 彈性伸縮,其代表產品是各雲廠商雲服務器彈性伸縮,如阿里雲 ESS,可以通過配置雲監控的吿警規則來觸發相應的 ECS 增減操作,同時支持動態增減 Slb 後端服務器和rds白名單來保證可用性,通過健康檢查功能實現彈性自愈能力。ESS 定義了伸縮組的概念,即彈性伸縮的基本單位,為相同應用場景的 ECS 實例的集合及關聯 Slb、Rds,同時支持多種伸縮規則,如簡單規則,進步規則,目標追蹤規則,預測規則等,用户的使用流程為創建伸縮組和伸縮配置,創建伸縮規則,監控查看彈性執行情況。

6.png

Kubernetes 彈性伸縮,這裏主要關注於水平彈性 Hpa,其代表產品為 K8s 以及其所對應的託管雲產品,如阿里雲容器服務,K8s 作為面向應用運維的基礎設施和 Platform for Platform,提供的內置能力主要是圍繞着容器級別的管理和編排來展開的,而彈性能力聚焦於對底層 Pod 的動態水平伸縮,K8s hpa 通過輪詢pod的監控數據並將它與目標期望值比較進行,通過算法實時計算來產生期望的副本數,進而對 Workload 的副本數進行增減操作,用户在實際使用上需要創建並配置對應的指標源和彈性規則以及對應的 Workload,可以通過事件來查看彈性的執行情況。

7.png

最後介紹一下應用畫像彈性伸縮,其主要用於互聯網公司內部,如阿里 ASI 容量平台。容量平台提供容量預測服務和容量變更決策服務,指導底層容量變更組件如 AHPA/VPA 實現容量彈性伸縮,並根據彈性結果修正容量畫像。以畫像驅動為主 + 指標驅動為輔實現彈性伸縮能力,通過提前伸縮 + 實時修正來降低彈性伸縮風險。

整個彈性伸縮會藉助 odps 和機器學習能力對實例監控等數據進行處理併產生應用畫像,如基準畫像,彈性畫像,大促畫像等,並藉助容量平台來完成畫像注入,變更管控和故障熔斷等操作。用户使用流程為應用接入,基於歷史數據/經驗生成對應的容量畫像,實時監控指標修正畫像,並監控查看彈性執行情況。

8.png

從對比可以看出各產品彈性伸縮功能模式上從抽象來講基本相同,均由觸發源,彈性決策和觸發動作組成,觸發源一般依賴外部監控系統,對節點指標,應用指標進行採集處理,彈性決策一般基於週期性輪詢並算法決策,有部分基於歷史數據分析預測以及用户定義的定時策略,而觸發動作為對實例進行水平擴縮,並提供變更記錄與對外通知。各個產品在此基礎上做場景豐富度,效率,穩定性的競爭力,並通過可觀測能力提升彈性系統的透明度,便於問題排查和指導彈性優化,同時提升用户使用體驗與粘性。

9.png

各產品彈性伸縮模型也存在這一定的差異,對於 IaaS 彈性伸縮,其作為老牌彈性伸縮能力,沉澱時間長,功能強大且豐富,雲廠商間能力趨於同質化。彈性效率相較容器受限,且強綁定各自底層 Iaas 資源。Kubernetes 作為開源產品,通過社區力量不斷優化迭代彈性能力和最佳實踐,更符合絕大部分開發運維人員訴求。對彈性行為和 API 進行高度抽象,但其可擴展性不強,無法支持自定義需求。而應用畫像彈性伸縮具有集團內部特色,根據集團應用現狀和彈性訴求進行設計,且更聚焦於資源池預算成本優化,縮容風險,複雜度等痛點。不易拷貝擴展,特別對於外部中小客户不適用。

從終態目標上,可以看出公有云與互聯網企業方向的不同:

  • 互聯網企業往往由於其內部應用具有顯著流量特徵,應用啟動依賴多,速度慢,且對整體資源池容量水位,庫存財務管理,離在線混部有組織上的諸多訴求,因而更多的是以容量畫像提前彈性擴容為主,基於 Metrics 計算的容量數據作為實時修正,其目標是容量畫像足夠精準以至於資源利用率達到預期目標。

  • 公有云廠商服務於外部客户,提供更為通用,普適的能力,並通過可拓展性滿足不同用户的差異化需求。尤其在 Serverless 場景,更強調應用應對突發流量的能力,其目標在於無需容量規劃,通過指標監控配合極致彈性能力實現應用資源的近乎按需使用且整個過程服務可用。

彈性落地

10.png

Serverless 作為雲計算的最佳實踐、雲原生髮展的方向和未來演進趨勢,其核心價值在於快速交付、智能彈性、更低成本。

在時代背景下,SAE 應運而生,SAE 是一款面向應用的 Serverless PaaS 平台,支持 Spring Cloud、Dubbo 等主流開發框架,用户可以零代碼改造直接將應用部署到  SAE,並且按需使用,按量計費,可以充分發揮 Serverless 的優勢為客户節省閒置資源成本,同時體驗上採用全託管,免運維的方式,用户只需聚焦於核心業務開發,而應用生命週期管理,微服務管理,日誌,監控等功能交由 SAE 完成。 

11.png

彈性的競爭力主要在於場景豐富度,效率,穩定性的競爭力,先講一下 SAE 在彈性效率上的優化。

通過對 SAE 應用的整個生命週期進行數據統計和可視化分析,其包含調度,init container 創建,拉取用户鏡像,創建用户容器,啟動用户容器&應用這幾個階段,示意圖中對其耗時的佔比進行了簡化。我們可以看到整個應用生命週期耗時集中於調度,拉取用户鏡像,應用冷啟動這幾個階段。

針對於調度階段,其耗時主要在於 SAE 當前會執行打通用户 VPC 操作,由於該步驟強耦合於調度,本身耗時較長,且存在創建長尾超時,失敗重試等情況,導致調度鏈路整體耗時較長。由此產生的疑問是可否優化調度速度?可否跳過調度階段 ? 而對於拉取用户鏡像,其包含拉取鏡像與解壓鏡像的時長,特別是在大容量鏡像部署的情況下尤為突出。

優化的思路在於拉取鏡像是否可以優化使用緩存,解壓鏡像是否可以優化。而對於應用冷啟動,SAE 存在大量單體和微服務的 JAVA 應用,JAVA 類型應用往往啟動依賴多,加載配置慢,初始化過程長,導致冷啟動速往往達到分鐘級。優化的方向在於可否避免冷啟動流程並使用户儘量無感,應用無改造。

12.png

首先 SAE 採用了原地升級能力,SAE 起初使用了 K8s 原生的 Deployment 滾動升級策略進行發佈流程,會先創建新版本 Pod,再銷燬舊版本 Pod 進行升級,而所謂原地升級,即只更新 Pod 中某一個或多個容器版本、而不影響整個 Pod 對象、其餘容器的升級。其原理是通過 K8s patch 能力,實現原地升級 container,通過 K8s readinessGates 能力,實現升級過程中流量無損。

原地升級給 SAE 帶來了諸多價值,其中最重要的是避免重調度,避免 Sidecar 容器(ARMS,SLS,AHAS)重建,使得整個部署耗時從消耗整個 Pod 生命週期到只需要拉取和創建業務容器,於此同時因為無需調度,可以預先在 Node 上緩存新鏡像,提高彈性效率。SAE 採用阿里開源 Openkruise 項目提供的 Cloneset 作為新的應用負載,藉助其提供的原地升級能力,使得整個彈性效率提升 42%。

13.png

同時 SAE 採用了鏡像預熱能力,其包含兩種預熱形式:調度前預熱,SAE 會對通用的基礎鏡像進行全節點緩存,以避免其頻繁的從遠端進行拉取。與此同時對於分批的場景支持調度中預熱,藉助 Cloneset 原地升級能力,在升級的過程中可以感知到實例的節點分佈情況,這樣就可以在第一批部署新版本鏡像的同時,對後面批次的實例所在節點進行鏡像預拉取,進而實現調度與拉取用户鏡像並行。通過這項技術,SAE 彈性效率提升了 30%。

14.png

剛才講述的優化點在於拉取鏡像部分,而對於解壓鏡像,傳統容器運行需要將全量鏡像數據下載後再解包,然而容器啟動可能僅使用其中部分的內容,導致容器啟動耗時長。SAE 通過鏡像加速技術,將原有標準鏡像格式自動轉化為支持隨機讀取的加速鏡像,可以實現鏡像數據免全量下載和在線解壓,大幅提升應用分發效率,同時利用 Acree 提供的 p2p 分發能力也可以有效減少鏡像分發的時間。

15.png

對於 Java 應用冷啟動較慢的痛點,SAE 聯合 Dragonwell 11 提供了增強的 AppCDS  啟動加速策略,AppCDS 即 Application Class Data Sharing,通過這項技術可以獲取應用啟動時的 Classlist 並 Dump 其中的共享的類文件,當應用再次啟動時可以使用共享文件來啟動應用,進而有效減少冷啟動耗時。映射到 SAE 的部署場景,應用啟動後會生成對應的緩存文件在共享的 NAS 中,而在進行下一次發佈的過程中就可以使用緩存文件進行啟動。整體冷啟動效率提升 45%。

16.png

除了對整個應用生命週期的效率進行優化外,SAE 也對彈性伸縮進行了優化,整個彈性伸縮流程包括彈性指標獲取,指標決策以及執行彈性擴縮操作三部分。對於彈性指標獲取,基礎監控指標數據已經達到了秒級獲取,而對於七層的應用監控指標,SAE 正在規劃採用流量透明攔截的方案保證指標獲取的實時性。而彈性決策階段,彈性組件啟用了多隊列併發進行 Reconcile,並實時監控隊列堆積,延時情況。

17.png

SAE 彈性伸縮包括強大的指標矩陣,豐富的策略配置,完善的通知吿警機制及全方位可觀測能力,支持多種數據源:原生的MetricsServer、MetricsAdapter、Prometheus,雲產品 SLS、CMS、SLB 以及外部的網關路由等,支持多種指標類型:CPU、MEM、QPS、RT、TCP 連接數,出入字節數,磁盤使用率,Java 線程數,GC 數還有自定義指標。對指標的抓取和預處理後,可以自定義配置彈性策略來適配應用的具體場景:快擴快縮,快擴慢縮,只擴不縮,只縮不擴,DRYRUN,自適應擴縮等。同時可以進行更為精細化的彈性參數配置,如實例上下限,指標區間,步長比例範圍,冷卻、預熱時間,指標採集週期和聚合邏輯,CORN 表達式,後續也會支持事件驅動的能力。

彈性觸發後會進行對應的擴縮容操作,並通過切流保證流量無損,並且可以藉助完善的通知吿警能力(釘釘,webhook,電話,郵件,短信)來實時觸達吿知用户。彈性伸縮提供了全方位的可觀測能力,對彈性的決策時間,決策上下文進行清晰化展現,並且做到實例狀態可回溯,實例 SLA 可監控。

18.png

SAE 彈性能力在場景豐富度上也有着相應的競爭力,這裏重點介紹一下 SAE 當前支持的四種場景:

  • 定時彈性: 在已知應用流量負載週期的情況下進行配置,應用實例數可以按照時間,星期,日期週期進行規律化擴縮,如在早 8 點到晚 8 點的時間段保持 10 個實例數應對白天流量,而在其餘時間由於流量較低則維持在 2 個實例數甚至縮 0。適用於資源使用率有周期性規律的應用場景,多用於證券、醫療、政府和教育等行業。

  • 指標彈性: 可以配置期望的監控指標規則,SAE 會對應用的指標穩定在所配置的指標規則內,並且默認採用快擴慢縮的模式來保證穩定性。如將應用的cpu指標目標值設置為 60%,qps 設置為 1000,實例數範圍為 2-50。這種適用於突發流量和典型週期性流量的應用場景,多用於互聯網、遊戲和社交平台等行業。

  • 混合彈性: 將定時彈性與指標彈性相結合,可以配置不同時間,星期,日期下的指標規則,進而更加靈活的應對複雜場景的需求。如早 8 點到晚 8 點的時間段 CPU 指標目標值設置為 60%,實例數範圍為 10-50,而其餘時間則將實例數範圍降為 2-5,適用於兼備資源使用率有周期性規律和有突發流量、典型週期性流量的應用場景,多用於互聯網、教育和餐飲等行業。

  • 自適應彈性: SAE 針對流量突增場景進行了優化,藉助流量激增窗口,計算當前指標在這個時刻上是否出現了流量激增問題,並會根據流量激增的強烈程度在計算擴容所需的實例時會增加一部分的宂餘,並且在激增模式下,不允許縮容。

19.png

穩定性是 SAE 彈性能力建設的過程中非常重要的一環,保證用户應用在彈性過程中按照預期行為進行擴縮,並保證整個過程的可用性是關注的重點。SAE 彈性伸縮整體遵循快擴慢縮的原則,通過多級平滑防抖保證執行穩定性,同時對於指標激增場景,藉助自適應能力提前擴容。SAE 當前支持四級彈性平滑配置保證穩定性:

  • 一級平滑:對指標獲取週期,單次指標獲取的時間窗口,指標計算聚合邏輯進行配置;

  • 二級平滑:對指標數值容忍度,區間彈性進行配置;

  • 三級平滑:對單位時間擴縮步長,百分比,上下限進行配置;

  • 四級平滑:對擴縮冷卻窗口,實例預熱時間進行配置。

Serverless 彈性最佳實踐

20.png

SAE 彈性伸縮可以有效解決瞬時流量波峯到來時應用自動擴容,波峯結束後自動縮容。高可靠性、免運維、低成本的保障應用平穩運行,在使用的過程中建議遵循以下最佳實踐進行彈性配置。

配置健康檢查和生命週期管理

建議對應用健康檢查進行配置,以保證彈性擴縮過程中的應用整體可用性,確保您的應用僅在啟動、運行並且準備好接受流量時才接收流量 同時建議配置生命週期管理 Prestop,以確保縮容時按照預期優雅下線您的應用。

採用指數重試機制

為避免因彈性不及時,應用啟動不及時或者應用沒有優雅上下線導致的服務調用異常,建議調用方採用指數重試機制進行服務調用。

應用啟動速度優化

為提升彈性效率,建議您優化應用的創建速度,可以從以下方面考慮優化:

  • 軟件包優化: 優化應用啟動時間,減少因類加載、緩存等外部依賴導致的應用啟動過長;

  • 鏡像優化: 精簡鏡像大小,減少創建實例時鏡像拉取耗時,可藉助開源工具 Dive,分析鏡像層信息,有針對性的精簡變更;

  • Java 應用啟動優化: 藉助 SAE 聯合 Dragonwell 11 ,為 Java 11 用户提供了應用啟動加速功能。

21.png

彈性伸縮指標配置

彈性伸縮指標配置,SAE 支持基礎監控,應用監控多指標組合配置,您可以根據當前應用的屬性(CPU 敏感 /內存敏感 /io 敏感)進行靈活選擇。

可以通過對基礎監控和應用監控對應指標歷史數據( 如過去 6h, 12h, 1 天,7 天峯值,P99,P95 數值)進行查看並預估指標目標值,可藉助 PTS 等壓測工具進行壓測,瞭解應用可以應對的併發請求數量、需要的 CPU 和內存數量,以及高負載狀態下的應用響應方式,以評估應用容量峯值大小。

指標目標值需要權衡可用性與成本進行策略選擇,如:  

  • 可用性優化策略 配置指標值為 40%

  • 可用性成本平衡策略 配置指標值為 50%

  • 成本優化策略 配置指標值為 70%

同時彈性配置應考慮梳理上下游,中間件,DB 等相關依賴,配置對應的彈性規則或者限流降級手段,確保擴容時全鏈路可以保證可用性。

在配置彈性規則後,通過不斷監視和調整彈性規則以使容量更加接近應用實際負載。

內存指標配置

關於內存指標,考慮部分應用類型採用動態內存管理進行內存分配(如 Java jvm 內存管理,glibc malloc 和 free 操作),應用閒置內存並沒有及時釋放給操作系統,實例消耗的物理內存並不會及時減少且新增實例並不能減少平均內存消耗,進而無法觸發縮容,針對於該類應用不建議採用內存指標。

Java 應用運行時優化

釋放物理內存,增強內存指標與業務關聯性:藉助 Dragonwell 運行時環境,通過增加 JVM 參數開啟 ElasticHeap 能力,支持 Java 堆內存的動態彈性伸縮,節約Java進程實際使用的物理內存佔用。

最小實例數配置

配置彈性伸縮最小實例數建議大於等於 2,且配置多可用區 VSwitch,防止因底層節點異常導致實例驅逐或可用區無可用實例時應用停止工作,保證應用整體高可用。

最大實例數配置

配置彈性伸縮最大實例數時,應考慮可用區 IP 數是否充足,防止無法新增實例。可以在控制枱 VSwitch 處查看當前應用可用 IP,若可用 IP 較少考慮替換或新增 VSwitch。

22.png

彈性到達最大值

可以通過應用概覽查看當前開啟彈性伸縮配置的應用,並及時發現當前實例數已經到達峯值的應用,進行重新評估其彈性伸縮最大值配置是否合理。若期望最大實例數超過產品限制(當前限制單應用50實例數,可提工單反饋提高上限)

可用區再均衡

彈性伸縮觸發縮容後可能會導致可用區分配不均,可以在實例列表中查看實例所屬可用區,若可用區不均衡可以通過重啟應用操作實現再均衡。

自動恢復彈性配置

當進行應用部署等變更單操作時,SAE 會停止當前應用的彈性伸縮配置避免兩種操作衝突,若期望變更單完成後恢復彈性配置,可以在部署時勾選系統自動恢復。

23.png

彈性歷史記錄

SAE 彈性生效行為當前可通過事件進行查看擴縮時間,擴縮動作,以及實時,歷史決策記錄和決策上下文可視化功能,以便衡量彈性伸縮策略的有效性,並在必要時進行調整。

彈性事件通知

結合釘釘、webhook、短信電話等多種通知渠道,便於及時瞭解彈性觸發狀況

24.png

最後分享一個採用 SAE 彈性伸縮功能的客户案例,在 2020 新冠疫情期間,某在線教育客户業務流量暴漲 7-8 倍,硬件成本和業務穩定性面臨巨大風險。如果此時採用傳統的 ECS 架構,客户就需要在非常短的時間內做基礎設施的架構升級,這對用户的成本及精力都是非常大的挑戰。但如果採用 SAE,用户 0 改造成本即可享受 Serverless 帶來的技術紅利,結合 SAE 的多場景彈性策略配置,彈性自適應和實時可觀測能力,保障了用户應用在高峯期的業務 SLA,並且通過極致彈性效率,節省硬件成本達到 35%。

綜上,彈性發展方向上,尤其是在 Serverless 場景,更強調應對突發流量的能力,其目標在於無需容量規劃,通過指標監控配合極致彈性能力實現應用資源的近乎按需使用且整個過程服務可用。SAE 通過對彈性組件和應用全生命週期的不斷優化以達到秒級彈性,並在彈性能力,場景豐富度,穩定性上具備核心競爭力,是傳統應用 0 改造上 Serverless 的最佳選擇。