阿里雲釋出企業雲原生IT成本治理方案:五大能力加速企業 FinOps 程式

阿里巴巴雲原生發表於2022-04-24

*作者:莫源*


## 雲原生技術與降本增效


2020 年,新冠疫情橫掃全球,大量的企業停工、工廠停產、供應鏈中斷,給全球的經濟帶來巨大的衝擊。有 65%的企業開始考慮透過上雲的方式提升企業 IT 資訊化的能力來應對未來可能出現的其他系統性風險。而云原生技術作為時下最先進的上雲方式,成為了大多數企業進行 IT 資訊化轉型的最佳選擇。


知名顧問機構 Capgemini 在 2020 年的“Cloud Native Comes of Age”調研結果顯示,僅有 15%的企業已經將新應用程式建立在雲原生環境,但接下來的三年這個比例將提升到 52%。報告中,在雲原生環境中部署超過 20% 應用的企業被定義為領先者,他們是如何看待雲原生技術呢?


87%的受訪企業表示,雲原生提高了效率並降低了成本。84%的受訪企業表示,雲原生推動了更好的客戶體驗。80%的受訪企業表示,新產品和服務的推行等待時間顯著降低。


![1.png](~tplv-k3u1fbpfcp-zoom-1.image "1.png")


而在2021年CNCF《FinOps Kubernetes Report》的調研報告顯示,遷移至 Kubernetes 平臺後,68%的受訪者表示所在企業計算資源成本有所增加,36%的受訪者表示成本飆升超過 20%。即便是作為大多數領先者企業共識的降本增效特性,在很多企業進行雲原生轉型的過程中依舊障礙重重,甚至付出了更多的成本,為什麼已經採用了雲原生技術,卻還是離理想那麼遙遠?


## 從一個真實的案例講起


Raymond 是一家網際網路電商的 IT 平臺負責人,在過去 2 年的時間裡,帶領團隊將公司所有的業務進行了雲原生化改造。Raymond 選擇雲原生技術作為平臺架構方式的初衷是非常樸素的,因為以微服務、容器、DevOps 為代表的雲原生技術,可以將不同型別的應用進行統一的交付和運維,降低管理成本;可以透過流水線實現自動化的構建和交付,提升研發速度;可以透過容器技術實現應用之間的資源共享與彈性,降低資源的浪費;可以透過不同型別應用間的混部與搶佔,進一步壓榨叢集資源的利用率。


| 業務平臺    | 業務描述                                                                     |

| ------- | ------------------------------------------------------------------------ |

| 電商主站    | 週期性業務,工作日白天為低谷,工作日晚上與節假日為高峰,大促場景下存在激峰流量。                                 |

| 大資料平臺   | 包含資料湖的即席查詢與報表/ETL作業,即席查詢主要以Presto為主,作業主要資料研發透過工作流提交;ETL作業主要以Spark離線作業為主。 |

| 微商家平臺   | 多租戶SaaS化業務,每個租戶獨立配額和用量。                                                  |

| 直播平臺    | 週期性業務,工作日白天為低谷,工作日晚上與節假日為高峰,存在不可預期的峰值流量。                                 |

| 轉碼/訓練平臺 | 臨時任務,碎片型作業,執行時間較短。                                                       |


Raymond 的團隊負責公司五大平臺的穩定執行,根據業務的特性、運維的便捷性、安全的等級、成本的考量,Raymond 將業務拆分了三個叢集:


-   **叢集 A-主站/轉碼叢集**


主站的業務穩定性要求較高,整個叢集的規劃以靜態節點池為主,配合定時伸縮的能力在業務高峰到來之前提前擴容。白天容量較低的時候,透過混部轉碼業務分時複用叢集的空間,從而實現資源效率的提升。


![2.png](~tplv-k3u1fbpfcp-zoom-1.image "2.png")


-   **叢集 B-直播/大資料集**


將直播業務和大資料業務放在一個叢集中的原因是,無論是資料湖的即席查詢、直播業務還是大資料的 ETL 作業,在單位時間內對計算資源的消耗都是非常大的,但是業務的容量大小存在比較大的隨機性,高彈性的場景更適合兩者的業務。


![3.png](~tplv-k3u1fbpfcp-zoom-1.image "3.png")


-   **叢集 C-微商家叢集**


將微商家業務獨立放在一個叢集內,主要是出於安全性的考慮,隔離租戶資料與業務資料。此外,獨立的叢集也可以更好地進行成本核算。


![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3840363eeebc41689ca6563516732e5d~tplv-k3u1fbpfcp-zoom-1.image "4.png")


