公有云的一個優(yōu)勢就是彈性伸縮, 那么如何衡量一家云計算客戶的彈性使用水平呢? 我設計了一個指標: 計算實例次日存活率(compute_instance_2nd_day_survival_ratio). 指標含義是: 計算第 N+1 天的所有運行過的計算實例中, 非當天啟動的計算實例的占比(也就是在第 N 天就出現過的計算實例占比是多少). 其中計算實例的含義可以指虛擬機, 也可以指其他計算資源. 這個指標越低, 代表計算資源都是當天啟動的, 那么就可以從側面反映該公司的計算資源都是彈性伸縮的.
指標計算方法
計算方法也非常簡單, 拿 AWS 的 EC2 為例, 為了計算 compute_instance_2nd_day_survival_ratio, 大概思路如下:
1. AWS 中所有的 EC2 都有一個全局唯一 ID, 類似 i-13dvwdfw. 每天收集所有運行過的 EC2 實例 ID, 按天存儲到一張表中
注意是采集所有運行過的 EC2 instance_id, 啟動后關閉也算在內.
2. 通過一個簡單的 SQL JOIN 即可實現計算, 類似 SQL 如下:
-- 第 N +1 天的時間SET data_date='2017-07-16';-- 第 N 天的時間SET data_date_base='2017-07-15;
WITH new_ids AS
-- 第 N + 1天的所有 instance_id 去重
( SELECT instance_id
FROM devops.ec2_instance_log
WHERE data_date = $
GROUP BY 1),
-- 第 N 天的所有 instance_id 去重
base_ids AS
( SELECT instance_id
FROM devops.ec2_instance_log
WHERE data_date = $
GROUP BY 1)
-- 計算兩天能夠 JOIN 上的 instance_id 數量和總共 instance_id 數量
-- 比例數字后續(xù)再自行處理
SELECT sum(if(base_ids.instance_id IS NOT NULL, 1, 0)) AS total_old_cnt,
sum(if(new_ids.instance_id IS NOT NULL, 1, 0)) AS survival_old_cnt
FROM base_ids
LEFT OUTER JOIN new_ids ON base_ids.instance_id = new_ids.instance_id
指標背后的思考
既然要最大限度的發(fā)揮彈性計算的能力, 背后的訴求是根據負載動態(tài)調整計算資源, 最大限度滿足計算資源需求, 而在低谷期間釋放多余計算資源避免浪費. 那么計算實例的隔日存活率就代表著這部分計算實例從第 N 天一直存活到次日(第 N+1 天), 也就是沒有”彈”. 得知這個數值后, 持續(xù)追問背后的原因: 為什么沒有自動彈?
再抽象一層來說, 其實是理念的變革, 不知道你是否聽說過 Pets vs Cattles 這個著名的說法, 大概意思就是之前大家的服務器都是當做寵物(Pets) 來對待的, 細心照顧, 可一旦出現故障, 恢復的成本就會非常高; 而如果起初設計時計算資源就是作為牲口(Cattles)來對待的, 按需取用, 一定會倒逼自己的系統(tǒng)設計容錯性大幅度提升, 也避免浪費, 節(jié)省成本.
如何更好的實現彈性
基礎設施構建
想要讓更好的實現彈性, 必須實現 Immutable Infrastructure, 讓自己的基礎設施是有版本的, 可測試的, 并且是無法變更的; 如果需要變更, 重新構建一個新的版本. 實現的工具也非常多, 個人非常喜歡 Hashcorp 實現的工具 Packer, 支持跨廠商的虛擬機 Image 構建, 非常方便.
彈性伸縮產品支持
彈性伸縮產品的基礎架構抽象上來說, 可以分成三個部分:
1. 感知
感知模塊負責收集和統(tǒng)計核心彈性驅動指標, 作為后續(xù)決策模塊的技術數據輸入; 例如 AWS 的 ASG 可以通過 CloudWatch 中的 Metric 作為感知模塊.
2. 決策
在基于感知模塊的數據, 針對預先配置的規(guī)則判斷當前是否需要觸發(fā)擴容或者縮容動作.
3. 行動
在接收到決策模塊的擴容或者縮容指令后, 進行對應的操作. 例如如果想擴容虛擬機, 行動模塊需要調用對應的 EC2 啟動 API, 提供 ImageID/AZ/初始化腳本等參數, 請求 EC2 服務確定新的虛擬機節(jié)點.
具體每家云廠商實現如何, 就看各家的功力了. 我個人使用比較多的是 AWS 家的 Autoscaling Group(下文簡稱 ASG), 非常好用.
IaC: Infrastructure as Code 基礎設施即代碼
所有基礎設施代碼化, 通過代碼定義自己基礎設施, 進一步提升自己的基礎設施靈活性和容錯. 例如如果自己系統(tǒng)里的 ASG 都是通過運維同學點擊鼠標構建的, 哪天誤刪了恢復起來就蛋疼了. 這里實名推薦 Hashicorp 公司的 Terraform.
總結
彈性的確是可以帶來計算資源的不必要的浪費, 但是否會最終節(jié)省云計算費用就是另外一個話題了, 畢竟成本優(yōu)化也是個技術活. 不過總體來說, 如果自己公司的業(yè)務是典型的白天扛流量, 夜間扛計算的場景, 更敏捷更彈性的基礎架構一定會帶來成本的節(jié)省.
