Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 八月 2013

雲端的架構設計: Integration 整合篇

leave a comment »

鬆耦合 loosely coupled

鬆耦合 loosely coupled 大概是我們談雲端整合時最常被提起的準則。在設計架構時為了達到 loosely 的效果,採用message queue 或service bus的框架來分離前端界面和後端邏輯之間的緊密關係,將它們融入架構中,這是達到鬆耦合最快速的方法了。

(討論架構時容易產生的怪異現象: 這一點相當的有趣,只要一談到架構則人們不論是程式師或是專案負責人甚至業務人員都會顯得特別感興趣,紛紛圍觀過來,然後接踵而來的就是一大堆的意見,然後很快的大家的聲調便會越提越高,爭論不休熱鬧異常!讓原本很正常的設計瞬間遭受大量的質疑,並成了有相當偏好的設計。這是目前大家對架構普遍喜好的現象,真可怕!其實嘛,UX設計師所面臨的評論場面,恐比架構師要悲壯的多了,在此,獻上敬意)

為此,我經常帶上一些色彩與虛幻來講架構的設計,藉著幽默來調和一下,這裡先跟大家分享(要聲明一下,這跟宗教信仰可是完全無關,請別想太多)。

問:"禱告有用嗎?"

答:當然有用!

問:那為什麼我的禱告都沒有實現呢!

禱告當然有用,這些訊息它們都會迅速的進到上帝的Message Queue中若沒有任何exception產生它們是不會遺失的,至於上帝的Queue的大小則是絕對經得起挑戰的,所以你放心,只要你禱告了,它就一定會進入Queue裏頭,不會漏掉的,但會不會實現就要看內容了,這一點基本上跟架構就無關。

然而;許多寫Queue的人都不了解,Queue它們是有輕重緩急的區分的,這一點我們在一開始就要設計進去。舉例來說;像孩子們在聖誕節前夕的禱告,上帝就會想盡辦法,加班熬夜也會盡力的把訊息從Queue拿出來,設法去達成的(要知道將訊息填入Queue容易,但消化Queue時就必須一個一個拿出來,這是需要相當時間的)。此時要是遇到緊急的情況時,像那種必須立刻被處理的事情你就不能像聖誕節的禱告一樣把它放進queue裡頭來處理,必須走特殊的管道。故事如下:

Constantine

康斯坦丁(John Constantine),沒錯就是那位驅魔神探。

話說;他好不容易抓到大天使加百列與閻羅王之子瞞著他老爸密謀透過”命運之戟”偷渡到人間的關鍵時刻…。

話說,憑藉康斯坦丁一個凡人的力量當然不足以對抗閻羅王之子或是加百列,所以即便看到事情即將發生,也是束手無策,此時;他只好向上帝禱告了,希望能及時阻止這場災難。但這種正常的禱告訊息,我們知道的,他必須先放進Queue裏頭排隊的,等到輪到他被處理的時候上帝才會看到訊息然後加以處理。這就是Queue的運作方式。康斯坦丁當然是等不及了,情急之下,他便想到閻羅王曾經說過,如果他要死的時候,閻羅王會親自前來提領康斯坦丁下地獄的。因此,急中生智的康斯坦丁便選擇了割腕自殺的途徑,要知道自殺對天主教徒而言是要下地獄的,而死亡本身就是一種即時訊息,它是無須被放入Queue中就會立即被處理的。立即的Event引來了閻羅王,並阻止了他兒子利用”命運之戟”偷渡到人間的事件。康斯坦丁也因此得到了重生。

這個故事告訴我們,Queue的設計確實可以在不遺失訊息之下,成功的收取大量訊息,但不是所有的訊息都能一視同仁的,尤其是對那些有即時性的訊息,選擇Event的處理方式會比填入Queue中好多了。這一點我們可以向雲端來學習,也就是在Web Role (web前端) 與 Worker Role(後端的邏輯單元)之間運用Queue的方式來 loosely Coupled 的傳遞資料與訊息。這是一般的 PAAS 的設計架構。但如果你是採用IAAS的話,這些單元就必須自己組合了(下面這張架構圖就是在EC2上用幾個VM兜出來類似的solution)。這麼設計的目的是使得,不論是 web前端或是後端的邏輯單元都可以視負荷的種類,單獨的進行Scaling 作業。

arch

上圖中右側是抽象的運用Web role 作前端,Worker role作後端邏輯層的架構設計,左側則是細部實踐後的結果。Web role 與 Worker role 之間運用message bus 做銜接。

上面的故事是閒話,其實講到整合,指的是雲端與既有系統之間的交互運作。也就是Hybrid cloud。

混合雲 Hybrid cloud

產生Hybrid Cloud 的架構很單純的,理由是你想作到雲端上的程式相互呼叫,或是另一種類是由既有的程式與雲端程式之間的呼叫,這就構成了混合雲的架構了,但在這麼作之前首先你該作的是判斷是否真的需要這麼作?!請參考下圖:

決策圖

一口氣扯多了,下回再談…

廣告

Written by ruddyllee

2013 年 08 月 03 日 at 00:24:14

雲端的架構設計

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 日 at 16:04:23