雲端服務可靠度的新觀點

發生在4月21日的Amazon雲端服務大當機事件，讓許多採用AWS（Amazon Web Services）服務的網站被迫關門超過30個小時，其中不乏一些知名的社交類型網站──Foursquare、Quora、Reddit，被迫停止服務，甚至還有一家提供心律調整器監控服務的廠商，也因為使用Amazon EC2虛擬主機來記錄居家照護的心臟病患的心電圖，面臨無法監控患者生理狀況，而急得像是熱鍋上的螞蟻，這可是人命關天，不能鬧著玩的事。

Amazon的AWS雲端服務，提供IaaS（Infrastructure as a Service）類型的雲端基礎設施服務，像是虛擬機器、資料庫、線上儲存空間等等。這個服務從2004年問市至今，可說是全世界最大、在安全考量上頗為周到的IaaS服務，它提出了99.95％的服務保證，多年營運下來也備受肯定，因而美國有許多新興網站都不再自己建機房，直接就採用AWS的基礎設施服務，就連做法較保守的企業也紛紛採用。然而，這個大家所信賴的雲端服務，卻發生了一連當機3天的重大事件，難道雲端服務真的不可信了嗎？

事後Amazon對外道歉說明，問題發生自一個人為設定網路的錯誤，但卻因為系統為了提高可靠度的一個自動化機制，而形成了連鎖效應。當時他們正準備要為一座資料中心裏的磁區儲存服務Elastic Block Store（EBS）擴充網路頻寬，然而操作人員在切換網路時發生錯誤，把服務導入了一個低頻寬的網段，因而導致整個網路連線變慢。

網路連線變慢頂多只是增加了延遲時間，然而Amazon EBS在設計上已考量到系統的高可靠度，當使用者新建一個EBS磁區時，系統會自動複製一個備份版本，以防系統故障時，可做為立即復原使用。而為了確保備份版本的可用度，系統會定期檢查備份版本是否存在，如果備份版本沒有回應檢查訊號，系統會自動判定備份版本可能失效了，接著就會立即製作另一個備份版本，以確保整個系統的高可用度。

這樣的設計已經考量了共用硬體架構下的高可用性，然而，當操作人員誤把EBS服務導入慢速網段後，造成網路延遲時間變大，許多EBS磁區因而無法在預設的時間內偵測到備份版本的存在，因此就自動判斷為備份版本失效，開始製作新的複製版本。如此形成了雪球效應，一個人為上的設定錯誤，加上自動化機制快速的反應，迅速形成了管理人員無法立即抒解的問題，最後雪球越滾越大，4座資料中心被迫停止運作。

細究事情經過，Amazon確實為了雲端服務的高可靠度而做了努力，多數企業自己可能都做不到如此的自動化機制。然而，這個事件也突顯了，面對雲端服務這樣一個新興的技術，還有許多我們沒想到的事。

這個事件讓企業未來面對雲端服務得更加謹慎，如果是採用公有雲服務，就必須更進一步了解服務商的營運架構、服務保證的內容，若抱持著只要刷了信用卡就行了，反正廠商會處理所有繁瑣的技術細節，這樣的心態就有點草率了。

然而，雲端服務就不可信了嗎？倒也未必，美國最大的影音網站Netflix，就大量採用AWS的服務，他們卻能躲過這一劫，關鍵就在於他們一開始就對雲端服務做了最壞的打算，連自身的網站架構都配合調整為高可用度的設計，經過這個事件，他們在採用雲端服務的策略不但不退縮，反藉由這個事件找到接下來作業流程可以改善的部分，讓他們更放心地大量使用雲端服務，亦保持更高的安全性。該如何做？請見本期封面故事的報導。