筆者所屬項(xiàng)目從零開(kāi)始接觸AWS，到目前在7個(gè)AWS地區(qū)部署上線，運(yùn)行維護(hù)將近4年的時(shí)間，著重就這幾個(gè)方面來(lái)展開(kāi)：

1. AWS的故障
2. 自動(dòng)伸縮規(guī)則
3. DDoS防護(hù)小建議

AWS的故障

從我們2011年接觸AWS至今，比較大一點(diǎn)的故障多集中于2012年，小故障每年零零星星還會(huì)有一些，總的來(lái)說(shuō)AWS的穩(wěn)定性和可靠性是越來(lái)越好。

這邊先簡(jiǎn)單介紹一下，AWS每一個(gè)區(qū)域(Region)都會(huì)有多個(gè)可用區(qū)(Availability Zone，簡(jiǎn)稱AZ)，可用區(qū)之間互相獨(dú)立，不受其他可用區(qū)故障的影響。

我們遇到過(guò)一個(gè)可用區(qū)(AZ)故障，最初的表象是網(wǎng)絡(luò)時(shí)斷時(shí)續(xù)，API Error Rate增加，AWS論壇里面也很有很多人報(bào)這個(gè)問(wèn)題，當(dāng)時(shí)沒(méi)有回應(yīng)。接下來(lái)，網(wǎng)絡(luò)開(kāi)始大面積中斷，直到整個(gè)可用區(qū)的EC2服務(wù)處于幾乎不可用的狀態(tài)，AWS網(wǎng)站開(kāi)始告知可用區(qū)故障的信息。

再往下，該地區(qū)的AWS Management Console也基本刷不出內(nèi)容。我們自己的監(jiān)控系統(tǒng)，產(chǎn)生大量的告警，且持續(xù)了一個(gè)多小時(shí)，當(dāng)時(shí)也嚇出一身冷汗。因?yàn)闊o(wú)法進(jìn)行直接的人工干預(yù)–AWS API直接返回503服務(wù)不可用。

另外，AWS文檔中提到的關(guān)于可用區(qū)掛掉后，新的機(jī)器會(huì)在另一個(gè)區(qū)自動(dòng)創(chuàng)建的功能，似乎當(dāng)時(shí)也沒(méi)有起效。不過(guò)，好在我們的機(jī)器都是多可用區(qū)部署，除個(gè)別非關(guān)鍵組件單點(diǎn)，以及AWS API暫時(shí)不可用外，另一個(gè)可用區(qū)的網(wǎng)絡(luò)并沒(méi)有受到影響，對(duì)外服務(wù)也沒(méi)有受到干擾。

這個(gè)事件過(guò)后，我們開(kāi)始反省，如果再發(fā)生要怎么辦?(后來(lái)還真發(fā)生了)

1. 保持多可用區(qū)部署且無(wú)狀態(tài)，避免單點(diǎn)服務(wù)，增加更細(xì)的監(jiān)控點(diǎn)(比如對(duì)所使用的AWS服務(wù)本身)。
2. ELB要打開(kāi)Cross-Zone Balancing功能，按實(shí)際機(jī)器數(shù)量來(lái)均分流量，默認(rèn)是按可用區(qū)均分流量。
3. 增加Fault Tolerance測(cè)試，類似Netflix Chaos Monkey的做法，評(píng)估我們所使用的每個(gè)AWS服務(wù)故障時(shí)，對(duì)服務(wù)可能產(chǎn)生的影響。
4. 跨地區(qū)的切換，比如：東京不可用，就把用戶流量切到新加坡。
5. 購(gòu)買AWS Support Plan，解決AWS故障時(shí)信息不透明且無(wú)人可幫忙的困境。

零星小故障總結(jié)：

1. 定時(shí)事件，雖然官方不叫故障，屬于我個(gè)人意見(jiàn)。有些底層的硬件存在故障或者需要更新，AWS會(huì)提前通知，到時(shí)間，通常情況下機(jī)器會(huì)被停掉重啟。比較煩人的點(diǎn)就是冷不丁就冒出來(lái)了，通常都必須要去關(guān)注，當(dāng)然不同的事件級(jí)別不同，出現(xiàn)時(shí)還是小心為好，找好維護(hù)時(shí)間窗，早點(diǎn)解決。
2. 有時(shí)候機(jī)器會(huì)被意外關(guān)掉，重啟或者短暫網(wǎng)絡(luò)故障，通常都不會(huì)有通知，而此時(shí)AutoScaling健康檢查也相應(yīng)失效。這種問(wèn)題現(xiàn)在變得越來(lái)越少，主要靠監(jiān)控發(fā)現(xiàn)，然后找AWS Support一起跟蹤確認(rèn)原因。
3. 如果使用DNS來(lái)幫助服務(wù)發(fā)現(xiàn)，就要小心Route53的API調(diào)用限制，因?yàn)镽oute53是全局服務(wù)，API調(diào)用數(shù)量的計(jì)算按一定時(shí)間內(nèi)，所有地區(qū)調(diào)用的總和。這個(gè)本質(zhì)上不算故障。

