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 的始祖吧,很值得一讀~

2011年4月1日

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

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

坎尼在以前公司的做法有下列幾個:
  • 另外再寫一個 windows service 來執行
  • 用 Windows Form 寫成 AP,再用內建的工作排程來定期執行

    不多說,馬上進入正題

    I. 概念

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

    II.實作

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

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

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

    III. 小結

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

  • Google Spreadsheet 裡用規則運算式

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