作為非常資深的雲原生領域專家,Raymond 的技術選型、叢集的拆分、最佳化的策略都是無可挑剔的,業務雲原生化的第一個月,穩定又高效,一切似乎都在向著預想中的結果前進著。


![5.png](~tplv-k3u1fbpfcp-zoom-1.image "5.png")


“上個月的費用增加了 70%?”,在拿到最新的賬單後 Raymond 喃喃自語百思不得其解,到底是哪裡出現了問題?


## 企業雲原生 IT 成本治理的難點


從前,Raymond 的團隊採用的比較傳統、成熟的靜態企業 IT 成本治理模型。這種模型的週期通常為月度或者季度,透過資源規劃、成本估算、成本預算、成本控制四個階段的實施,進行 IT 資產的採購,實現企業IT成本治理的目標。


![6.png](~tplv-k3u1fbpfcp-zoom-1.image "6.png")


這種模型的優勢是每一次 IT 成本治理所得出的成本預算是固定的,從 IT 資產管理的角度來講是非常友好的。但是弊端也比較明顯,當業務存在容量的頻繁變化的時候,可能會使成本估算階段出現較大的偏差,造成大量的浪費。


雲原生技術中常用來降本增效的方式,例如:智慧排程、彈性伸縮、混部、分時搶佔等本質上來講是將資源的獨享變成共享,將資源的靜態供給變成動態,任何新技術的採用,勢必會對已有系統的架構進行改造與最佳化,而云原生技術架構的引入的動態性改造常常會打破企業中傳統的 IT 成本管理體系,造成 IT 成本管理的失控。當 IT 成本管理失控的時候,各種最佳化的策略也就成為了無根之木。


![7.png](~tplv-k3u1fbpfcp-zoom-1.image "7.png")


當 Raymond 嘗試透過賬單來找尋出現問題的蛛絲馬跡的時候,他得到的是一張上百頁的月度賬單詳情,從賬單明細中來回溯導致異常費用產生的應用、部門是幾乎不可能的事情。而 Raymond 遇到的難題,幾乎是每一個雲原生架構的負責人都必須跨過的難題。


那麼,是什麼導致了企業雲原生 IT 成本治理的困難呢?


-   **業務單元與計費單元生命週期的差異**


在傳統的企業 IT 成本治理模型中,業務單元和計費單元是存在一定的匹配關係的,例如:一個入口網站,包含兩臺 ECS,一個接入層閘道器 SLB,一個資料庫 RDS。它的業務單元和計費單元是一對一的,賬單即是成本。


![8.png](~tplv-k3u1fbpfcp-zoom-1.image "8.png")


但是,在雲原生的場景下,當應用部署在 Kubernetes 等容器叢集時,所有的資源是池化的,業務的最小計量單元是一個 Pod,而 Pod 的生命週期與實際產生賬單的節點的生命週期是不匹配的。大多數場景下,應用的重新部署,業務的 Pod 就會重新排程到其他的節點之上,這導致了業務單元和計費單元在邏輯、空間、時間三個維度上,都可能無法做到一對一的匹配關係。


這就導致了企業的業務部門想要去衡量、規劃、估算一個業務的預算的時候,難以得出具體的結果。


-   **動態資源交付與靜態容量規劃的矛盾**


傳統的企業 IT 治理模型中,規劃/預算與資源交付的關係是靜態的。業務部門可以按照月度、季度、年度的週期提交預算,再由 IT 部門進行統一的採購、分配。為了解決靜態容量規劃模型中資源浪費的問題,容器採用了例如:彈性伸縮等技術與解決方案。透過動態資源交付的方式,進行容量成本的控制。


但是,動態資源交付模型在實際的生產中,可能會引入其他的成本陷阱。比較典型的是傳統靜態規劃模型大多會採用包年包月的計費方式,而動態資源交付模型,會混合包年包月與按量付費等多種模型。甚至某些場景下,還會引入 Saving Plan、預留例項券、競價例項等特殊的付費策略。相比而言,包年包月的計費單價是按量付費等模型的 30-50%左右。當動態交付的資源佔比不合理的時候,可能會造成 IT 成本的大量浪費。


此外,傳統靜態容量規劃模型的預算和採購是在一個階段實施的,這樣 IT 成本治理無需關注成本的趨勢變化。但是當大量的動態資源交付模型實施後,企業的 IT 管理員需要不僅僅關注總的費用變化,還需要關注成本的趨勢,甚至某些場景下需要對費用進行預測,以保障叢集的費用不會出現非預期的大規模超出預算的現象。


-   **企業 IT 成本治理模型與雲原生架構的適配**


