撰文⊙王宏仁 攝影⊙賴基能
人為疏失因自動化擴大連鎖效應
1個人為網路設定錯誤，導致Amazon美東地區好幾座資料中心的EBS服務大規模當機，美國數千個網站停擺，8小時以後陸續修復，少數網站甚至3天才恢復正常
Netflix安全上雲端的秘訣
全美網路流量排名第一的Netflix雖然所有服務仰賴Amazon的EC2，但幾乎不受這次大當機事件的影響，關鍵就是5項安全上雲端的秘訣
打造高擴充網站的設計關鍵
透過Stateless和全面API化的網站設計架構，影片租賃服務Netflix打造出高擴充性的網站架構，也因而順利度過這次Amazon大當機事件的考驗
人為疏失因自動化擴大連鎖效應
在美國太平洋時間4月21日凌晨12點47分，剛過午夜不久，負責Amazon美東地區其中一個服務區域（Availability Zone）的維護人員，不小心弄錯了一項網路設定。
這個看似微不足道的問題卻引發了Amazon的EC2（Elastic Compute Cloud ）雲端服務失效的連鎖效應，導致Amazon美東地區的4座資料中心的EC2服務嚴重大當機，Amazon陸續搶救，3天後才完全恢復正常。
例如美東有家心律調節器監控服務的廠商，有3部使用EC2服務的主機完全停擺，用來蒐集心電圖訊號的服務停止運作，導致監控人員無法即時追蹤數百位在家休
養的心臟病患者身上，醫護人員無法取得這些患者身上心律調節器的ECG
心電圖訊號而非常擔心。該公司急著在Amazon論壇求助，但沒有人可以協助解決。
 |
