剖析Amazon大當機關鍵：人為疏失因自動化擴大連鎖效應

在美國太平洋時間4月21日凌晨12點47分，剛過午夜不久，負責Amazon美東地區其中一個服務區域（Availability Zone）的維護人員，不小心弄錯了一項網路設定。

這個看似微不足道的問題卻引發了Amazon的EC2（Elastic Compute Cloud ）雲端服務失效的連鎖效應，導致Amazon美東地區的4座資料中心的EC2服務嚴重大當機，Amazon陸續搶救，3天後才完全恢復正常。

例如美東有家心律調節器監控服務的廠商，有3部使用EC2服務的主機完全停擺，用來蒐集心電圖訊號的服務停止運作，導致監控人員無法即時追蹤數百位在家休養的心臟病患者身上，醫護人員無法取得這些患者身上心律調節器的ECG 心電圖訊號而非常擔心。該公司急著在Amazon論壇求助，但沒有人可以協助解決。

因為心電圖訊號並非是攸關性命的醫療系統，原本這家監控服務商以為，Amazon EC2承諾的 99.95%可用性符合這樣居家照護系統的要求，沒想到卻發生大當機，一直到4月23日當天下午2點時，主機才恢復正常。在38個小時的服務空窗期內，系統停擺的廠商只能緊急調派人手通知家屬，並以人工確認的方式來掌握病患的狀態。

這次EC2大當機事件是Amazon自2008年S3服務8小時當機事件後，最嚴重的一次當機事件。上次S3當機事件對網站服務的影響，大多只是靜態網頁資料無法呈現，例如Twitter儲存的S3服務上的圖片無法顯示，但沒有嚴重影響到Twitter服務的運作。

但是，Amazon這次失效事件卻導致了上千個網站服務完全中斷，其中包括了知名新興網站如 Foursquare、Quroa、Reddit。甚至像Heroku網站代管平臺因為大量仰賴EC2服務，更是導致了60小時的營運中斷，代管的網站也連帶無法存取。

事後，Amazon的AWS服務團隊在官方部落格公開道歉，承認這次EC2當機事件是人為引發了自動化工具的盲點，在連鎖影響下，造成美東地區的EC2服務都受到影響。

要了解這次大當機的原因，得先知道Amazon EC2的服務架構。目前， EC2服務在全球5個地區提供服務，包括了美東、美西、歐洲、亞太東南和亞太東北等地區，每一個地區，Amazon稱為一個「Region」，而每個地區下則有多座資料中心，Amazon再用Availability Zone（服務區域，簡稱AZ）來稱呼，一個資料中心也就是一個AZ服務區域。

EBS網路升級是當機導火線

事故發生當晚，Amazon正在升級美東地區其中一座資料中心內EBS（Elastic Block Store）儲存服務的網路頻寬，這正是造成這次當機事件的起源。EBS是Amazon提供的儲存服務之一，可以掛載在EC2虛擬機器上使用，就像是實體伺服器使用的SAN儲存網路一樣，使用者可以指定多個EBS的Volume儲存空間作為EC2虛擬機器的磁碟機。

相較於EC2虛擬機器上的本地端儲存空間，EBS擁有較長的資料保存期限，也有高可用性的設計架構，每個Volume會自動建立一份完全一樣的備份Volume。

為了避免備份機制干擾EBS的存取，Amazon設計了2種不同的網路傳輸方式，一種是低延遲高頻寬的主要網路傳輸服務（Primary Network），用來提供給EC2主機與EBS間的資料I/O之用，而另一種網路則是頻寬較低的傳輸服務，主要作為EBS非同步建立Volume備份時的資料傳輸。

4月21日當晚，Amazon正計畫對美東地區其中一個服務區域的EBS主要網路進行線路升級工作。一般企業升級伺服器的網路線路時，為了避免伺服器的服務中斷，通常會建立另外一套有足夠流量承載力的臨時性備援線路，將舊線路的流量導入備援線路以後，再來更換網路設備。

但Amazon維護人員輸入了錯誤的網路設定，誤將主要網路上的網路流量導向頻寬較低的非同步備份用線路，而沒有導入到備援線路，造成大量EBS的資料I/O流量塞爆了這個服務區域的EBS低頻寬傳輸網路。

頻寬不足的問題原本只會影響資料存取效能，頂多是讓網站服務變慢，但不致於完全中斷甚至當機，但是，EBS的自動備份特性卻讓網路頻寬的消耗更加雪上加霜，也衍生出更嚴重的災情。

當機關鍵是過度自動化

EBS為了提供長期儲存機制，採取了多項高可用性的架構設計。例如每個服務區域中會有很多套EBS叢集系統，每1套EBS叢集由多臺伺服器組成，稱為1個EBS節點。雖然每1個地區（Region）內有多個資料中心，但在Amazon的設計上，1個地區屬於同1個網段，同一地區下每個服務區域共用同一套命名空間，也只使用1套EBS控制服務（ Control Plane Services），用來協調這個地區下，不同服務區域中每個EBS叢集所提出的需求。

