劈腿無罪! ?談設計高可靠度的系統架構需要注意什麼

前陣子美國的颶風造成AWS大跳電 [1][2]，網路上怨聲載道[3]，甚至一堆人又開始質疑Amazon與雲端運算可靠性[4]，以及趁機推銷他們的Private Cloud[5]，這些質疑都是合理的，也值得我們省思，但是我們不能因咽廢食就此遠離AWS甚至是Public Cloud，真正重要的是我們是否有任何災難復原計畫？是否有可以藉由架構的設計來減低災害造成的損失？所以我們今天要來談如何(劈腿與腳踏多條船) 設計與建置 High Availability and Reliability 的系統架構。

我真的好愛這隻劈腿狗(誤)，我們都知道在感情上劈腿和腳踏多條船是不被允許的，但是在系統建置上，卻是只要能力許可，財力足夠，你越有錢你愈要腳踏多條船 (這正是Hybrid Cloud的精義!) ，因為你才可以把你的風險分散，而且還有很多等級的分散：

• 分散在 Amazon 同一個Region 不同的AZ (Availability Zone )
• 分散在 Amazon 不同的Region
• 分散在 Amazon 與 其他不同的IaaS provider
• 分散在Public Cloud 與 Private Cloud

越下面的成本越高，設計起來難度也越高，不過才可以有效的降低與分散風險，這也很像理財所說的雞蛋不要放在同一個籃子裡面。

光是分散還不夠，重點是軟體架構

讓我們來參考一下AWS官網提供的Reference Architecture，裡面就介紹一個HA的系統架構應該長成什麼樣子，圖中的範例是把同樣的系統部屬到同一個Region的兩個AZ，所以設計的重點有：

• 如何使用Load Balance 有效把流量導到不同AZ 
• 如何把Service 設計成 Stateless 的，並且讓所有資料與狀態透過DB 來Sync
• 如何讓 DB 可以有效的 Replicate and Sync

同樣的，前幾天去參加AWS201的研討會，大家都對Auto Scale 很有興趣，但是Auto Scale真的難的不是在如何讓Amazon偵測流量和Loading去自動開啟關閉Instance，真的有學問的地方是在如何設計系統架構，讓Auto Scale每開啟一台新的Instance，Instance 內的 Service 可以自動啟動，加入這個Auto Scale Group，並且有效的Share loading。如果Auto Scale 自動shrink Instance size時，可以讓Instance 關閉卻不影響現有的Service 和使用者，資料也不會出現異常。

而且說實在這些都還沒考慮系統安全性和系統效能問題呢...囧rz..

有興趣的人快回去翻分散式系統架構的書吧，另外可以參考這本書：Addison Wesley - Patterns of Enterprise Application Architecture



Reference
[1] Multiple Generator Failures Caused Amazon Outage
[2] After The Storm: Architecting AWS for Reliability
[3] Amazon Takes Blame for Outages, Bugs and Bottlenecks
[4] Amazon outage one year later: Are we safer?
[5] AWS Outage Proves It’s Better to Own Than Rent