自動(dòng)伸縮

• 自動(dòng)伸縮(AutoScaling)可以認(rèn)為是AWS的核心功能，可根據(jù)用戶的業(yè)務(wù)需求和策略，自動(dòng)調(diào)整其彈性計(jì)算資源。
• 可用性和穩(wěn)定性是通過(guò)定時(shí)健康狀況檢查和自動(dòng)替換機(jī)器來(lái)做到的，包括EC2本身的健壯檢查、使用ELB的健康監(jiān)控，甚至自定義的監(jiān)控通過(guò)API反饋給AutoScaling服務(wù)。
• 伸縮規(guī)則分為兩種：簡(jiǎn)單規(guī)則和步進(jìn)規(guī)則。

a. 簡(jiǎn)單規(guī)則，只根據(jù)一條規(guī)則增減容量，比如當(dāng)平均CPU超過(guò)70%，增加兩臺(tái)機(jī)器。Cloud Watch會(huì)去自動(dòng)監(jiān)控這個(gè)指標(biāo)，達(dá)到時(shí)就會(huì)告警，觸發(fā)伸縮行為。這邊要注意的是伸縮行為的發(fā)生必須等待其他伸縮行為完成，再響應(yīng)告警。其中，增減的數(shù)量可以是定值也可以是百分比，同樣Cloud Watch中監(jiān)控到的數(shù)據(jù)，也可是通過(guò)API自定義灌入的。

b. 步進(jìn)規(guī)則，早先AWS并不支持，它包含一組規(guī)則。比如CPU在40%-50%時(shí)加一臺(tái)機(jī)器，50%-70%加兩臺(tái)，70%以上加四臺(tái)等 等。此時(shí)，若已有伸縮行為發(fā)生，該規(guī)則還會(huì)繼續(xù)響應(yīng)告警，中間會(huì)有一個(gè)預(yù)熱時(shí)間，時(shí)間不到，這個(gè)機(jī)器的指標(biāo)都不會(huì)計(jì)入。和簡(jiǎn)單規(guī)則相比，這種規(guī)則的伸縮行 為無(wú)鎖，且持續(xù)統(tǒng)計(jì)指標(biāo)，及時(shí)觸發(fā)，推薦使用。

關(guān)掉的機(jī)器不能做特定選擇，但會(huì)有一些模糊的規(guī)則：運(yùn)行時(shí)間最久的，隸屬的伸縮規(guī)則最老的，接近一個(gè)小時(shí)的開(kāi)機(jī)時(shí)間等等。

對(duì)于是事先準(zhǔn)備預(yù)編譯好的AMI還是通過(guò)配置管理工具現(xiàn)場(chǎng)安裝，對(duì)預(yù)熱時(shí)間比較敏感的服務(wù)，推薦是前者。

介紹完AWS中的自動(dòng)伸縮服務(wù)，引出一個(gè)關(guān)鍵問(wèn)題就是如何設(shè)置一個(gè)合理的規(guī)則，來(lái)比較精細(xì)地平衡成本和負(fù)載。這些都需要通過(guò)大量的測(cè)試來(lái)做權(quán)衡判斷。

設(shè)計(jì)伸縮規(guī)則，需要注意的地方是：

