Amazon雲端服務大當機的啟示(2)
連鎖當機耗用API協調系統的資源，災情蔓延其他服務區域
但是，災情還沒結束，因為Amazon的架構設計上，一個地區雖然會有多座資料中心來提供AZ服務區域，但是同一個地區內的所有AZ的EBS是共用同一套
EBS
控制系統，這間北維吉尼亞資料中心內EBS提出的大量建立複本要求，塞爆了美東地區的EBS控制系統，導致這個地區的EBS控制系統無法協調其他3座資料
中心的EBS節點，來進行各種EBS
API請求，即便這些EBS的資料一切正常也無法有效運作，整個美東地區仰賴EBS的EC2和RDS服務至此全數停擺。
Amazon在事件爆發後半小時就發現網路設定錯誤的問題，維護人員花了幾個小時，先停止了這個自動建立Volume的API，也將網路設定恢復正常，但
是大量的EBS複本建置需求，已經耗用了原有的實體儲存空間，Amazon不敢驟然中止所有的EBS
Volume，擔心會造成正在處理的資料遺失，只能先透過網路切割的方式，先將北維吉尼亞資料中心的EBS服務和美東地區的EBS控制系統隔離，並且建立
新的EBS控制系統，協助其他3個服務區域內的EBS以及仰賴EBS的RDS服務回復正常，讓不在問題服務區域的網站可以先恢復運作。
接著，Amazon開始擴充實體設備來增加問題服務區域的儲存容量，讓等待建立複本的re-mirror程式有足夠的實體空間和運算資源可以完成待執行的指令。因為資料中心擴充實體機器的速度很慢，這也是導致少數服務得等3天才回復正常的原因。
自動化的漣漪效應
 |
