DevOps達人與AWS接觸五年來的運維經驗
筆者所屬項目從零開始接觸AWS，到目前在7個AWS地區部署上線，運行維護將近4年的時間，著重就這幾個方面來展開：
- AWS的故障
- 自動伸縮規則
- DDoS防護小建議
AWS的故障
從我們2011年接觸AWS至今，比較大一點的故障多集中于2012年，小故障每年零零星星還會有一些，總的來說AWS的穩定性和可靠性是越來越好。
這邊先簡單介紹一下，AWS每一個區域(Region)都會有多個可用區(Availability Zone，簡稱AZ)，可用區之間互相獨立，不受其他可用區故障的影響。
我們遇到過一個可用區(AZ)故障，最初的表象是網絡時斷時續，API Error Rate增加，AWS論壇里面也很有很多人報這個問題，當時沒有回應。接下來，網絡開始大面積中斷，直到整個可用區的EC2服務處于幾乎不可用的狀態，AWS網站開始告知可用區故障的信息。
再往下，該地區的AWS Management Console也基本刷不出內容。我們自己的監控系統，產生大量的告警，且持續了一個多小時，當時也嚇出一身冷汗。因為無法進行直接的人工干預–AWS API直接返回503服務不可用。
另外，AWS文檔中提到的關于可用區掛掉后，新的機器會在另一個區自動創建的功能，似乎當時也沒有起效。不過，好在我們的機器都是多可用區部署，除個別非關鍵組件單點，以及AWS API暫時不可用外，另一個可用區的網絡并沒有受到影響，對外服務也沒有受到干擾。
這個事件過后，我們開始反省，如果再發生要怎么辦?(后來還真發生了)
- 保持多可用區部署且無狀態，避免單點服務，增加更細的監控點(比如對所使用的AWS服務本身)。
- ELB要打開Cross-Zone Balancing功能，按實際機器數量來均分流量，默認是按可用區均分流量。
- 增加Fault Tolerance測試，類似Netflix Chaos Monkey的做法，評估我們所使用的每個AWS服務故障時，對服務可能產生的影響。
- 跨地區的切換，比如：東京不可用，就把用戶流量切到新加坡。
- 購買AWS Support Plan，解決AWS故障時信息不透明且無人可幫忙的困境。
零星小故障總結：
- 定時事件，雖然官方不叫故障，屬于我個人意見。有些底層的硬件存在故障或者需要更新，AWS會提前通知，到時間，通常情況下機器會被停掉重啟。比較煩人的點就是冷不丁就冒出來了，通常都必須要去關注，當然不同的事件級別不同，出現時還是小心為好，找好維護時間窗，早點解決。
- 有時候機器會被意外關掉，重啟或者短暫網絡故障，通常都不會有通知，而此時AutoScaling健康檢查也相應失效。這種問題現在變得越來越少，主要靠監控發現，然后找AWS Support一起跟蹤確認原因。
- 如果使用DNS來幫助服務發現，就要小心Route53的API調用限制，因為Route53是全局服務，API調用數量的計算按一定時間內，所有地區調用的總和。這個本質上不算故障。
自動伸縮
- 自動伸縮(AutoScaling)可以認為是AWS的核心功能，可根據用戶的業務需求和策略，自動調整其彈性計算資源。
- 可用性和穩定性是通過定時健康狀況檢查和自動替換機器來做到的，包括EC2本身的健壯檢查、使用ELB的健康監控，甚至自定義的監控通過API反饋給AutoScaling服務。
- 伸縮規則分為兩種：簡單規則和步進規則。
a. 簡單規則，只根據一條規則增減容量，比如當平均CPU超過70%，增加兩臺機器。Cloud Watch會去自動監控這個指標，達到時就會告警，觸發伸縮行為。這邊要注意的是伸縮行為的發生必須等待其他伸縮行為完成，再響應告警。其中，增減的數量可以是定值也可以是百分比，同樣Cloud Watch中監控到的數據，也可是通過API自定義灌入的。
b. 步進規則，早先AWS并不支持，它包含一組規則。比如CPU在40%-50%時加一臺機器，50%-70%加兩臺，70%以上加四臺等 等。此時，若已有伸縮行為發生，該規則還會繼續響應告警，中間會有一個預熱時間，時間不到，這個機器的指標都不會計入。和簡單規則相比，這種規則的伸縮行 為無鎖，且持續統計指標，及時觸發，推薦使用。
關掉的機器不能做特定選擇，但會有一些模糊的規則：運行時間最久的，隸屬的伸縮規則最老的，接近一個小時的開機時間等等。
對于是事先準備預編譯好的AMI還是通過配置管理工具現場安裝，對預熱時間比較敏感的服務，推薦是前者。
介紹完AWS中的自動伸縮服務，引出一個關鍵問題就是如何設置一個合理的規則，來比較精細地平衡成本和負載。這些都需要通過大量的測試來做權衡判斷。
設計伸縮規則，需要注意的地方是：
- 這是一整個系統的調優過程，涉及到的參數，可能不僅僅是規則本身，比如，使用ELB的，還要考慮到相關的性能參數。
- 這個規則可能會隨程序的變革而變化，最好做到自動化。
- 加 機器要早，減機器要慢。負載開始增加時早作打算，因為中間有可能會產生新機器啟動失敗等問題，另外算上機器啟動時間和服務到位的時間，早打算可以避免容量 跟不上的問題;減機器時，要慢慢來，穩穩地進行。否則，一方面避免連接被硬生生掐斷，另一方面由于減機器過快，而負載仍在，導致又要增加機器，這使得伸縮 行為太過頻繁，成本和穩定性會受到影響。
- 采集機器的CPU數據，盡量使用Cloud Watch的，本機采集的數據不一定準確。
- 應用本身需要記錄足夠的性能數據，寫入日志，方便后期數據整理。
- 如果有條件，可以嘗試建立一個簡單的數據模型來實際分析。
DDoS防護小建議
這張圖描述的是2015年第二季度AWS上有關DDoS的情況。
一個DDoS攻擊大小是1.04Gbps，大于10Gbps的攻擊持續時間大約39分鐘。
圖片中展示了AWS防范DDoS的方式，目前是Traffic Shaping，然后通過優先級來標識，如果判斷是可能的攻擊，就減慢它的速度。
所以這邊的建議是：
- 利用ELB、Route53、Cloudfront(CDN)等已經具有防范DDoS功能的服務。
- 將機器置于VPC中，設置合理的security group(防火墻)，避免直接對外服務。
- 針對應用層的攻擊，則需要WAF來幫忙。
這是一種AWS推薦的保護方式。最外層Cloudfront(CDN)和ELB，中間設置WAF，內層ELB，最后到應用部分。
#p#
Q&A
Q：請問您覺得AWS和國內的云廠商相比，最大的優勢是什么?
A：從全球的角度來看，根據Gartner Report，是最領先的云服務。對于功能而言，AWS的服務多，質量上乘。對于業務需求在海外的，AWS更為重要。有些國內的云服務，基本上都是模仿著AWS起來的。
Q： 防DDoS架構都需要自己搭建，AWS沒有提供外層包裝好的服務么?
A：AWS內置的服務中已經提供了防范DDoS的能力，大多數情況下都夠用，只是針對應用層的攻擊，需要額外的服務。另外有很多安全廠商和AWS有合作，在AWS Market可以得到相應的安全服務。
Q：你們用過ECS服務嗎，功能上能否滿足你們的應用需求?
A：我們目前正在嘗試采用ECS的方式來部署我們的服務，10月份的reInvent大會發布了Private Registry還有ecs-cli等一些工具，會使ECS更易使用。
Q：前端放不同az還好說，后端數據庫不同az怎么搞?
A：數據庫如果是自己在EC2上部署的話，比如我們使用的Cassandra，多臺同樣可以采用不同AZ，至于AWS本身的數據庫服務RDS、Aurora、DynamoDB，里面有一個multi-AZ的功能。
Q：另外目前很多公司都采用了云服務，很多運維同學比較關注的一個問題是會對運維成員帶來了一定的影響，因為很多工作使用云服務就可以解決。一種觀 點是，上云，是運維人員的一個機會，因為使用云服務在某個方面來說，對運維人員的要求又提高了。目前熟悉AWS的運維人員并不好招。請問，您是怎么想的?
A：這個問題，我自己也深有體會，Docker會這么火，里面也有這一層關系。
Q：自動伸縮服務對于用戶這邊需要做哪些準備，如何保證代碼持續更新，自動伸縮也是可用的，就是我怎樣信任自動擴容出的機器?
A：主要還得要求機器中的服務實現無狀態，信任是建立在測試和監控的基礎上。代碼持續更新是另一個問題，持續發布的問題，這個現有的解決方案也蠻多的，可以線下討論。
Q：亞馬遜云的故障率大概有多少，企業級應用的價格是否可以接受?
A：目前根據我們使用的服務來看，故障率不高，穩定性和質量都蠻高的，剩下的都是一些小問題，2012年的時候曾有5個大問題(AWS專門解釋原因的)。對于價格可能要具體問題具體看，對于我們而言，也做企業級應用，7個地區的部署，還是能接受的。
Q：請問有沒有部署將企業自己數據中心和AWS上服務互聯，推薦方式是?
A：公司里其他部門是有的，通過VPN的方式更安全。
Q：請問ECS是否只有提供CD、CO、CI部分是否只能是用戶自己定制和對接，還有預計ECS什么時候會在中國站點發布呢?
A：AWS本身有提供code deploy、code pipeline、code commit持續發布的服務，可以和ECS一起使用，新發布的Private Registry也會對ECS的CI/CD帶來幫助。中國站點的情況，不了解。
Q：請問老師是否知道目前亞馬遜在國內數據中心部署進展怎樣?
A：我們沒有使用，所以具體的細節不太了解。似乎是有限開放，之前去reInvent開會，有一個中國專場，很多國內的公司都在使用了。
Q：你們有考慮過灰度發布嗎，AWS上對此是否有相應支持?
A：有在使用，粒度現在還比較粗一點。一方面需要依靠應用程序本身，可以做到配置管理。AWS的支持，還是需要通過架構設計來做到，比如Router53支持帶權值的DNS，另外還有今年發布的API Gateway也可以拿來幫忙。
Q：目前AWS的一個趨勢是推廣基于事件的服務，就是逐步弱化服務器的概念，根據事件進行相關服務，這也是領先其它云廠商的一個方面，請問針對這一點，您是怎么想的?
A：本來我也想聊聊lambda這個服務，考慮到時間的問題，沒有討論到。這確實是一個蠻好的想法。我了解的信息是，歐洲、北美有蠻多的公司采用了這種無服務器的方式，基本上不用自己來管理EC2機器，做好監控就可以。好處就是快，壞處就是和AWS耦合太緊。
【本文來源：dockone分享群】