1. 這是一整個(gè)系統(tǒng)的調(diào)優(yōu)過(guò)程，涉及到的參數(shù)，可能不僅僅是規(guī)則本身，比如，使用ELB的，還要考慮到相關(guān)的性能參數(shù)。
2. 這個(gè)規(guī)則可能會(huì)隨程序的變革而變化，最好做到自動(dòng)化。
3. 加 機(jī)器要早，減機(jī)器要慢。負(fù)載開(kāi)始增加時(shí)早作打算，因?yàn)橹虚g有可能會(huì)產(chǎn)生新機(jī)器啟動(dòng)失敗等問(wèn)題，另外算上機(jī)器啟動(dòng)時(shí)間和服務(wù)到位的時(shí)間，早打算可以避免容量 跟不上的問(wèn)題;減機(jī)器時(shí)，要慢慢來(lái)，穩(wěn)穩(wěn)地進(jìn)行。否則，一方面避免連接被硬生生掐斷，另一方面由于減機(jī)器過(guò)快，而負(fù)載仍在，導(dǎo)致又要增加機(jī)器，這使得伸縮 行為太過(guò)頻繁，成本和穩(wěn)定性會(huì)受到影響。
4. 采集機(jī)器的CPU數(shù)據(jù)，盡量使用Cloud Watch的，本機(jī)采集的數(shù)據(jù)不一定準(zhǔn)確。
5. 應(yīng)用本身需要記錄足夠的性能數(shù)據(jù)，寫入日志，方便后期數(shù)據(jù)整理。
6. 如果有條件，可以嘗試建立一個(gè)簡(jiǎn)單的數(shù)據(jù)模型來(lái)實(shí)際分析。

DDoS防護(hù)小建議

這張圖描述的是2015年第二季度AWS上有關(guān)DDoS的情況。

一個(gè)DDoS攻擊大小是1.04Gbps，大于10Gbps的攻擊持續(xù)時(shí)間大約39分鐘。

圖片中展示了AWS防范DDoS的方式，目前是Traffic Shaping，然后通過(guò)優(yōu)先級(jí)來(lái)標(biāo)識(shí)，如果判斷是可能的攻擊，就減慢它的速度。

所以這邊的建議是：

1. 利用ELB、Route53、Cloudfront(CDN)等已經(jīng)具有防范DDoS功能的服務(wù)。
2. 將機(jī)器置于VPC中，設(shè)置合理的security group(防火墻)，避免直接對(duì)外服務(wù)。
3. 針對(duì)應(yīng)用層的攻擊，則需要WAF來(lái)幫忙。

這是一種AWS推薦的保護(hù)方式。最外層Cloudfront(CDN)和ELB，中間設(shè)置WAF，內(nèi)層ELB，最后到應(yīng)用部分。

#p#

Q&A

Q：請(qǐng)問(wèn)您覺(jué)得AWS和國(guó)內(nèi)的云廠商相比，最大的優(yōu)勢(shì)是什么?

A：從全球的角度來(lái)看，根據(jù)Gartner Report，是最領(lǐng)先的云服務(wù)。對(duì)于功能而言，AWS的服務(wù)多，質(zhì)量上乘。對(duì)于業(yè)務(wù)需求在海外的，AWS更為重要。有些國(guó)內(nèi)的云服務(wù)，基本上都是模仿著AWS起來(lái)的。

Q： 防DDoS架構(gòu)都需要自己搭建，AWS沒(méi)有提供外層包裝好的服務(wù)么?

A：AWS內(nèi)置的服務(wù)中已經(jīng)提供了防范DDoS的能力，大多數(shù)情況下都?jí)蛴茫皇轻槍?duì)應(yīng)用層的攻擊，需要額外的服務(wù)。另外有很多安全廠商和AWS有合作，在AWS Market可以得到相應(yīng)的安全服務(wù)。

Q：你們用過(guò)ECS服務(wù)嗎，功能上能否滿足你們的應(yīng)用需求?

A：我們目前正在嘗試采用ECS的方式來(lái)部署我們的服務(wù)，10月份的reInvent大會(huì)發(fā)布了Private Registry還有ecs-cli等一些工具，會(huì)使ECS更易使用。

Q：前端放不同az還好說(shuō)，后端數(shù)據(jù)庫(kù)不同az怎么搞?

A：數(shù)據(jù)庫(kù)如果是自己在EC2上部署的話，比如我們使用的Cassandra，多臺(tái)同樣可以采用不同AZ，至于AWS本身的數(shù)據(jù)庫(kù)服務(wù)RDS、Aurora、DynamoDB，里面有一個(gè)multi-AZ的功能。

Q：另外目前很多公司都采用了云服務(wù)，很多運(yùn)維同學(xué)比較關(guān)注的一個(gè)問(wèn)題是會(huì)對(duì)運(yùn)維成員帶來(lái)了一定的影響，因?yàn)楹芏喙ぷ魇褂迷品?wù)就可以解決。一種觀 點(diǎn)是，上云，是運(yùn)維人員的一個(gè)機(jī)會(huì)，因?yàn)槭褂迷品?wù)在某個(gè)方面來(lái)說(shuō)，對(duì)運(yùn)維人員的要求又提高了。目前熟悉AWS的運(yùn)維人員并不好招。請(qǐng)問(wèn)，您是怎么想的?