傳統的 IT 成本治理模型在成本控制方面,更多的側重是在增效這個維度,透過提升機器的利用率,縮減下一次容量規劃階段的成本。而云原生 IT 成本治理的場景,增效和降本是同時進行的,企業可以透過監控、智慧推薦等方式調整資源的配額,實現資源利用率的提升;透過彈性伸縮、動態資源交付等方式,實現資源成本的降低。降本增效同時進行的方式,會大大縮短企業 IT 成本治理模型的週期,並且對預算管理配額管理、成本趨勢預測、成本趨勢報警提出更多的要求。


-   **不恰當的成本最佳化方案濫用的副作用**


傳統的 IT 成本治理模型的最佳化手段相對而言比較單一,通常是透過資源利用率等指標的指導,實現降本增效的目的。而在雲原生的場景下,各種各樣的最佳化手段層出不窮。但是,任何的最佳化方案都會對現有架構的穩定性帶來挑戰,例如:


-   使用彈性伸縮時,需要考慮伸縮靈敏度與業務流量洪峰的匹配程度;需要考慮縮容時業務的優雅下線;需要考慮是否會造成成本黑洞(異常原因造成的大量資源浪費,例如:DDOS 時造成的 CDN 資源超量使用)等等。


-   使用大資料彈性供給時,需要考慮叢集是否還有閒置資源可以複用;需要考慮臨時資料作業的執行時長是否過長,造成資源的計費模型不合理;需要考慮彈性供給時資源的利用率是否符合預期等等。


本質來講,雲原生場景的最佳化主要集中在排程/資源的動態性上,透過騰挪、分時、搶佔、伸縮等手段,實現資源利用率的提升,以及整體叢集水位或者總核時成本的降低。大多數的最佳化都是針對領域場景的,企業在進行雲原生 IT 成本最佳化方案實施之前,需要先衡量和評估架構的變更帶來的風險,以及最佳化方案的預期收益。


上述的四個問題,是每一家企業雲原生轉型時做 IT 成本管理都繞不過的障礙,制約了企業進行雲原生轉型的節奏,也困擾了像 Raymond 等一大批雲原生技術的領先者。為了解決上述問題,雲原生 IT 成本治理方案就應運而生。


## 阿里雲企業雲原生 IT 成本治理方


阿里雲容器服務與 AWS 並列排名第一,是全球容器產品最完善的雲服務廠商。早在 2006 年就開始在阿里集團內部推進雲原生技術的落地,十六年的雲原生實踐的經驗積累讓阿里雲對雲原生的思考和理解可以更好的賦能給企業,助力企業實現 IT 資訊化轉型。


近些年,隨著企業上雲的加速,雲財務管理(**FinOps**)的概念被越來越多的企業提及與採納,雲財務管理(**FinOps**)是一種雲的運營模式,它將系統、最佳實踐和文化結合在一起,以提高組織瞭解雲成本的能力。這是一種為雲支出帶來財務責任的做法,使團隊能夠做出明智的業務決策。雲財務管理(**FinOps**)增強了 IT、工程、財務、採購和企業之間的協作。它使 IT 能夠發展成為專注於利用雲技術為業務增值的服務組織。當雲原生技術與雲財務管理(FinOps)概念交織在一起,就孕育出了雲原生IT成本治理(Cloud Native FinOps)的理念,它是雲財務管理(FinOps)概念在雲原生場景下的一種演進與進化。


阿里雲容器服務推出了企業雲原生 IT 成本治理方案,助力企業在雲原生雲上的場景下,提供企業 IT 成本管理、企業 IT 成本視覺化、企業 IT 成本最佳化等功能。阿里雲企業雲原生 IT 成本治理方案擁有五大核心功能:


![9.png](~tplv-k3u1fbpfcp-zoom-1.image "9.png")


**核心功能一:獨有的雲原生容器場景成本分攤與估算模型**


為了解決容器場景下業務單元與計費單元生命週期不一致的問題,容器服務提出了獨有的計費與計量相結合的成本估算模型,並加入費用策略(付費型別、節省計劃、代金券、使用者折扣、競價波動)、分攤因子(CPU、記憶體、GPU 卡、GPU 視訊記憶體等)、資源形態(ECS\ECI\HPC)等因素的考量,實現針對Pod維度的成本估算以及叢集佔比的成本分攤。透過賬單分析將叢集在一個階段內的所有資源成本進行聚合,再配合 Pod 維度的成本分攤能力實現了完整的雲原生容器場景成本分攤與估算模型。


![10.png](~tplv-k3u1fbpfcp-zoom-1.image "10.png")


**核心功能二:多維度的成本洞察、趨勢預測、根因下鑽**


![11.png](~tplv-k3u1fbpfcp-zoom-1.image "11.png")


