筆者所屬項目從零開始接觸AWS，到目前在7個AWS地區(qū)部署上線，運行維護將近4年的時間，著重就這幾個方面來展開：

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

AWS的故障

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

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

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

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

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

這個事件過后，我們開始反省，如果再發(fā)生要怎么辦?(后來還真發(fā)生了)

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

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

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

自動伸縮

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

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

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

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

對于是事先準備預編譯好的AMI還是通過配置管理工具現(xiàn)場安裝，對預熱時間比較敏感的服務，推薦是前者。

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

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

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

DDoS防護小建議

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

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

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

所以這邊的建議是：

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

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

#p#

Q&A

Q：請問您覺得AWS和國內(nèi)的云廠商相比，最大的優(yōu)勢是什么?

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

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

A：AWS內(nèi)置的服務中已經(jīng)提供了防范DDoS的能力，大多數(shù)情況下都夠用，只是針對應用層的攻擊，需要額外的服務。另外有很多安全廠商和AWS有合作，在AWS Market可以得到相應的安全服務。

Q：你們用過ECS服務嗎，功能上能否滿足你們的應用需求?

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

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

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

Q：另外目前很多公司都采用了云服務，很多運維同學比較關(guān)注的一個問題是會對運維成員帶來了一定的影響，因為很多工作使用云服務就可以解決。一種觀 點是，上云，是運維人員的一個機會，因為使用云服務在某個方面來說，對運維人員的要求又提高了。目前熟悉AWS的運維人員并不好招。請問，您是怎么想的?

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

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

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

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

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

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

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

Q：請問ECS是否只有提供CD、CO、CI部分是否只能是用戶自己定制和對接，還有預計ECS什么時候會在中國站點發(fā)布呢?

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

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

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

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

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

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

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

【本文來源：dockone分享群】