隨機將雲端/分散式系統中的 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 的始祖吧，很值得一讀～

[ASP.NET] 在 Web 專案中進行排程工作

其實在很久之前坎尼就想研究這樣的東西了
概念大致上曉得，只是一直沒時間去實作出來
這幾天有些時間就去翻了一下資料，把它實作出來

坎尼在以前公司的做法有下列幾個：

另外再寫一個 windows service 來執行

用 Windows Form 寫成 AP，再用內建的工作排程來定期執行

不多說，馬上進入正題

---

I. 概念

排程這個東西，就是指定好時間，時間一到程式就會自動去執行
在 ASP.NET 裡，坎尼主要是利用 System.Thread.Timer 來進行排程設定
其他說明可詳見Bill叔所寫的 <三種時間人>
接著在 Timer callback 事件中撰寫要系統做的事 (抓正妹圖之類的…)

II.實作

首先，新增一個 Web 專案 (似乎是廢話)
在專案中新增一個 Global.asax 檔
 
接著宣告一個全域的 Timer
並在 Application_Start 中加入要進行 callback 的事件
最後再設定 Timer 的週期，本範例中是以 5 秒當作一個循環 (50000毫秒)
(第3個參數為 Timer 要在多少毫秒之後啟動事件
範例中所做的事就只是把時間寫進一個文字檔
(由於 sample 沒做好處理，很容易當掉 XD

進行測試，在 Visual Studio 中按 F5 (讓虛擬伺服器啟動)

注意，由於是另外開個 Thread
所以在伺服器關掉之前都會持續進行 callback事件
 
測試結果，果然有成功的在 background 進行寫時間 log 的動作

III. 小結

本次的範例下載
有興趣的人可以回去研究如何應用 :p