支援叢集、名稱空間、節點池、應用(label 萬用字元匹配)四個維度的成本洞察,叢集維度側重在雲資源的分佈、資源成本的趨勢變化、叢集水位與浪費的比率以及叢集成本費用的趨勢與預測,可以協助IT管理員準確判斷成本消費的趨勢,防止超過預算的場景;名稱空間側重在費用的分攤,支援短週期的費用預估以及長週期的成本分攤,支援排程水位、資源用量、成本趨勢的相關性分析,協助部門管理員進行成本估算,下鑽分析成本浪費,提升部門資源利用率;節點池維度側重在資源成本規劃與治理,透過例項型別、單位核時、排程水位、利用率水位的相關性分析,協助 IT 資產管理員最佳化資源組合和付費策略。應用(label 萬用字元匹配)維度側重在領域場景成本最佳化,例如:大資料、AI、離線作業、線上應用等各種上層應用場景,都可以透過應用維度的成本洞察進行實時費用預估以及任務級別的成本核算。


透過四個維度的成本洞察,可以讓全場景的成本最佳化功能與解決方案都有資料可以支撐,有理有據的進行降本增效。


**核心功能三:全場景的成本最佳化能力、解決方案的覆蓋**


**![12.png](~tplv-k3u1fbpfcp-zoom-1.image "12.png")**


針對於不同企業的實際業務場景,阿里雲容器服務提供了全場景的資源畫像建立、成本最佳化能力與解決方案(具體見文末):


-   彈性伸縮

-   混部

-   智慧資源畫像

-   雲原生大資料/AI

-   雲原生工作流


此外,企業針對成本的最佳化策略,大部分是需要業務場景支撐的,很多場景下還會存在定製化和二次開發。因此,阿里雲容器服務的企業雲原生 IT 成本治理方案提供的成本洞察能力與上層最佳化方案完全解耦的,可以透過四個維度的成本洞察能力,覆蓋全場景的成本最佳化手段的衡量與評估。


**核心功能四:多叢集/多雲/混合雲全型別雲成本管理能力**


多雲是目前企業上雲的新趨勢,不同的雲廠商的計費模型存在比較大的差異,例如:國內雲服務商常見的包年包月付費方式、國際雲服務商常見的信用卡預扣/後付、部分雲服務商支援的節省計劃以及預留例項等等。這些都對多雲雲管平面的成本分析能力提供了更多的挑戰。阿里雲容器服務的企業雲原生 IT 成本治理方案透過提供統一的雲服務廠商的賬單與詢價接入與預設實現,支援主流的雲服務廠商、IDC 自建機房的費用資料的接入。並透過一致的雲原生容器場景成本分攤與估算模型進行成本管理。配合企業級雲原生分散式雲容器平臺 ACK One(Alibaba Cloud Distributed Cloud Container Platform)實現多雲雲管、資管統一的控制平面。


**核心功能五:企業雲原生IT成本治理的專家服務**


企業雲原生 IT 成本治理不僅僅是一個產品能力或者解決方案,更是一種雲原生時代的企業IT管理、組織流程、文化的演進。阿里雲容器服務團隊聯合阿里雲天基團隊,透過阿里云云資管家提供完整的 FinOps 理念覆蓋的產品及專家服務。


![13.png](~tplv-k3u1fbpfcp-zoom-1.image "13.png")


阿里云云資管家作為國內透過《面向雲資源的財務運營能力通用成熟度模型》評估的雲產品,協助企業落地:成本流程治理、成本洞察、成本最佳化、成本運營等,助力企業建立雲原生整體 IT 成本平臺,加速企業全面雲化後的  IT創新與 IT 決策。


## 回到真實的場景中去

面對 Raymond 的困境,要如何透過阿里雲容器服務提供的企業雲原生 IT 成本治理方案來進行成本最佳化呢?


**步驟一**:Raymond 先透過叢集的成本分析能力,檢視叢集的成本趨勢與成本預算的差異,可以來得出成本異常的初步結論。


![14.png](~tplv-k3u1fbpfcp-zoom-1.image "14.png")


| 叢集名稱          | 是否超出預算 | 超出預算比例 |

| ------------- | ------ | ------ |

| 叢集 A-主站/轉碼叢集  | 是      | 5%     |

| 叢集 B-直播/大資料叢集 | 是      | 140%   |

| 叢集 C-微商家叢集    | 否      | -9%   |


根據叢集的費用情況可以看出,主體的浪費是在叢集 B。那麼,接下來可以主要針對叢集 B 進行下鑽分析。


**步驟二**:檢視叢集的費用構成,確定最佳化方向與下鑽策略。


