網頁

2012年7月6日 星期五

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


前陣子美國的颶風造成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

沒有留言:

張貼留言