最近翻了下一本講AWS成本優(yōu)化的書。書里提到了一個叫KAO的框架（拼音一念真的很牛），覺得雖然抽象但是好歹是個框架，于是想借用下，再結(jié)合自己這些年在初創(chuàng)公司的經(jīng)驗，聊聊從成本的角度，我們對AWS的架構(gòu)應(yīng)該有哪些思考。文章是關(guān)于AWS的，但是類似的思路，應(yīng)該也可以擴(kuò)展到阿里云、華為云等其他的云平臺上。
1. 簡介
2019年的今天，公有云計算早就不是什么讓人眼前一亮的黑科技。但是在媒體輿論趨于平靜的背后，我們看到的是公有云計算確實成為了我們這個時代各種龐大的商業(yè)、政務(wù)生態(tài)系統(tǒng)的IT基礎(chǔ)設(shè)施。如果聚焦到技術(shù)類初創(chuàng)公司的角度，公有云計算大幅度的減小了初期團(tuán)隊需要花費(fèi)在基礎(chǔ)設(shè)備和運(yùn)維方面的成本，為企業(yè)快速的迭代試錯提供了可能。對于一部分技術(shù)類初創(chuàng)公司，比如電商和o2o行業(yè)，以及saas、paas類的產(chǎn)品，這種優(yōu)勢尤其明顯。有些云平臺對于新賬戶還會有不同程度的補(bǔ)貼（比如我們的創(chuàng)業(yè)公司在AWS的境外和國內(nèi)平臺上就分別獲得了平臺的資助，初期的一段時間都在0現(xiàn)金使用AWS的各種服務(wù)）。
但是我們也應(yīng)該看到公有云計算的長期運(yùn)維成本并不低。我創(chuàng)投圈的朋友所在的公司，在公司規(guī)模增長，并且度過了云平臺補(bǔ)貼期以后，每個月幾十萬上百萬人民幣的AWS或者阿里云賬單并不少見。對于資源有限同時又要追求極致增長的初創(chuàng)公司，把寶貴的現(xiàn)金從IT運(yùn)營中節(jié)省出來，投入到客戶價值的挖掘和最大化，對企業(yè)的發(fā)展是會有不小幫助的。
說回前面提到的KAO框架 - KAO是知識（Knowledge），架構(gòu)（Architecture），運(yùn)營（Operation）的英文首字母縮寫。也就是說要想有效的優(yōu)化AWS的成本，我們需要
- 熟悉AWS的各種服務(wù)，他們各自在性能、維護(hù)和成本上的優(yōu)勢和劣勢
- 基于從1)中獲得的知識，設(shè)計滿足業(yè)務(wù)要求，同時最小化成本的系統(tǒng)架構(gòu)（從優(yōu)化理論的角度說，就是基于業(yè)務(wù)要求的約束，對成本函數(shù)求最小值）
- 通過對AWS環(huán)境的監(jiān)控、分析，對成本進(jìn)行持續(xù)優(yōu)化
具體的，我們針對三個最主要的服務(wù)類別，運(yùn)用這個框架分別來談：
- 計算 - EC2，ECS，Lambda等
- 存儲 - S3，EBS，EFS，snowball等
- 網(wǎng)絡(luò) - Route53，ELB，VPC，Subnet，各種Gateway，等等
另外一些重要的服務(wù)比如Kinesis，RDS，DynamoDB，ElasticCache會專門再談。這一篇總結(jié)一下計算資源的優(yōu)化思路。
2. 計算
AWS的計算服務(wù)主要分三類，EC2，容器類（ECS，ECK，和Fargate），Serverless（Lambda）。說到這里不得不分享一下這張著名的圖片（出處不詳，侵刪）
AWS的計算服務(wù)，對應(yīng)的正是圖里“猴變?nèi)恕钡暮笕齻€階段。
2.1 EC2
據(jù)說EC2從region, availability zone, instance type到tenancy option, scheduling, 外掛的elastic inference有超過1百萬個option。這里面的細(xì)節(jié)很多，我嘗試抓一下重點(diǎn)
選合適的region: 對于有海外和全球業(yè)務(wù)的公司，選一個合適的region是很關(guān)鍵的。一般來說，亞太地區(qū)的東京、新加坡等region可以提供相對低的操作延時；美國本土的尤其是東海岸的region費(fèi)用更低；南美的AWS region的費(fèi)用是最高的。
選合適的instance type和size: 各種instance type的大致使用場景官方文檔已經(jīng)比較詳細(xì)，概括起來可以見下圖。選用的適合一方面根據(jù)自己的需求重點(diǎn)，另一方面也應(yīng)該計算單位CPU和內(nèi)存的獲取成本（如下表）。在同一個type下，一般來說size每增加1檔，相對的CPU性能（用AWS的專有單位ECU衡量）和內(nèi)存的量就會增大一倍，價格也會貴一倍；在同一個type和size下，一般更新的一代instance會有更好的性能并且更低的花費(fèi)，比如c5.large比起c4.large，CPU和內(nèi)存分別有12.5%和6.7%的性能提升，但是每小時的費(fèi)用卻降低了15%。所以能升級盡量升級。
避免使用商業(yè)license的操作系統(tǒng)：EC2 instance是可以選擇Redhat或者Windows操作系統(tǒng)的，但是相應(yīng)的花費(fèi)都會更高。如果不是基于行業(yè)政策、慣例這類商務(wù)需求，建議使用AWS Linux, Ubuntu這種免費(fèi)的操作系統(tǒng)。
對穩(wěn)定的使用場景購買reserved instance: 這個和手機(jī)話費(fèi)是一個道理，簽綁定合同比不簽的話費(fèi)要便宜；同樣是簽了合同，預(yù)存（預(yù)付）話費(fèi)多的更劃算。所以如果有一部分穩(wěn)定核心的計算資源是不會變動的，并且現(xiàn)金流允許，可以考慮購買3年的reserved instance并且pay upfront。這里要注意的是reserved instance是一種權(quán)益，有標(biāo)準(zhǔn)和可轉(zhuǎn)兩種，可以被轉(zhuǎn)換、拆分用在不同的instance type上，甚至不同的availability zone上。
圍繞spot instance設(shè)計架構(gòu)：spot instance隨時會有被terminate的可能，但是成本是同配置的on-demand instance的35%到15%，所以如果業(yè)務(wù)場景允許，完全值得思考如何能盡可能多的使用spot instance，并且做設(shè)計上的權(quán)衡。比如在一個load balancer背后用一部分reserved instance負(fù)擔(dān)一部分load，其余通過一個動態(tài)的spot instance的資源池來補(bǔ)充；再比如內(nèi)部的ETL和數(shù)據(jù)分析，也可以設(shè)計成使用spot instance來完成的批處理模式……針對spot instance設(shè)計的大致思路無非是把狀態(tài)存儲隔離開，盡量使用spot instance處理無狀態(tài)的部分。另外，spot instance可以被設(shè)置成最多6小時不被terminate。這樣的instance可以被用于對instance的穩(wěn)定性需求更高的場景。當(dāng)然這樣的策略的費(fèi)用會比一般的spot instance更高。
EC2還有一些比較有意思的選項，值得探索和嘗試：
- 非Intel CPU：AWS提供有AMD的ec2 instance，可以根據(jù)需要使用節(jié)約成本。例如m5a.large（AMD處理器）就比使用Intel CPU的m5.large節(jié)省大約10%的使用費(fèi)用。另外A系列的instance使用arm處理器，可以作為某些開發(fā)和生產(chǎn)環(huán)境使用。
- 可外部掛載的elastic graphics和elastic inference：專業(yè)的graphics或者深度學(xué)習(xí)的G和P instances的使用成本都比較高，如果使用場景并不需要一個專門優(yōu)化的instance，可以考慮使用一般的instance然后掛載外部的顯卡。比如深度學(xué)習(xí)的模型訓(xùn)練完成后的預(yù)測場景，是可以使用elastic inference的。
- Dedicated host和bare metal：默認(rèn)情況下，EC2 instances是虛擬主機(jī)，用戶是不知道也無法控制自己的instance是在哪一臺物理主機(jī)上的，也無法控制自己和誰在共享一臺物理主機(jī)。Dedicated host和bare metal提供的是不同于這種共享模式的專有資源，用于用更低的成本使用離線購買的軟件，比如Windows操作系統(tǒng)。
- 超線程設(shè)置：有些按CPU授權(quán)的軟件，可以在EC2 instance上設(shè)置關(guān)閉超線程以減少license開銷。
2.2 ECS, ECK, Fargate
微服務(wù)架構(gòu)的是現(xiàn)在最主流的互聯(lián)網(wǎng)和SaaS平臺的首選的架構(gòu)。這種架構(gòu)的種種在這里就不講了，有興趣可以去讀Sam Newman的著作《Building Microservices》，是一本非常值得讀的書。
這部分的費(fèi)用也相對簡單：
- ECS是免費(fèi)的
- ECK的每個cluster需要額外費(fèi)用
- Fargate是managed service，不需要手動管理instance。服務(wù)按照使用的CPU和內(nèi)存來收費(fèi) - 一般情況下Fargate的費(fèi)用會高于使用ECS和ECK，但是由于Fargate簡化了運(yùn)維的工作，所以對于初創(chuàng)公司往往是劃算的。（畢竟在咱們行業(yè)，高素質(zhì)的人才才是最昂貴的……）
2.3 Lambda
Serverless架構(gòu)帶來的運(yùn)維方面的簡化，對于研發(fā)和業(yè)務(wù)效率的提升是巨大的，這是很多新的初創(chuàng)公司擁抱serverless的初衷。但是serverless架構(gòu)的實際花費(fèi)還是需要細(xì)細(xì)思考和審計的。
Lambda的收費(fèi)模式看起來比較簡單，主要有兩個方面
- 請求數(shù)：us-east-1 region上每一百萬個請求$0.2
- 處理時間+系統(tǒng)資源：us-east-1 region上1GB內(nèi)存上限的Lambda每秒鐘$0.00001667
（另外一個對一些微軟技術(shù)棧的公司很有吸引力的點(diǎn)是，Lambda是可以用C#編寫邏輯，運(yùn)行在.net runtime上的。然而用戶確并不需要為因此用到的Windows server支付任何額外的軟件費(fèi)用）
從兩個角度看起來Lambda都不貴，然而實際使用的時候，還是有很多相關(guān)費(fèi)用需要注意。首先Lambda本身是個無狀態(tài)的邏輯單元，既不能直接接受API request，也不能持久化任何的狀態(tài)。這一特性決定了Lambda往往會和API Gateway和類似DynamoDB、Kinesis這樣的數(shù)據(jù)服務(wù)一起使用。在衡量是使用EC2，container還是Lambda的時候，這兩部分的連帶費(fèi)用需要一起考慮。另外比較復(fù)雜的狀態(tài)機(jī)系統(tǒng)可能還會用到step function作為狀態(tài)管理服務(wù)，也會增加實際的總使用成本。
其次，失敗的或者有未被處理的運(yùn)行時異常的異步和streaming request會被重試，產(chǎn)生額外的費(fèi)用。所以如果代碼質(zhì)量不高，沒有有效的處理各種異常，也會導(dǎo)致計劃外的成本產(chǎn)生。
另外Lambda并不適合處理高密度、長時間運(yùn)行的計算邏輯：第一，Lambda函數(shù)的執(zhí)行時間是有上限的，超過以后就會直接被中止，從而出發(fā)重試邏輯；第二，相比于EC2和container，Lambda的成本在處理相對高頻的計算邏輯時其實更高。書中有一個t2.micro instance和Lambda對比處理每秒一次的request時產(chǎn)生的費(fèi)用，結(jié)果是43.2，ec2 instance完勝。
即使拋開經(jīng)濟(jì)從純技術(shù)的角度，Lambda也有一些局限。比如分布式計算：Lambda的模式是讓數(shù)據(jù)流向邏輯，這樣當(dāng)前主流的基于“讓邏輯流向數(shù)據(jù)”的大數(shù)據(jù)系統(tǒng)，如Spark，Presto等，都很難在Lambda的世界里實現(xiàn)（開源世界有一些有趣的嘗試，比如：https://github.com/qubole/spark-on-lambda）。這使得很多的大數(shù)據(jù)分析場景目前都還無法使用Lambda來完成的。
綜上，對于Lambda的使用需要針對研發(fā)和業(yè)務(wù)需求，具體問題具體分析。目前來看，在相對輕量的，使用較少內(nèi)存，計算量不大的邏輯上使用Lambda是比較合理的選擇。
2.4 KAO框架在計算系統(tǒng)上的使用
在有了上述的這些基本知識（Knowledge）以后，公司就需要有經(jīng)驗和技術(shù)能力的人來根據(jù)這些外部約束來設(shè)計或調(diào)整系統(tǒng)架構(gòu)，這就是KAO中A(rchitecture)的部分。這兩年所謂的cloud-native，cloud-first架構(gòu)，就旨在在設(shè)計系統(tǒng)之初就以公有云服務(wù)的優(yōu)勢、限制和費(fèi)用模型作為重要的考量，來做出類似于系統(tǒng)的模塊化、技術(shù)棧等等基礎(chǔ)的設(shè)計決定。
曾有同事開玩笑道，幾十年前，架構(gòu)師是真的在從零設(shè)計系統(tǒng)。可現(xiàn)在，更像在用公有云的服務(wù)組裝系統(tǒng)。這也許對架構(gòu)師是一種新的約束，但是對于整個行業(yè)無疑是有推動作用的。
最后是O(peration)的部分。這一部分的細(xì)節(jié)很多，用文字很難寫清楚。一方面云服務(wù)的成本控制的確可以通過一次次自上而下的推動來達(dá)到目的。但是技術(shù)公司的增長和變化都是非常迅速的，比起靠組織架構(gòu)層層傳到一線來推動的成本管理，顯然一個好的運(yùn)營框架、流程、乃至文化，才是一個企業(yè)在云服務(wù)成本管理上成功的關(guān)鍵。我們所謂的優(yōu)化，應(yīng)該只是好的運(yùn)營框架下自然而然的、每天都在發(fā)生的事情。遺憾的是對于運(yùn)營，世界上從來就沒有統(tǒng)一的最優(yōu)解，哪怕僅僅只是針對AWS的費(fèi)用優(yōu)化。上文提到的這本書中有一個階梯形的示意圖，提供了一個做云計算成本控制的思路，可以作為參考：
- Governing Unit：這是個組織架構(gòu)問題。公司需要成立一個負(fù)責(zé)云計算基礎(chǔ)設(shè)施管理的團(tuán)隊（CCoE - Cloud Center of Excellence）
- 帳戶管理：設(shè)置和組織架構(gòu)和日常運(yùn)營相兼容的賬戶創(chuàng)建、管理、回收機(jī)制
- Govenance：針對組織架構(gòu)，對公有云服務(wù)的權(quán)限應(yīng)該進(jìn)行相應(yīng)的設(shè)計，保證最大授權(quán)的同時，減少不同團(tuán)隊的浪費(fèi)和誤操作（比如沒有人會希望自己的后端開發(fā)團(tuán)隊每個人都使用$24一小時的x instance來做開發(fā)環(huán)境）
- Tagging：使用標(biāo)簽對資源進(jìn)行技術(shù)、商務(wù)、資源管理等多角度的分類
- 數(shù)據(jù)監(jiān)控和報表：AWS平臺上特指使用CloudWatch和Cost Explorer收集各項服務(wù)的使用和閑置情況，并且定時生成報表用于監(jiān)控運(yùn)營成本
- KPIs：根據(jù)業(yè)務(wù)設(shè)定需要優(yōu)化的KPI，例如研發(fā)重的公司可以使用"cost per R&D unit"，主要業(yè)務(wù)邏輯在云端完成的公司可以使用"cost per business transaction".
- Cost optimization：針對KPI進(jìn)行優(yōu)化。例如修改ec2 instance的lifecycle policy，在一段時間的閑置后自動stop一個instance；調(diào)整賬戶權(quán)限、設(shè)置更好的部門quota，等等。措施可以宏觀可以微觀，具體問題具體分析。
