aws成本優化
本文首發於我的blog
我們使用aws已經一年了，幾乎全部的線上和離線任務都已經遷移到了aws。但是看每個月賬單的時候發現公有云的花費真的多（具體多少不便透露，反正不算小客戶了）。我最近研究了下我們的賬單，發現有不少的優化空間，起碼可以把花銷降低一半甚至1/3。這篇文章是我在團隊內部分享如何優化公有云花費的一次整理。
成本優化的基本原則
選擇EC2的合適size
如果large可以滿足，就不要選擇xlarge。通過經驗+實際測試來得到確定合理的機器，不能拍腦袋。
儘量選新一代機器，價效比更高，比如選擇m5，不要選擇m4。
根據業務場景選擇機器，一般資料庫型別選擇r系列，計算密集型別選擇c系列，計算密集並且對記憶體也有要求的話選擇m系列。
彈性原則
資源用完了就釋放，再用的時候再申請。比如一個典型的場景是，開發申請了一臺機器用於測試，但是這臺機器每個周只會用兩次，在這種場景下每次用的時候開機，用完之後關機，這樣比7*27小時開機節省了大量的費用。
不僅如此，設計系統的時候也要做到彈性。流量多工系統就自動申請更多機器，流量下來了任務少了就主動釋放掉多餘的機器，這個過程需要完全是自動化的。
選擇合適的EC2模型
EC2有按需例項（用多少時間，給多少錢），預留例項（一次買一年的，不管用多少都得交一年的錢），spot例項（aws從資源池裡面空閒的資源，價格非常便宜，但是可能因為資源緊張導致申請機器的時候申請不到）。
關於價格，我用c4x.8large為例，按需/預留/spot的一小時價格分別為 10.844 / 3.871 / 2.7267。
選擇EC2模型的參考：
- 對於7*24小時執行的業務（比如線上服務，資料庫應用），購買預留例項最划算。
- 對於離線業務，採用spot例項最划算。並且跑完任務就自動回收機器最好。
- 對於短時間的測試等等，可以直接使用預留。
注意新建一個例項的時候不能指定這個機器用預留例項。因為機器買了之後是否匹配到預留例項是由aws作出的決定。並且aws有靈活的轉換因子，我舉個例子，我提前買了一個m4.8xlarge的預留，並且此時沒有例項命中了這個預留，這個時候我買了兩臺m4.4xlarge的按需例項，那麼就會命中m4.8xlarge的預留，一個m4.8xlarge等於兩個m4.4xlarge。
選擇合適的S3儲存
目前寧夏區有5種S3的儲存，針對長期和短期的資料提供了不同的方案。
標準儲存 0.1755元/GB 月
適合不斷頻繁訪問的熱資料。
標準-IA 0.1030029
適用於不常訪問但在需要時要求快速訪問的資料。標準 – IA 非常適合長期檔案儲存、來自同步和共享的舊資料、備份資料以及災難恢復檔案。
要求一個檔案最小128K，小於128K按照128K收費。
最少儲存30天，不足30天按照30天收費。
S3 One Zone-IA 0.08240232
和標準-IA區別是，S3資料只放在單個可用區，如果發生可用區故障會導致資料無法訪問。所以適合儲存一些備份的副本或者其他易於建立的資料(就算單個可用區故障導致資料丟失，還是可以建立回來)。
128K和30天限制和標準-IA相同。
Glacier 0.03006
至少儲存3個月，不足3個月刪除需要支付剩下的儲存時間費用。
3～5小時完成檢索，加速訪問可在5分鐘之內完成(需要支付一定費用)。
glacier deep archive 0.01082
12小時檢索出來資料，並且不能申請加速檢索。
檔案最小40K，最少存半年。
適合每年訪問幾次的資料。
以基因分析生產線為例，看下應該如何選擇儲存
- 配置檔案。因為每天訪問幾十次，所以放標準儲存。
- 生產線日誌檔案。根據業務方要求，這些檔案需要儲存三個月用於debug。這些資料也不是特別重要的資料，所以可以用one-zone，然後設定生命週期策略，3個月之後自動刪除。
- 業務方會不定期的來檢索這些資料，所以用標準-IA/不頻繁訪問。
- 每個開發自己的儲存空間，使用標準，且限制最大1T。
- 測試和內測環境，使用標準，限制最大1T。
- 批量重跑的結果，因為資料量很大，上百T，並且訪問不頻繁，所以可以一個月之後放glacier。需要讀的時候提前幾個小時說即可。
另外，S3提供了一個analytics-storage-class和智慧分層技術來幫助我們選擇合理的S3儲存。
選擇合適的EBS
選擇合適容量，合理估算。
對於資料庫應用，選擇SSD提供出色的隨機讀寫效能，對於大資料應用選擇HDD，提供出色吞吐量。並不是SSD一定比HDD效能好，需要根據業務選擇。
可以用HDD的，就不要用SSD，因為SSD價格是HDD的兩倍。
比如搭建測試k8s環境的時候，磁碟統一用HDD，正式環境的磁碟可以用SSD。
優化對外的網路流量
aws對於inbound流量和同一個zone的流量一般是不收費的，但是如果是outbound流量，費用就大了，以S3為例，傳出到internet的流量是0.933/G，10個T的資料就是1W，流量比儲存貴的多！
尤其是公有云和私有云公用的情況下，這塊一定梳理清楚。
監控，度量，改進
你度量什麼，就會得到什麼。
把成本作為metric之一監控起來非常有必要，這樣每天都可以看到公有云花費增長的趨勢，讓每個人有一個直觀的感受，讓每個工程師都開始專注成本，形成一種文化。
具體方案分成兩步。首先需要給每個資源打tag，具體參考AWS Tagging Strategies。然後拿到詳細的消費表格然後解析把資料儲存到Prometheus，然後通過Grafana展示出來。
總結
通過選擇合適的EC2，S3，和EBS，同時優化outbound流量可以極大降低成本。最重要的是去度量成本的花費並且監控起來，讓大家知道公有云的錢花在哪裡了，讓團隊每個人都去在意這件事情，形成一種文化。