| ▲Amazon大當機造成許多網站數小時，甚至1、2天無法運作，例如有家心律調節器監控廠商連續2天無法追蹤病人心電圖狀態，急著在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也在官方部落格道歉，並且發文說明當機事件原因，以及後續的改善作法。 |
要了解這次大當機的原因，得先知道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虛擬機器或資料庫系統當機以後，租用了這間資料中心資源的用戶網站也跟著停擺。
打造高擴充網站的設計關鍵
美國影片租賃服務Netflix在這次Amazon大當機事件中，除了少數用戶抱怨影片傳輸速度變慢外，幾乎不受影響，等於順利度過這次Amazon當機
審判日的考驗。在Netflix負責IT架構、電子商務和系統工程的總監Adrian Cockcroft表示，Stateless
Services（無狀態服務）的網站架構是不受影響的關鍵之一。
所謂的Stateless Services設計，簡單來說，就是指使用者透過瀏覽器向網站伺服提出的每一次請求（request）都是獨立的，彼此沒有相關的。因此，這一次的瀏覽器請求和下一次的請求，可以分別交給不同的網站伺服器來執行。
這個設計的優點是，因為每一次瀏覽器請求都是獨立的，即使是同一位使用者提出的每一次請求，都可以分別由不同的網站伺服器單獨執行，所以可以將這些瀏覽請
求任意分散到不同的網站伺服器上，即使請求數量很大，也不會全數集中在特定伺服器上產生執行瓶頸。當使用者數量越來越多以後，造成瀏覽效果不彰時，只要增
加更多的網站伺服器，就可以來分擔所有的工作量，換句話說，採取Stateless設計架構的網站可以輕易地擴充使用規模。
靜態網頁就是一種Stateless的服務，使用者瀏覽不同的靜態網頁時，任何一臺網站伺服器都可以依據使用者送出的網址來提供網頁內容，不需要從另一個網頁取得資訊。使用者越多時，只要增加越多網站伺服器，就可以透過流量平衡設備將瀏覽器請求分散到其他伺服器。
而Netflix正是採取了Stateless的網站架構，所以就可以將瀏覽器所呼叫的API服務任意指派給任意一個Amazon虛擬機器（Instance）來執行，而不需要綁定在特定虛擬機器上。
因此，在這次當機事件中，Netflix可以向Amazon購買其他地區的虛擬機器接手服務美東地區使用者的瀏覽器請求。對使用者而言，只是因執行伺服器處在更遠的資料中心而增加網頁瀏覽時間，但影片播放的功能則一點都不受影響。
不過，《AWS雲端企業實戰聖經》作者林允溥表示，要開發出Stateless架構的服務並非是一件容易的事。對於有依存關係的操作程序、瀏覽過程或有交
易記錄的服務網站，例如購物車功能，若採取Stateless設計，使用者每次執行購物車中的交易動作，可能會由不同的網站伺服器執行，必須還有另外一臺
負責統整瀏覽過程交易資訊的機制，才能提供最後的金額累計和訂購產品清單。
或像是身分確認機制，使用者透過某一臺網站伺服器的應用程式登入系統，登入資訊若只存放在這臺伺服器上，當這名使用者下一次瀏覽器動作改由另一臺伺服器執行時，這臺伺服器若沒有這名使用者登入成功的資訊，就會重複要求對方登入系統，造成難以登入系統的困擾。
力可科技資深軟體架構師陳彥任表示，為了打造Stateless架構的網站，有幾種常見的網站建置架構，可以保存互動網頁需要的狀態資訊。
在用戶端保存狀態資訊
第一種是在用戶端保存狀態資訊，將各種狀態資料儲存在使用者端的電腦中，例如使用Cookie儲存，或是下載一支Flash程式，在應用程式執行過程中，
將狀態資料儲存在Flash程式內的本地端變數中。每次瀏覽網頁時，再透過網頁參數將這些狀態值傳遞給下一次負責執行的伺服器，來延續前一次的執行結果。
這樣一來，即使每次都是由不同網站伺服器來提供服務，也能確保使用者資料的延續。
不過，這種方法的缺點是安全性較低，因為將狀態資料儲存在使用者端，即使透過加密機制避免資料遭竄改或竊取，但也有被破解的風險，或是在應用程式回傳資料給伺服器的過程中被攔截，所以，通常只會在用戶端儲存較不具機敏性質的狀態資料。
以專用Session伺服器儲存狀態
對於有機敏特性或是重要性較高的狀態資料，則是可以透過伺服器端的作法來保存。這種做法就是建立專用的Session伺服器來保存狀態資料。使用者接觸的
前端應用伺服器上不保存狀態資料，而將網站應用程式執行過程需要的狀態資料，全部交由這臺Session伺服器來負責傳遞。這樣一來，只有這些少量的狀態
資訊會集中，前端網站伺服器仍舊可以不斷擴充，來提高能承載的使用者規模。採用Session專用伺服器的作法比使用者端的作法更能確保資料不被惡意竄改
或攔截。
不過，最終瓶頸仍舊會發生在Session伺服器，而且風險也會集中，一旦Session伺服器當機就會導致應用服務停擺，陳彥任表示，為了提高
Session伺服器的可用性，可採取伺服器叢集架構，例如一般可以使用3臺伺服器組成Session伺服器叢集，以避免其中1臺發生故障。
當專用Session伺服器叢集接近滿載時，還可以透過分割使量的方式來擴充規模。例如將使用者分成10組，每一組只有原本的十分之一規模，一組使用者就
由一套Session伺服器叢集來提供服務，未來增加了新的使用者，只要再多增加新的Session伺服器叢集就可以承載用量，來達到高擴充性的需求。
Stateless
Services的設計能解決狀態資料集中的瓶頸來提高擴充性，陳彥任表示，另一個提高網站擴充性的作法是網頁內容API化。例如Amazon的書籍介紹
網頁，對使用者而言看似只有一個網頁，但其實這個網頁組合了上百個API程式的執行結果，Amazon將網頁中的每一個功能或資訊，例如評星等、價格顯
示、下訂單、推薦書籍等，都開發成一項API，在分散給不同的網站伺服器執行，使用者透過一個整合式的混搭網頁來匯集其他API伺服器提供的內容。
陳彥任表示，這類API化的網站，在架構設計上，必須盡可能簡化每一個API的功能，才能減少彼此的影響，達到分散和擴充規模的效果，這也是一種提高前端
網站擴充性的方法。不過，每一個網頁都要等待其他伺服器執行完API後回傳資料，若內部網路頻寬不足，每個API的延遲時間會影響使用者看到網頁的流暢
性。
Netflix在1年前決定將服務全數轉移到Amazon上時，也重新打造了新的系統架構，將網站內容全面API化，再透過API提供影音串流服務或其他
功能給不同平臺或裝置上的使用者端程式，包括桌上型電腦、手機、平板電腦等，Adrian
Cockcroft表示，因為網站規模成長太快，建置資料中心的速度太慢，將系統架構API化以後，就可以快速調度Amazon虛擬機器來擴充規模，不用
自行準備硬體設備，甚至Netflix將常用的函式庫元件也API化，來提高內部應用程式執行共用元件時的彈性，可以由任一臺元件伺服器支援。
另外，Netflix也利用memcached記憶體式資料庫來儲存Session資料，作為API存取後端儲存系統或資料庫之間的中介。陳彥任表示，資
料庫是打造網站擴充性的第一個瓶頸，除了利用叢集式資料庫架構或NoSQL資料庫來分散存取量外，也透過像memcached這類記憶體式資料庫作為常用
資料的快取，也可以用來處理保存時限較短暫的Session資料。不過，若要讓多套memcached資料庫互相分享資料，則要自行建立同步機制，目前
memcached還未提供自動同步資料庫內容的功能。
透過Stateless
Services和API化的網站設計架構，Netflix只要將API服務複製到新的EC2虛擬機器上，就可以建立一個提供API服務的伺服器，能夠快
速擴充承載規模，遇到當機事件時，也能快速將服務轉移到其他地區資料中心的虛擬機氣上，避開有問題的服務區域，這正是Netflix順利度過這次
Amazon大當機的關鍵之一。
