2011年4月26日

隨機將雲端/分散式系統中的 processes/services 刪除,以測試系統的容錯能力 - Netflix & Chaos Monkey

上禮拜四 (4/21) 在 InfoQ 看到一個大新聞:Major Outage on Amazons EC2 US-East Datacenter - Many Sites Affected,災情相當慘重,不少最近以 Amazon 的 IaaS solution 為基礎的新興熱門網站都掛了 (e.g., Foursquare, Quora, Heroku),最後拖了整整3天才完全修復。

接下來的幾天 Amazon 當然是全力搶修,在週末將服務修復後,網路上陸續出現很多評論 & 分析的文章。昨天早上看到 Phil Wainewright 寫的 Seven lessons to learn from Amazon's outage,其中讓我最 shock 的就是第六點「Understanding the trade-offs help you frame what to ask」中所說,Netflix 內部寫了一個叫做 Chaos Monkey 的 daemon,它的作用就是隨機的將 Netflix 系統中的各個 processes/service 刪除,看看系統的存活能力是否有達到當初的設計!因此在這次的大災難中 Netflix 的系統仍可正常運作,在眾多倒地不起的網站中顯得一枝獨秀!
(原文請參考 ReadWriteWeb: Chaos Monkey: How Netflix Uses Random Failure to Ensure Success)

Chaos Monkey 的運作方式對於資深的前輩們可能不是什麼新的觀念 (e.g., Monkey Lives),但是對我來說真的是蠻大的衝擊。在傳統的維運架構中,為了要測試系統的容錯能力,不管是 active/backup 的 Web/DB/AP Server、 NIC binding 要測試 failover/failback,redundant power supply,都必須事先擬定演練計畫,詳列所有操作步驟的 SOP (如何製造 failover 的狀態,如何確認是否 failback,若操作失敗要如何 rollback 等等),所有相關人員從業務單位的 PM、開發單位到維護單位都如臨大敵,演練當天(有時候還必須要挑凌晨的時段)戰戰兢兢的按表操課。也因此這類的測試頂多一季到半年做一次,而且這還是所有元件都 tightly-coupled、所有環境都在完全掌握中的系統,還不是環境無法 100% 完全掌握的分散式系統呢!

相較之下,Chaos Monkey 的作法則是在 Production 系統中常駐一個 daemon (相當於 Windows 中的 Service),不定時的將系統中的重要 process/services 刪除!例如有個神經病忽然發作登入系統把 Oracle 的 process 通通 kill 掉!

這時候系統應該如何反應?能否在短時間內偵測到 Oracle fail,趕快在其他地方 (e.g., 另一個 Region / Availability Zone 中) 另起爐灶 (e.g., 啟動 backup Oracle server)? 在備援機制接手之前,或者此問題無法在短時間內解決時,如何做到 graceful degradation (例如 Netflix 的 recommendation 系統掛了,無法顯示推薦影片,就改為顯示目前最熱門的影片)?這些就是當初建置 Chaos Monkey 這套機制希望可以自動測試的,看看系統反應是否如設計的一樣達到很高的容錯能力。

分散式系統在設計的時候當然會考量到上述的各種情況,系統中的元件會做好適當的切割,設法避免一個元件 fail 以後拖垮整個服務。在高水準的團隊中會採用 Test-Driven Development (TDD) 的方式來開發,透過 Continuous Integration (CI) 來每天驗證系統是否符合設計。但是自動測試有其極限,許多時候更需要透過 mock object 或者 stub 來模擬其他元件的反應,並無法 100% 保證系統實際執行時會符合預期,而 Chaos Monkey 則是直接把 Production 系統中正在運作的元件給砍掉,如此才能在真實環境中真正去驗證系統的容錯能力,並且發掘設計時沒想到的問題。

要讓 Chaos Monkey 這套機制順利運作,除了技術上的挑戰之外,也要整個組織文化的配合,如果這隻猴子剛好挑在半夜的時候發瘋,真的把系統搞掛了,相關的人就沒辦法安穩的睡個好覺了,而且對於營收以及公司商譽的衝擊也是很大的風險,因此若是想要在已經成熟的系統或者傳統的大公司導入這套機制,想必會遇到重重阻礙。Starup 就比較沒有這種包袱,若能在一開始建立系統的時候就建置並執行如 Chaos Monkey 的機制,未來這個系統的體質一定會非常的強健。

最後就 quote Netflix Tech Blog 中的一句話作結吧:

The best way to avoid failure is to fail constantly.

後記:昨天下午又在 Jeff Atwood 的 Coding Horror 看到一篇:Working with the Chaos Monkey (裡面有隻看起來很機車的猴子插圖),Jeff 提到他在一年多前就在 Netflix 的 Tech Blog 看到關於 Chaos Monkey 的說明 (5 Lessons We've Learned Using AWS),但後來太忙了就忘記寫心得 XD  在這篇文章的回應中,有人又提到 Monkey Lives 的故事,應該可以說是 automatic monkey teesting 的始祖吧,很值得一讀~

3 則留言:

Unknown 提到...

模範生 Netflix 在官方的 Tech Blog 裡面又發表了一篇新文章:Lessons Netflix Learned from the AWS Outage (http://techblog.netflix.com/2011/04/lessons-netflix-learned-from-aws-outage.html),大推阿!Netflix 準備要把 Chaos Monkey 升級為 Chaos Gorila 了 XD 感覺官方對於技術分享非常有誠意,文章品質也很高,建議對 cloud computing / AWS 有興趣的人訂閱這個 blog。

Unknown 提到...

InfoQ: Amazon EC2 Outage Explained and Lessons Learned (http://www.infoq.com/news/2011/04/Amazon-EC2-Outage-Explained),AWS 官方報告: Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region (http://aws.amazon.com/message/65648/),看來是因為調整網路設定的錯誤導致的

Unknown 提到...

最新結果是已經漸漸形成一支猴子大軍了:The Netflix Simian Army (http://techblog.netflix.com/2011/07/netflix-simian-army.html)

Google Spreadsheet 裡用規則運算式

最近因為工作關係,遇到要用 Google Form 及 Google Sheet 所以研究了 Google Sheet 裡的一些 function 怎麼用 首先,分享一下如何在 Google Sheet 裡用規則運算 :D