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