AWS EC2 預留實例(Reserved Instance, 下文統一簡稱 RI) 簡單來說就是虛擬機包年, 一次性繳納一年的費用折扣非常誘人, 比按需啟動(也就是按小時計費) 便宜非常多, 但如何知道該買多少個 RI 呢? 尤其公司開始增長, 數據開發人員經常會按需啟動一些計算集群的情況下, 如何優化購買策略達到節省開支的目的?
找了一圈也沒有成熟的方案(有知道的可以隨時告訴我, 感激不盡), 利用一些時間自己寫了一個 '基于使用歷史優化 RI 購買' 的方案, 簡單來說就是

讓開發可勁兒造, 根據一段時間的使用歷史, 后續去購買 RI

先說說 AWS 現狀

1. 每個實例按小時計費, 不足一小時按照一小時計費 (注意是每個實例, 比如 t2.micro 類型實例在一個小時內啟動兩個(啟動一個, terminate 后再啟動一個, 再 terminate 要算兩個小時)

1. 每個啟動的 EC2 實例都有唯一的一個ID: instance id
2. 虛擬機啟動'慢', 基本上啟動一個節點要1分鐘+
3. 所有的 EC2 信息可以通過 API 很容易拿到
4. RI 針對的是對應的 AvailabilityZone 的相應類型, 比如在 cn-north-1a 購買的t2.micro RI 對 cn-north-1b 的 t2.micro 實例沒有用

第一種思路: 官方賬單

可以在賬戶中設置導出賬單, 指定一個 S3 bucket , 每個月會以 csv 文件的方式導出詳細賬單. 推薦大家都開啟這個功能. 但這個賬單沒有官方規范, 貌似一個月才出一次, 不能等到 on demand 付費了一個月才想起買RI 很不劃算.

第二種思路: 自行記錄是否買過 RI

單獨寫 Excel 也好, 或者在 EC2 上使用 tag 方式標記也好, 但這個終究是靠人力, 忘記標記/標記錯誤都是事兒. 如果使用tag 的方式, 如果這個 EC2 實例被 terminate 替換了(云計算的優勢不就是玩兒壞了重來快么 >;<) 導致 tag 丟失等問題也是麻煩. 靠人力辦事, 不推薦

第三種思路: 根據使用歷史日志, 優化購買 RI

實現很簡單, 跟 把大象放進冰箱 一樣, 僅需3步:

1. 每隔2分鐘 dump 正在運行的 EC2 實例的日志, 扔進數據倉庫.

1. 每隔幾天運行分析腳本, 生成帶圖的 Excel
2. 瞅一眼 Excel, 看哪種類型的 EC2 實例需要買 RI 趕緊買

1. dump 日志

使用 aws ec2 describe-instances 很方便獲取所有在運行的 EC2 實例信息, JSON 格式非常容易解析. 重要的字段有如下幾個:

• InstanceId, 全局唯一ID
• State, 實例狀態, 只有 running 的才會被計費, 需要過濾一下
• AvailabilityZone, az 信息, 包含 aws region 信息.
• LaunchTime, 啟動時間
• Tags, 實例上的標簽, 后續可以根據 Tag 按部門/系統分析使用狀況
• dump_time, 本次 dump 日志的時間. 這個字段 JSON 中沒有, 相當于給本次 dump 記錄一個時間

解析后直接扔數據倉庫. 剛剛不是說過 AWS EC2 啟動慢, 所以每隔2分鐘dump一次所有運行時的 EC2 日志, 一定不會錯過任何啟動的 EC2 節點. 其實推薦將整個 JSON 都存儲下來, 后續可以有其他用處.
為何采用 dump 日志的方式, 比如 cloudtrail 也可以獲取相關數據?

因為簡單! 幾行代碼就搞定, 數據倉庫是現成兒的. 扔進去就可以用 SQL 分析.

2. 分析報告

寫一個腳本, 根據時間范圍分析日志, 獲取每小時每個類型的 EC2 實例運行個數, 以及 已經購買的 AWS RI 現狀, 計算差值并畫圖.

help_info.png

比如這個 Query:

SELECT concat(substr(dump_time, 1, 13), ':00:00') AS instance_hour,
       az,
       instance_type,
       count(DISTINCT instance_id) AS cnt
FROM testdb.aws_instance_log
WHERE data_date BETWEEN '2016-02-11' AND '2016-02-15'
  AND json_extract_scalar(raw_json, '$.State.Name') = 'running'
GROUP BY concat(substr(dump_time, 1, 13), ':00:00'),
         instance_type,
         az
ORDER BY az,
         instance_type,
         instance_hour

是計算 2016-02-11 至 2016-02-15 日之間的實例使用狀況. 然后根據結果生成 Excel 并畫一個三條線的線圖: 一條是運行的實例數量, 一條是已經購買的該類型的實例數量, 還有一條就是需要買的 RI

3. 購買 RI

別搞錯 AvailabilityZone 就好了.

一點想法

由于 RI 是針對某個 AvailabilityZone 的某個類型的節點, 因此, 盡量使用少類型的 EC2 節點有時可以節省成本. 比如A系統需要 c3.4xlarge 類型節點10臺, B 系統需要20臺 c3.2xlarge, 如果有可能, 是不是可以都用一個類型的節點, 購買同樣的 RI, 等到系統 resize了還可以空余 RI 給其他系統. 針對 AvailabilityZone, 如果不需要高可用, 盡量在同一個 AvailabilityZone, 比如計算密集型的系統.

總結

云計算這種形式的確帶來了很大效率的提升, 但至于如何節省成本, 還是要看如何做容量規劃, 省錢還是要靠小算盤.

容易擴容也意味著容易浪費

比如, 之前物理機/租機房時代, 公司上架服務器慢, 做數據開發臨時跑大計算想擴容有錢都花不出去, 只能在現有集群上慢慢等, 慢慢優化; 現在用了 AWS, 隨隨便便加計算資源只要計算集群做得好, 非常容易, 如果不做限制, 大家都想快出結果因此 on demand 啟動大量節點計算, 雖說節省了時間, 但由于隨機性太大無法購買 RI 節省成本. 總體來說還是有可能浪費.

ROI 啊.

-- EOF --