| 《AWS雲端企業實戰聖經》作者林允溥認為：「很多網站只是將機房搬上雲端，卻沿用傳統資料中心的運作概念，沒有善用雲端的彈性擴充能力來建立備援。」 |
《AWS雲端企業實戰聖經》作者林允溥認為，這次大當機事件是一種自動化的漣漪效應，這些自動化程式沒有設定終止條件來限制執行次數，或是逐漸拉長執行自動化程式的時間間隔，一旦發生人為疏失，觸發了這個程式設計漏洞，惡性循環不斷耗用資源直到服務停擺。
林允溥表示，這類自動化程式的演算法應該設計很短暫的Time-Out時間，指令等待觸發的時效很短，萬一請求失效，等待再次請求的時間也應逐步延長，例
如第二次請求間隔1 秒，第三次則間隔2秒，第四次4秒等指數延長等待時間的方式，並且設定重試次數等作法，就可以延緩自動化程式造成的連鎖風暴。
不過，林允溥表示，對於快速成長的網站，網站主容易只專注於開發新功能或提供新服務，卻沒有累積足夠的網站擴充經驗，尤其是用如何建置穩定又具高擴充性的
自動化工具，即便像Amazon這類全球流量排名前15大的網站，他們開發的自動化工具都會有盲點，更何況是經驗不足的新興網站。
累積足夠手動經驗再全面自動化
林允溥建議，網站主即便開發出了自動化網站擴充或維護工具，也不要輕易導入全自動化，而是先採取自動化程式的最後一關是人工切換的作法，等到累積足夠多的操作經驗後，才導入全面自動化。
這次大當機事件後，有許多網站也發文反省，大量仰賴Amazon
EC2服務的同時，卻忘了自行建立妥善的備援設計。林允溥解釋，很多網站將所有服務集中在Amazon單一服務區域內，而沒有建立跨區備援，一來因為單一
服務區內的網路傳輸免費，二來要進行跨區備援也會增加系統架構的複雜性，管理維護的難度也就更高。
林允溥認為：「很多網站只是將機房搬上雲端，卻沿用傳統資料中心的運作概念，沒有善用雲端的彈性擴充能力來建立備援。」例如遇到這類整間資料中心失效的情
況，就可以先在另一個地區建立新的EC2虛擬機器和EBS儲存內容，快速回復系統來接手服務，等到問題排除後，再切換回北美服務區域的主機中。
不過，他認為，平時必須先將EBS的資料備份到亞洲地區資料中心的S3服務中，同時也預先建立跨地區的備援計畫，並且定期演練確保計畫可行才有辦法因應這類大規模當機情況的發生。
當機事件回復正常後，Amazon也在官方部落格上發文檢討，承諾會強化網路設定變更時的稽核，以降低人為錯誤的風險。
另外從這次當機事件的經驗中，Amazon未來會預先備妥足夠的實體設備，來因應類似突發性的需求，以縮短擴充實體設備時的裝機時間。
在系統程式的改善上，會修改EBS複本程式的自動化程式判斷邏輯，增加如限制條件等作法，以免發生這種會陷入無限迴圈的情況，以避免突發性大量需求塞爆服務後衍生的其他問題，並承諾會重新檢討所有自動化程式，避免其他程式也有類似的盲點。
另一方面，Amazon也承諾要解決現有跨地區自動化工具不足的問題，首先將讓所有Amazon提供的服務，可以支援多個AZ服務區域，包括原本只能在單
一服務區域存取的Amazon
VPC，未來也可跨服務區域存取或部署，Amazon還會提供更多跨AZ服務地區的工具，方便網站主建立高可用性的架構，即使遇到單一資料中心失效，還能
將服務轉移到其他服務區域中。
最後，Amazon還會加快EBS叢集的資料回復機制，方便網站主能自動化復原EBS上的Volume資料，提高從備援機制中恢復服務的時效，也會改善現有網路通訊和服務監控工具，來提高對營運狀態的監控等。
| 快速認識Amazon雲端服務 |
全球最大雲端服務網站Amazon所推出的雲端服務包括了20多種不同的服務，統稱為AWS（Amazon Web
Services）。從2002年起，Amazon就開始提供內部服務給限定用戶使用，到了2006年3月，更是推出了第一個AWS服務Amazon
S3儲存服務，之後陸續推出了涵蓋儲存、運算、資料庫、網路服務、訊息傳遞、監控、付款等各式各樣的網路服務。
《AWS雲端企業實戰聖經》作者林允溥表示，使用AWS的困難是，即使只是要新增一個虛擬機器來建置網站，仍然要熟悉AWS相關網路、儲存、資料庫等服務
的API使用方式，才能架構出正式上線所需的執行環境。他建議，企業可以先從S3儲存服務開始熟悉AWS的API使用方式，以及透過憑證來授權服務的方
式。
另外，在使用AWS服務之前，企業還需要了解地區（Region）和服務區域或稱為所在地（Availability
Zone）觀念的差別，地區是實體地理的區域，例如有美國東部、歐洲西部、亞洲區等，一個地區中會有很多座資料中心，1個服務區域就代表了1座資料中心。
AWS服務對於跨區域或跨服務區域的計費方式有很大差異，例如同一地區內的EC2主機互相傳輸不收費，但跨地區就要計價。不同服務區域對全球各地的延遲時間也不同。企業要就近選擇適當的地區和服務區域的使用方式。 |
| AWS主要服務整理
● 運算：EC2、Elastic MapReduce、Auto Scaling
● 內容發布：CloudFront
● 儲存：S3、EBS、AWS輸入輸出
● 資料庫：SimpleDB、RDS
● 網路：Route 53、ELB、VPC
● 訊息：SQS、SNS、SES
● 監控：Amazon CloudWatch
● 付款：FPS、DevPay
● 協同工作：Mechanical Turk
● 網頁流量監控：Alexa網頁資訊服務
資料來源：Amazon，iThome整理，2011年7月 |
Netflix安全上雲端的秘訣
影片租賃服務Netflix是北美網路流量最大的網站，全美網路流量有2成都是用來傳輸Netflix提供的影片。Netflix在2010年10月時才
決定改用Amazon的EC2來提供所有的線上影音服務，不再建置新的資料中心。全美流量最大的服務商的這項背書，無疑是對Amazon雲端服務穩定性的
一大保證。
不料，今年4月21日凌晨，Amazon北維吉尼亞機房發生了EBS（Elastic Block Service）服務大當機事件，
完全仰賴EC2提供服務的Netflix自然也受到波及，但是只有發生影音傳輸速度變慢的情況。雖然在當機期間，用者抱怨大幅增加，但沒有像有些知名網站
如Quora幾乎是服務完全中斷的情況，Netflix等於是順利度過這次當機的考驗。
當Amazon美東地區（Region）的一座AZ服務區域（Availability
Zone，相當於是一座資料中心）失效時，Netflix工程團隊就決定趁使用者流量還未達到顛峰前，將所有服務撤離這個區域，並且手動設定流量負載規
則，避開發生問題的地區，確保服務不致中斷，也因此而沒有發生嚴重的災情。
在事件發生之後，負責IT架構、電子商務和系統工程的Netflix總監Adrian Cockcroft與2位同僚聯名在官方部落格上發表長文，分享Netflix順利度過這次當機事件的關鍵，以及從中得到的教訓。
 |