每次EC2使用者建立一個新的EBS Volume時，EBS控制服務會自動在同一個服務區域內的不同EBS節點上建立這個Volume的複製版本（Mirror Volume），作為備援之用，一旦原本的EBS Volume失效，EBS控制程式就會自動切換到另一個節點上的複製Volume接手提供儲存服務。

Amazon設計了一個自動偵測機制，來確保EBS Volume的HA架構。原始的EBS Volume會不斷向複製Volume發送偵測訊號，類似Ping功能，若複製Volume沒有在一段時間內回應，自動偵測機制就會判斷複製Volume失效，並且向EBS控制服務提出建立一個全新複製Volume的請求。EBS控制服務就會找出另一個可用的EBS節點，在數毫秒內重新建立鏡像複製版（re-mirroring），正是自動偵測機制加上re-mirroring功能導致了連鎖錯誤的發生。

大當機當晚，因為設定錯誤讓服務區域的低速網路大塞車，自動偵測程式無法透過低速網路接收到複製Volume的回覆訊息，以為是複製版本失效了，就開始向EBS控制服務大量提出re-mirroring的請求。

因為整個服務區域的網路都受到影響，所以該服務區域內的每一個EBS節點都向EBS控制服務提出請求，產生了大量建立備份Volume的請求等待執行，一旦網路塞車稍微紓解，EBS控制服務就會立刻執行建立Volume的動作，但複製Volume的資料傳輸又會用掉更多網路頻寬，讓整個資料中心的低速網路更塞車，原始Volume還是無法確認複製Volume的存在，繼續請求建立更多備份。

如此惡性循環，最終，Amazon北維吉尼亞資料中心內所有EBS節點都無法運作，因為這些EBS節點的運算資源和網路頻寬都被建立複本Volume的請求所占用，無法正常存取服務。

有一種EC2虛擬機器使用EBS來儲存開機時的分割區（Root Partition），EBS失效也連帶導致這些EC2無法讀取開機資料因而失效，Amazon提供的MySQL RDS資料庫服務也是安裝在EBS上，同樣中斷服務。

這個Amazon北維吉尼亞資料中心的EC2虛擬機器或資料庫系統當機以後，租用了這間資料中心資源的用戶網站也跟著停擺。

連鎖當機耗用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雲端企業實戰聖經》作者林允溥認為，這次大當機事件是一種自動化的漣漪效應，這些自動化程式沒有設定終止條件來限制執行次數，或是逐漸拉長執行自動化程式的時間間隔，一旦發生人為疏失，觸發了這個程式設計漏洞，惡性循環不斷耗用資源直到服務停擺。

林允溥表示，這類自動化程式的演算法應該設計很短暫的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也在官方部落格道歉，並且發文說明當機事件原因，以及後續的改善作法。

《AWS雲端企業實戰聖經》作者林允溥認為：「很多網站只是將機房搬上雲端，卻沿用傳統資料中心的運作概念，沒有善用雲端的彈性擴充能力來建立備援。」

Amazon連鎖大當機歷程

階段1

美東地區升級單一服務區域的主要網路，維護人員網路設定錯誤將EBS主要網路的資料流量導向低頻寬的非同步備份網路，因而造成EBS網路大塞車。

階段2

該服務區域內所有EBS的Volume 自動備份機制因網路塞車，無法確認備份用的volume 副本是否存在，因此，大量向美東地區的EBS控制服務送出重建Volume 副本的re-mirroring請求。

階段3

大量re-mirroring請求塞爆了美東地區EBS控制服務的運算負載，連帶造成EBS控制服務無法協調美東地區其他3座資料中心內的EBS運作，造成美東地區所有服務區域的EBS當機，仰賴EBS的RDS服務也因此而停擺。

階段4

8小時以後，Amazon更正網路設定，並且關閉這個EBS控制服務的部分API，也透過網路分割的方式，隔離發生問題的服務區域，另外還增加新的EBS控制服務讓其他3座資料中心的EBS服務恢復正常，但發生問題的Amazon北維吉尼亞資料中心所提供的EBS服務仍舊還未恢復。

階段5

Amazon開始擴充Amazon北維吉尼亞資料中心的實體儲存設備，讓發生問題的EBS控制器有足夠的資源可以完成大量的EBS副本建置請求。

階段6

3天後，Amazon擴充了足夠的實體設備，讓發生問題的服務區域完成所有等待執行的EBS副本建置請求以後，EC2服務和RDS服務才恢復正常。

快速認識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月

相關報導請參考「Amazon雲端服務大當機的啟示」