A：這個(gè)問(wèn)題，我自己也深有體會(huì)，Docker會(huì)這么火，里面也有這一層關(guān)系。

Q：自動(dòng)伸縮服務(wù)對(duì)于用戶這邊需要做哪些準(zhǔn)備，如何保證代碼持續(xù)更新，自動(dòng)伸縮也是可用的，就是我怎樣信任自動(dòng)擴(kuò)容出的機(jī)器?

A：主要還得要求機(jī)器中的服務(wù)實(shí)現(xiàn)無(wú)狀態(tài)，信任是建立在測(cè)試和監(jiān)控的基礎(chǔ)上。代碼持續(xù)更新是另一個(gè)問(wèn)題，持續(xù)發(fā)布的問(wèn)題，這個(gè)現(xiàn)有的解決方案也蠻多的，可以線下討論。

Q：亞馬遜云的故障率大概有多少，企業(yè)級(jí)應(yīng)用的價(jià)格是否可以接受?

A：目前根據(jù)我們使用的服務(wù)來(lái)看，故障率不高，穩(wěn)定性和質(zhì)量都蠻高的，剩下的都是一些小問(wèn)題，2012年的時(shí)候曾有5個(gè)大問(wèn)題(AWS專門解釋原因的)。對(duì)于價(jià)格可能要具體問(wèn)題具體看，對(duì)于我們而言，也做企業(yè)級(jí)應(yīng)用，7個(gè)地區(qū)的部署，還是能接受的。

Q：請(qǐng)問(wèn)有沒(méi)有部署將企業(yè)自己數(shù)據(jù)中心和AWS上服務(wù)互聯(lián)，推薦方式是?

A：公司里其他部門是有的，通過(guò)VPN的方式更安全。

Q：請(qǐng)問(wèn)ECS是否只有提供CD、CO、CI部分是否只能是用戶自己定制和對(duì)接，還有預(yù)計(jì)ECS什么時(shí)候會(huì)在中國(guó)站點(diǎn)發(fā)布呢?

A：AWS本身有提供code deploy、code pipeline、code commit持續(xù)發(fā)布的服務(wù)，可以和ECS一起使用，新發(fā)布的Private Registry也會(huì)對(duì)ECS的CI/CD帶來(lái)幫助。中國(guó)站點(diǎn)的情況，不了解。

Q：請(qǐng)問(wèn)老師是否知道目前亞馬遜在國(guó)內(nèi)數(shù)據(jù)中心部署進(jìn)展怎樣?

A：我們沒(méi)有使用，所以具體的細(xì)節(jié)不太了解。似乎是有限開(kāi)放，之前去reInvent開(kāi)會(huì)，有一個(gè)中國(guó)專場(chǎng)，很多國(guó)內(nèi)的公司都在使用了。

Q：你們有考慮過(guò)灰度發(fā)布嗎，AWS上對(duì)此是否有相應(yīng)支持?

A：有在使用，粒度現(xiàn)在還比較粗一點(diǎn)。一方面需要依靠應(yīng)用程序本身，可以做到配置管理。AWS的支持，還是需要通過(guò)架構(gòu)設(shè)計(jì)來(lái)做到，比如Router53支持帶權(quán)值的DNS，另外還有今年發(fā)布的API Gateway也可以拿來(lái)幫忙。

Q：目前AWS的一個(gè)趨勢(shì)是推廣基于事件的服務(wù)，就是逐步弱化服務(wù)器的概念，根據(jù)事件進(jìn)行相關(guān)服務(wù)，這也是領(lǐng)先其它云廠商的一個(gè)方面，請(qǐng)問(wèn)針對(duì)這一點(diǎn)，您是怎么想的?

A：本來(lái)我也想聊聊lambda這個(gè)服務(wù)，考慮到時(shí)間的問(wèn)題，沒(méi)有討論到。這確實(shí)是一個(gè)蠻好的想法。我了解的信息是，歐洲、北美有蠻多的公司采用了這種無(wú)服務(wù)器的方式，基本上不用自己來(lái)管理EC2機(jī)器，做好監(jiān)控就可以。好處就是快，壞處就是和AWS耦合太緊。

【本文來(lái)源：dockone分享群】