| 負責IT架構、電子商務和系統工程的Netflix總監Adrian Cockcroft在官方部落格上分享這次Amazon大當機因應經驗。 |
5大防當機設計
Netflix表示，2010年底時，Netflix將全數服務轉移到Amazon上時，也重新調整了IT架構，這個新架構讓Netflix度過這次的
AWS審判日的考驗。其中最重要的幾項防當機關鍵包括了，Stateless
Services（無狀態服務）設計、跨區域儲存資料、功能移除機制、N+1備援、以及大量使用雲端解決方案的服務架構。
首先，無狀態服務的設計是Netflix重新打造IT架構的重點，新架構會讓所有的API服務可以指派給任意的虛擬機器（Instance）來提供服務，
而不需要綁定在特定的伺服器上，有些必須要持續使用的Session資料，例如每一次放進購物車中的資料，則由另外的Session伺服器來統一管理，讓
前端提供服務的伺服器不需要保留這些統合性的資料。這個設計的好處是，可以隨時切換服務節點，快速由新節點取代發生問題的節點。
其次，Netflix平時會定期將提供給使用者的影音內容和伺服器資料備份到Amazon的其他服務區域，遇到單一AZ服務區域發生問題時，就可以由其他區域快速接手提供，而不用再等待資料回復的時間。
第三、為了避免部分失功能拖累了整套系統，Netflix也預先設計了多種快速移除部分功能的機制，遇到有少數元件發生問題，可以先關閉部分功能，確保其
他服務可以繼續執行。這些功能移除機制的設計原則包括了能快速中止元件（Fail
Fast）、提供候補功能（Fallbacks）、可直接移除的功能（Feature Removal）等設計。
第四，在備援設計上，Netflix採取了N+1備援的作法，任何時刻，都會提供比使用量更多的運算資源，而且不是採用主從式的備援，或是部分離線的備
援，而是隨時都會額外多一份資源的作法。Netflix將服務主機散布在Amazon美東地區4座服務區域（資料中心）的3座，每個服務區域內都會有提供
額外AWS備援，以避免單一區域服務失效，雖然每年會增加三分之一的費用，但可以確保影音服務不會中斷。
最後一項就是大量使用雲端解決方案的作法，相較於過去實體資料中心的作法，雲端IT架構讓Netflix的應用系統很容易地在不同資料中心間切換，也搭配了NoSQL資料庫來提高可用性，另外還使用S3儲存來提供更耐用的資料備份。
整體性自動化工具不足與負載設計盲點
不過，在這次因應Amazon當機事件的過程中，Netflix也發現幾項有待改進的缺失，第一個就是手動轉移全數服務的過程中，原本用來自動部署和調整
AWS設定檔的工具，無法同時調整所有的設定檔，過去只為局部性調整或特定用途而開發工具，缺乏一套整體性的自動化工具，例如無法用一個指令就將某一類服
務全數搬移到另一個區域。換句話說，每一種服務的負責團隊，都得人工手動切換，也提高了轉移過程的風險。Netflix表示，因為服務規模太大，大量轉換
時的工具不足，未來會先簡化轉移程序，增加更多自動化設計和工具。
其次是負載平衡的盲點，原本Netflix使用Amazon提供的ELB負載平衡服務來切換所有前端服務的流量，但因ELB只能在Amazon的單一服務
區域中分散流量，而無法達到跨區域的負載平衡，如果在單一區域中過多伺服器當機，就會讓負載平衡機制失效，進而讓整個區域的服務中斷。
ELB是一種2階層式的負載平衡設計，第一層是DNS負載平衡切換，第二層則是由AWS直接提供的ELB服務，在這次當機事件中，EBS失效問題也影響了
AWS的服務，進而導致這個服務區域的ELB發生問題。Netflix打算建立另一個中間層的負載平衡機制，不使用ELB機制，而且可以跨不同服務區分散
流量。
3項改進重點
綜和這次當機事件，Netflix決定進行3項改進作法，首先是建立更多失效測試機制，原本Netflix就自行打造了一個自動化測試服務Chaos
Monkey，可以用來模擬系統失效的情況，例如臨時中止某些服務，來測試備援機制的運作。但是這個Chaos
Monkey沒有考慮到整座資料中心失效的情況，只考量到資料中心內少數虛擬機器失效的情況，未來Netflix會加入整座資料中心失效的模擬。
另外，Netflix也決定開發跨地區（Region）的自動化工具，因為Amazon提供的自動化備援機制或備份機制，只能在單一地區內跨服務區域，例
如美東地區的服務區域，但就無法自動跨越美東地區和亞洲地區等多地區。這次Netflix工程團隊只能手動將服務轉移到其他地區的AZ服務區域。未
來，Netflix也會針對全球各地區的服務來設計可以跨地區的影音服務，這樣的設計也有助於提高服務可用性。
最後，為了降低對EBS儲存資源的依賴，Netflix決定使用S3備份服務來提供靜態的虛擬機器映象檔備份，並且要將MySQL EBS資料庫轉移到Cassandra這類NoSQL資料庫上，利用EC2本地端資料庫搭配分散式設計來確保資料庫服務。
雖然Amazon發生了這樣的大當機事件，但Netflix仍然認為，「使用Amazon的AWS服務來取代實體資料中心的策略是正確的方向，這次大當機
只是一次考驗，這些從中學習到的經驗，更加確認這個方向的信心」。負責Netflix整體架構的Adrian Cockcroft表示。
文章定位：
