Ruddy Lee 分享空間

Emergent Design 演化設計

雲端的架構設計

leave a comment »

雲端的架構設計與傳統在既有系統的設計是有些個不同之處,例如: 對負荷的處理,傳統的作法是尋找工作負荷最高點然後把伺服器的能力向上拉高到超過這個負荷點,這樣就不會超載了。但在雲端則因為平台已經提供 scaling的能力了,因此做法就不同了,它是這樣作的: 我們要試著去定義所謂的 最小”負荷單元”,並以此作為scaling 的基本單元,然後我們便能夠藉著調整基本單元的多寡來應付多變的負荷。這一點等一下再說明。

雲端的設計思維 Design for Cloud

架構設計的目的在解決客戶的需求,所以通常都是針對某一些個特定問題來做設計的(沒有所謂銀子彈的,也就是那種可以放諸四海都對的設計!)。在這裡我想試著談一些一般性的設計原則,這些原則談起來總是比較無聊,變通的部分;就靠讀者自己加入符合客戶需求的一些變化囉!

  • 故障防護 Failsafe
  • 規模調適 Scale
  • 整合 Integration

故障防護 Failsafe

談雲端的架構設計應該先從Failsafe 開始吧。話說,如果失敗時能夠不受傷害,縱然失敗了也沒有受損失那該有多好!不過;對系統設計而言往往能把損失降到最小就是良好的設計了(大部分的不良防護或是根本沒有做防護都是成本考量所造成的,當然不管客戶在不在意,程式設計師在設計上還是該做它應該做好的設計工作)。

@ Availability

環境的配置決定了 HA值的高低,但也反應在成本上頭。你可以考慮用最基本的串聯或是並聯的方式。並聯的方式就是Redundancy,也就是將至少二個以上一樣的系統並存的掛在一起,萬一一個故障了,另外一個可以立刻取代,只要銜接的好(MTTR越短越好, Mean Time To Repair,平均修復時間)系統的可用度自然可以維持在一定範圍。這一點我們可以向雲端學習(它對 MTTR也有特別的作法,有機會再說),它預設是同時啟動或讀寫三份,如下圖:

HA

圖 、 High Availability 的設計

上圖左側是並聯的方式,也就是 Redundancy. 這時候我們向Windows azure 借鏡,同時用三個90%的系統構成99.9%的高使用率。但明顯的成本會高上許多。右側則是採用串聯的方式將三個高效的系統串聯在一起,則得到的群體服務效能則反而下降了(如果你的程式必須與其他系統共事,則互相牽連則是難以避免的)。

Availability 90% 跟99%差異在哪裡呢?

一個簡單的判斷方法,那就是看客戶的雲端服務是否能接受一天停機 144分鐘跟14.4分鐘服務被暫停的差別。而99.9% 的HA值呢! 那就是說一天最多只會有1.44分鐘的時間服務可能中斷。Redundancy 的成本是高昂的,但換取來的卻是寥寥無幾的幾個百分點。因此在架構設計時若能善用雲端平台的故障防護能力,是最好不過的了。以下是 Windows Azure 的一些基本 Redundancy功能:

  • Windows Azure 的 Storage 針對相同資料有三份的複寫。
  • SQL Azure 原來就自動內建備份伺服器。
  • Windows Azure 可採用勾選的方式啟動內建 caching 的HA 功能。
  • Windows Azure Web Sites and Cloud Services都已經俱有Multi-instance。
  • 比較少人會注意到其實Windows Azure 是具有VM負載自動平衡的功能(Load-balanced Virtual Machines)。
  • 把資料跨Data Center存放,把資料備份在不同區域的雲端資料中心裡( using Windows Azure Traffic Manager)。

@ Scale 規模規劃

雲端的scaling與傳統非雲端的scaling是有所不同的。傳統的作法是尋找工作負荷最高點然後把伺服器的能力上限拉高過這個負荷,這樣就不怕超載了(通常就是加大容量,或買個更強大的伺服器)。但在雲端的做法則不同,我們要依靠試著去定義所謂的最小 ”負荷單元”。以單元(unit)的方式來考量彈性的增加或減少來應付負載的變動,是需求考量要增加或減少多少個負荷單元數,並企圖做到讓它自動化(這是相當不容易的,因為負荷往往會不按牌理的變動,它是不會配合我們的計畫的。正所謂計畫趕不上變動。請記得;比較有效的解法是: 加大你的負荷單元的大小)。

traditional scaling

傳統的Scaling,就是考慮花錢加大容量,讓它超過最大負載量就OK了! 但也就容易出現浪費容量的現象(當容量若來不及增加時,就容易出現負荷超載而讓客戶產生不滿的現象)。

capacity

圖、雲端以最小負荷單元來處理工作負荷的變動

黃線是實際的工作負荷,黑色格線則是以負荷單元做彈性調整的結果,這一條黑色格線我們往前面提前了一些讓它超過了縱軸線,目的是在說明只有試著計劃做提前預測的方式,才有機會避開非常態性的負荷。 至於中間那一條綠色的線,則是假設我們把基本的負荷單元加大(這是正解),它能輕易的包含所有負荷(乍看起來成本當然是增加了,但平均成本則反而下降了)。

good scaling

圖、用 Scale Up 處理高 hit rate.

針對客戶的工作特性,雲端程式的設計必須在開工之前就先做好預測的計畫,然後才能在程式上線前進行負載模擬,才來得及做好調整的動作。如上圖,顯示的是網站每分鐘被點閱的次數,與伺服器提升工作 Instance數目,這是一個實際IIS在雲端動態scale up instance 數的好範例,但第一個尖峰它失敗了,因此所產生的Lag 現象則是屬於設計上預期的現象(當然是為了省成本,刻意放棄的)。

以下是一些個建議:

  • 做好容量規劃 Capacity plan
  • 適度分解 Proper decomposition of system
  • 無狀態設計 Stateless design
  • 所有層均可規模化 Scale at all layers
  • 節流 Throttling

@ Integration 整合

再補 …

Written by ruddyllee

2013 年 08 月 01 日 於 16:04:23

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: