[Cloud Computing]Amazon事件後續
在設計時會使用Chaos Monkey來做錯誤模擬，這個概念也蠻有趣的，一般來說我們在做系統時的測試案例大多會包含正常狀態與異常狀態，很多時候測試異常狀態大多只是針對『這個異常狀態所呈現的結果』，如果相符，那這個測試案例就pass了，但在雲端的世界，測試案例除了要涵蓋每個comnponent失敗時的狀態外，也該針對此有更多的設計，例如自動回復機制、人工回復機制等，如何讓使用者的downtime縮短、甚至不發生，將是每個雲端服務供應商最大的挑戰
上禮拜發生的Amazon雲端服務當機事件：[Cloud Computing]亞馬遜雲端服務當機事件
本次的事件Amazon已有公開說明：Amazon: Bad Execution During Planned Upgrade Caused Outage，主要原因是出在EBS(Elastic Block Store)上頭，其中一個受害的苦主Netflix的開發團隊在部落格上發表了一篇lesson learn：Lessons Netflix Learned from the AWS Outage，裡頭記載了本次事件他們的處理方法，以及後續該如何因應這一類的問題，裡頭有許多值得參考的內容，以下我自己摘要一下。
在設計架構上，Netflix提到：
(1)使用Stateless services
他們在系統架構設計時期已經儘量設計成Stateles，不用記住狀態，就不用擔心client跟server間的關聯，例如用了session，你就要思考當存放user session那台主機掛點時，session如何保留與移轉的問題，如果沒有狀態，那就比較不用擔心這樣的問題。
(2)跨區域儲存資料
除了同時將資料存放數份外，也思考如何讓這些資料的儲存是跨區域的，以避免類似這次的事件，服務中斷是比較好解決的，但如果資料損毀就很麻煩了，只能想辦法還原回上一個備份時期的資料，當資料放在客戶端時，資料的備份問題是客戶自己的問題，但是當資料放在雲端，資料的備份就是雲端服務供應商的問題了，如何確保服務與資料的安全與穩定將是雲端服務業者的挑戰。
(3)無痛的移除功能，確保主要功能正常
這邊提到Netflix的系統對於錯誤已經有很好的防範機制，例如他們在設計時會考量以下概念：
Fail Fast：當服務出現錯誤時，立即中止該元件，以避免該元件的錯誤導致整個系統異常。
Fallbacks：候補的意思，當某個功能不能運作時，就用另一個功能替補上，例如當使用者的個人化設定功能不能work時，就先用之前暫存的設定，功能不能用總比系統出現錯誤來的好。
Feature Removal：當某功能發生異常時，就直接從系統終將該功能移除掉，例如在首頁撥放的影片，若無法順利載入，導致整個網站都在waiting，那就將該功能移除掉，以避免卡主整的系統的運作。
(4)N+1的備援機制
如果平常使用N台機器就可以服務客戶，但永遠都要啟動N+1台機器來確保服務的穩定，我想這個+1只是示意，最保險的還是多幾台作為預備，以避免一次有多台機器出錯時措手不及，但這種備援方式影響到的就是成本了，但買保險總是要擔負較高的成本的。
另外他也提到如果他們在設計時會使用Chaos Monkey來做錯誤模擬，這個概念也蠻有趣的，一般來說我們在做系統時的測試案例大多會包含正常狀態與異常狀態，很多時候測試異常狀態大多只是針對『這個異常狀態所呈現的結果』，如果相符，那這個測試案例就pass了，但在雲端的世界，測試案例除了要涵蓋每個comnponent失敗時的狀態外，也該針對此有更多的設計，例如自動回復機制、人工回復機制等，如何讓使用者的downtime縮短、甚至不發生，將是每個雲端服務供應商最大的挑戰。
Netflix分享的這篇文章真的很棒，點出了好多問題，其他跟Amazon的服務相關的內容就請各位看倌自行觀看囉。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
