Amazon雲端服務大當機的啟示

只因為一個網路設定錯誤所造成的骨牌效應，竟導致雲端服務典範廠商Amazon的EBS服務大當機，連帶使得美國數千個網站停擺，雲端運算還值得信賴嗎？從這個事件可以學到什麼教訓呢？

撰文☉王宏仁

人為疏失因自動化擴大連鎖效應

1個人為網路設定錯誤，導致Amazon美東地區好幾座資料中心的EBS服務大規模當機，美國數千個網站停擺，8小時以後陸續修復，少數網站甚至3天才恢復正常

在美國太平洋時間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、Quora、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虛擬機器或資料庫系統當機以後，租用了這間資料中心資源的用戶網站也跟著停擺。