![15.png](~tplv-k3u1fbpfcp-zoom-1.image "15.png")


在這個叢集中,可以看到計算資源是費用的主體構成,那麼可以將問題下鑽問題的方向導向資源利用率以及核時單價成本的角度來進行進一步的分析。


**步驟三**:檢視叢集的資源利用率情況以及核時單價成本


![16.png](~tplv-k3u1fbpfcp-zoom-1.image "16.png")


從叢集的排程水位上來看達到了 78%,是一個比較理想的情況,既有一定的空間繼續排程又不至於過於浪費。從實際的資源使用率來看,只有 3%的真實用率,說明資源存在已分配但是未充分使用的場景。此外,從節點池的核時單價上來檢視,其中一個包含競價例項的節點池的單價逼近按量付費的單價,這說明選擇的競價例項的規格存在不合理的現象,造成單位核時的價格過高。


![17.png](~tplv-k3u1fbpfcp-zoom-1.image "17.png")


**步驟四**:下鑽應用維度,定位問題應用


![18.png](~tplv-k3u1fbpfcp-zoom-1.image "18.png")


透過名稱空間維度可以定位到有部分的名稱空間有明顯的波峰波谷的容量變化,且容量擴容後,資源的利用率並沒有明顯的波動和變化,說明定時的伸縮對業務的是沒有帶來任何收益的。


![19.png](~tplv-k3u1fbpfcp-zoom-1.image "19.png")


透過名稱空間中提供的資源浪費列表,可以看到出現大量浪費的應用名稱。填寫應用的 label 情況,可以看當前的應用基本是空跑的情況,但是佔據了叢集 34.74%的整體消費。


![20.png](~tplv-k3u1fbpfcp-zoom-1.image "20.png")


Raymond 經過和研發同學確認,發現是由於定時伸縮配置到了一個還未上線的測試業務上,而且配置伸縮的副本數比較大,造成了資源的大量浪費。此外,叢集中的競價例項組合由於庫存的問題造成費用飆高,需要配置新的競價例項的可用區和規格。至此,Raymond 重新配置了定時伸縮規則,修正了競價例項的配置組合,困擾他很久的問題解決了。


其實,當我們回過頭來看 Raymond 的問題,都是實際生產中可能遇到的小事,而正是這些不起眼的小事有可能造成企業 IT 成本治理的大資損。IT 的系統複雜度越高,就需要運維繫統越自動化,同樣,雲原生降本增效的手段越豐富,就越需要 IT 成本治理的方案更資料化、透明化。降本增效是目的,強調的是結果而不是過程,依託企業雲原生 IT 成本治理方案,可以透明化、數字化、自動化地實現企業 IT 成本最佳化的目標。


## 雲原生企業 IT 成本治理未來的展望


可預見在未來,雲財務管理(FinOps)的概念會被越來越多的企業提及與採納,降本增效的能力與方案也會如雨後春筍一般的湧現。但是,從實際的情況上來看,大部分企業的 IT 成本治理的理念還沒有跟上架構的演進,這無形中給企業的雲原生化轉型帶來了更大的負擔。想要完整驅動、落地雲原生 IT 成本最佳化的策略,一定要讓雲原生 IT 成本治理的理念、工具、流程先行,只有可觀測、可量化、可衡量的最佳化方案才能真正證明價值。


阿里雲企業雲原生 IT 成本治理方案助力企業落地企業 IT 成本治理的理念、工具與流程,讓企業在雲原生化的過程中可以數字化地實現企業 IT 成本管理與最佳化,成為 FinOps 領域的踐行者與領先者。


***相關連結***


[1]《Gartner報告:阿里雲成全球容器產品最完善雲服務商》


[*https://developer.aliyun.com/article/763157*](https://developer.aliyun.com/article/763157)


[2]彈性伸縮:


[*https://help.aliyun.com/document_detail/119099.html*](https://help.aliyun.com/document_detail/119099.html)


[3]智慧資源畫像:


[*https://help.aliyun.com/document_detail/413944.html*](https://help.aliyun.com/document_detail/413944.html)


[4]雲原生大資料/AI:


[*https://help.aliyun.com/document_detail/201994.html*](https://help.aliyun.com/document_detail/201994.html)


[5]雲原生工作流:


[*https://help.aliyun.com/document_detail/157124.html*](https://help.aliyun.com/document_detail/157124.html)


點選[**此處**](https://help.aliyun.com/document_detail/396325.html),檢視阿里雲企業雲原生 IT 成本治理方案文件!


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69953029/viewspace-2888511/,如需轉載,請註明出處,否則將追究法律責任。

相關文章