日前，又一 AWS 服務的失效沖擊了幾大網站及其服務。如何才能避免癱瘓？僅為伸縮進行架構還不夠，還需為災備進行架構。
根據 AWS 服務健康儀表板，Amazon 東區（北弗吉尼亞區）AZ 的一組云服務——EC2、EMR、RDS 和彈性 Beanstalk 失效，時間大約從六月 29 日下午7：25起，至六月 30 日下午 3 時止。該失效影響了許多公司及其服務和網站，其中有 Netflix、Instagram、Pinterest 和 Herokua。據 Amazon 報道，罪魁禍首是“由橫掃北弗吉尼亞地區的大面積電暴引起的”電力事件，上周五晚間一場暴風雨襲擊了美國東部地區，導致13人喪生，三百萬人口被停電。
除了電力設施的波動之外，一次巨大的電壓脈沖襲擊了兩大計算中心，迫使它們切換到發電機供電模式，但是其中一個數據中心的發電機未成功運行，導致了相應數據中心在耗盡 UPS 之后停電。電力很快就得到恢復，但是將服務恢復至所有功能完好卻需要長得多的時間。Inmar 的架構副總裁 Mike Kavis解釋了 需要這么長時間的原因：“事實上，雖然 Amazon 的備份電源切換進來，但是并非所有的計算資源得到成功災備。其結果是有一組虛擬服務被踢下線，直到 AWS 恢復它們為止。用戶（譯注：AWS 的用戶）對于這一情況的應對措施決定了其應用是癱瘓還是保持彈性。許多網站癱瘓了。”
考慮到這類事件對于理解如何避免癱瘓的重要性。這次 AWS 的電力事故之后，Kavis 在其博文中說，他的公司自 2009 年起經歷過 5 次 AWS 失效，但是他們的服務從未宕機過。原因是他們使用了多個 Zone 和 Region。
Amazon 的每個 Region 的 SLA 可達到 99.95%。在同一區域里從未發生過多個 Zone 同時失敗，也從未出現過多個 Region 同時失敗的情況。本質上，他們提供了計算資源的 100% 正常運行時間（uptime）。只不過這取決于我們如何架構系統以利用 Zone 和 Region 的優勢……
我們假設平臺中的每個服務器和服務都可能在某個時間點失敗，所以設計出多條通路，使之能在多個 Zone 的冗余計算資源上繼續處理交易。換言之，我們假定區域內的 Zone 可能會失效，所以將平臺設計得不依賴于單個 Zone。
但是，多個 Zone 也不夠，Kavis 說：
在這些失效中，我注意到一個模式，即 AWS 的 RDS 服務（將數據庫管理過程自動化的服務）似乎在每次 Amzon 出現問題時都會失效……
事實上，我們手動管理我們的 MySQL 數據庫才是我們在這些失效中保持彈性的主要原因之一。如果我們依賴于 RDS，我們也不會那么幸運。這是否意味著 AWS 客戶不該使用 RDS 呢？不，我們仍然用它實現一些無需極端 SLA 的功能并提供與各銷售點系統的實時連接。
Kavis 提到，上次 AWS 失效所襲擊的一些公司有著“目前看到的最吸引人、最先進的高可用環境的架構”。但是，他們為了伸縮性犧牲了正常運行時間（uptime）：
無 SLA 要求的免費社交媒體網站就可能會把更多的時間花在支持上百萬并發用戶的伸縮性上，同時會面臨一至兩個小時宕機的風險。對于他們而言，把精力花在處理突發訪 問量比關注不太容易發生的 AWS 失效更有價值。畢竟沒有人會因為無法向 Facebook 傳照片而死掉。
其結論是：若要實現永遠可用，就要為災備進行架構，而不僅僅為伸縮性架構。正如 Kavis 所言，“我們需要理解的是，弗吉尼亞地區的許多公司自建的數據中心也癱瘓了，而且仍然處于癱瘓中。發生了電力故障。云端和本地的數據中心都癱瘓了。最終一 切都癱瘓了。正常運行時間（uptime）的秘密在于你如何在設計時考慮這些失效。”
京公網安備 11010502049343號