AWS EC2 預留實例(Reserved Instance, 下文統(tǒng)一簡稱 RI) 簡單來說就是虛擬機包年, 一次性繳納一年的費用折扣非常誘人, 比按需啟動(也就是按小時計費) 便宜非常多, 但如何知道該買多少個 RI 呢? 尤其公司開始增長, 數(shù)據(jù)開發(fā)人員經(jīng)常會按需啟動一些計算集群的情況下, 如何優(yōu)化購買策略達到節(jié)省開支的目的?
找了一圈也沒有成熟的方案(有知道的可以隨時告訴我, 感激不盡), 利用一些時間自己寫了一個 '基于使用歷史優(yōu)化 RI 購買' 的方案, 簡單來說就是
讓開發(fā)
可勁兒造, 根據(jù)一段時間的使用歷史, 后續(xù)去購買 RI
先說說 AWS 現(xiàn)狀
- 每個實例按小時計費, 不足一小時按照一小時計費 (注意是每個實例, 比如 t2.micro 類型實例在一個小時內(nèi)啟動兩個(啟動一個, terminate 后再啟動一個, 再 terminate 要算兩個小時)
- 每個啟動的 EC2 實例都有唯一的一個ID: instance id
- 虛擬機啟動'慢', 基本上啟動一個節(jié)點要1分鐘+
- 所有的 EC2 信息可以通過 API 很容易拿到
- RI 針對的是對應的 AvailabilityZone 的相應類型, 比如在 cn-north-1a 購買的t2.micro RI 對 cn-north-1b 的 t2.micro 實例沒有用
第一種思路: 官方賬單
可以在賬戶中設置導出賬單, 指定一個 S3 bucket , 每個月會以 csv 文件的方式導出詳細賬單. 推薦大家都開啟這個功能. 但這個賬單沒有官方規(guī)范, 貌似一個月才出一次, 不能等到 on demand 付費了一個月才想起買RI 很不劃算.
第二種思路: 自行記錄是否買過 RI
單獨寫 Excel 也好, 或者在 EC2 上使用 tag 方式標記也好, 但這個終究是靠人力, 忘記標記/標記錯誤都是事兒. 如果使用tag 的方式, 如果這個 EC2 實例被 terminate 替換了(云計算的優(yōu)勢不就是玩兒壞了重來快么 >;<) 導致 tag 丟失等問題也是麻煩. 靠人力辦事, 不推薦
第三種思路: 根據(jù)使用歷史日志, 優(yōu)化購買 RI
實現(xiàn)很簡單, 跟 把大象放進冰箱 一樣, 僅需3步:
- 每隔2分鐘 dump 正在運行的 EC2 實例的日志, 扔進數(shù)據(jù)倉庫.
- 每隔幾天運行分析腳本, 生成帶圖的 Excel
- 瞅一眼 Excel, 看哪種類型的 EC2 實例需要買 RI 趕緊買
1. dump 日志
使用 aws ec2 describe-instances 很方便獲取所有在運行的 EC2 實例信息, JSON 格式非常容易解析. 重要的字段有如下幾個:
- InstanceId, 全局唯一ID
- State, 實例狀態(tài), 只有
running的才會被計費, 需要過濾一下 - AvailabilityZone, az 信息, 包含 aws region 信息.
- LaunchTime, 啟動時間
- Tags, 實例上的標簽, 后續(xù)可以根據(jù) Tag 按部門/系統(tǒng)分析使用狀況
- dump_time, 本次 dump 日志的時間. 這個字段 JSON 中沒有, 相當于給本次 dump 記錄一個時間
解析后直接扔數(shù)據(jù)倉庫. 剛剛不是說過 AWS EC2 啟動慢, 所以每隔2分鐘dump一次所有運行時的 EC2 日志, 一定不會錯過任何啟動的 EC2 節(jié)點. 其實推薦將整個 JSON 都存儲下來, 后續(xù)可以有其他用處.
為何采用 dump 日志的方式, 比如 cloudtrail 也可以獲取相關數(shù)據(jù)?
因為簡單! 幾行代碼就搞定, 數(shù)據(jù)倉庫是現(xiàn)成兒的. 扔進去就可以用 SQL 分析.
2. 分析報告
寫一個腳本, 根據(jù)時間范圍分析日志, 獲取每小時每個類型的 EC2 實例運行個數(shù), 以及 已經(jīng)購買的 AWS RI 現(xiàn)狀, 計算差值并畫圖.
比如這個 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 日之間的實例使用狀況. 然后根據(jù)結(jié)果生成 Excel 并畫一個三條線的線圖: 一條是運行的實例數(shù)量, 一條是已經(jīng)購買的該類型的實例數(shù)量, 還有一條就是需要買的 RI
3. 購買 RI
別搞錯 AvailabilityZone 就好了.
一點想法
由于 RI 是針對某個 AvailabilityZone 的某個類型的節(jié)點, 因此, 盡量使用少類型的 EC2 節(jié)點有時可以節(jié)省成本. 比如A系統(tǒng)需要 c3.4xlarge 類型節(jié)點10臺, B 系統(tǒng)需要20臺 c3.2xlarge, 如果有可能, 是不是可以都用一個類型的節(jié)點, 購買同樣的 RI, 等到系統(tǒng) resize了還可以空余 RI 給其他系統(tǒng). 針對 AvailabilityZone, 如果不需要高可用, 盡量在同一個 AvailabilityZone, 比如計算密集型的系統(tǒng).
總結(jié)
云計算這種形式的確帶來了很大效率的提升, 但至于如何節(jié)省成本, 還是要看如何做容量規(guī)劃, 省錢還是要靠小算盤.
容易擴容也意味著容易浪費
比如, 之前物理機/租機房時代, 公司上架服務器慢, 做數(shù)據(jù)開發(fā)臨時跑大計算想擴容有錢都花不出去, 只能在現(xiàn)有集群上慢慢等, 慢慢優(yōu)化; 現(xiàn)在用了 AWS, 隨隨便便加計算資源只要計算集群做得好, 非常容易, 如果不做限制, 大家都想快出結(jié)果因此 on demand 啟動大量節(jié)點計算, 雖說節(jié)省了時間, 但由于隨機性太大無法購買 RI 節(jié)省成本. 總體來說還是有可能浪費.
ROI 啊.
-- EOF --
