雲端服務與經驗談 [6] 關於雲端搬家的八卦

雲端服務與經驗談 [5] 雲服務的成本控制與優化 << 前情

前一陣子讀到了這篇文章 從 Instagram 到 Dropbox，為什麼 AWS 正在失去大客戶？，有一種雲端供應商進入戰國時代的「錯覺」。這其實如同翻開報紙的娛樂版，看見人生中的悲歡離合。

不過大明星的戀愛故事總是仍我們太遙遠，Instagram 的案例算是一種嫁入豪門的概念，但其他的例子卻更值得做為省思的材料。如文中的 Zynga 與 Dropbox 漸漸走向混合雲的發展方向，以及一般認知的 Netflix 長久以來僅混合使用自建 Server 與 AWS 也有小道消息指出，它開始混合不同的雲端供應商：Netflix is no longer AWS only, Google Compute Engine and Maybe soon Softlayer。

即便每一個公司或開發團隊選擇的關鍵因素略各有不同，也非我們外部人員能任意揣測，不同就當成一個自省的機會，來想想在什麼情況下「我該從供應商 A 離開，進入供應商 B」或是「混合使用供應商 A, B, C 的服務」或是「自建雲搭配不同的供應商」。

回憶一下廣告

PAY AS YOU GO

這幾乎是所有雲端供應商都會告訴你的，用多少、付多才。隨付即用的新收費型態。首先，我們會看到的是這樣的系統負載的示意圖：

X 軸代表時間，Y 軸代表負載容量。藍線為該時間點的負載量，而淺灰色的橫線為目前系統負責的容量。在未使用彈性的雲端服務前，系統容量是個定值，需必透過事先的採購或變更合約服務等級來增加系統容量。若是系統的尖鋒與離鋒時期負載量差距過大，那麼就有超出系統負載的風險。以上圖來說，藍線代表的當時負載量，有一段時間是超出可用負載量的。

為了要增加總負載量，傳統的方法是加購或租用硬體或申請更多的流量。如上圖所示，我們現代表總負載量的灰線向上移動表示「已增加總負載量」後的態，那麼廣告或宣傳內容會這麼告訴你：「看看那些黃色的區段，就是總負載量以下，負載量之間的區域，那些都是浪費掉的資源」。我們應該這件事情更有彈性，要雲端化，由傳統的合約與整包購入的容量更加彈性，透過 API 你能自動開開關關服務，讓總負載量隨著你的需要變更，你也能應付突昇的負載量，它看起來會像是：

使用具有彈性的雲端服務後，你的負載量就可以由一個定值的灰線，變成淺紅色的那一條，隨著你的需求去調整容量。用多少，付多少。

對照一下現實世界

當上了雲端之後，風景是不是更為美好，得看看我們是以什麼思維面對雲端服務。如果只是把這些服務當成有方面 API 的 VPS 供應商，或是機房服務，那你的圖應該長成這個樣子：

那條應該彈性變動的總負載量為何如同心跳停止的心電圖呢？沒有以架構思維使用雲端服務，那只是換來一個可能更貴的服務供應成本。唯一能向外人道的，大概只有「喔！我們公司也有用雲端服務，很跟得上時代吧！」等帳單拿出來時，就知道是誰會被時代的洪流所淹沒。使用雲端服務沒有達到廣告宣稱的節省效果，到底是廣告的內容過於誇大，還是使用者未正確使用呢？這些都是可能的原因。

對於使用者的來說，一般公司內會接觸到雲端技術者有開發者與網管人員。典型的工作模式是，開發者向網管人員提出機器使用的需求，網管人員設法調配資源，生出機器無虛擬機給開發人員使用。開發人員獲得資源後，就能將程式部署上去。除了機器網路不通或資源不足，開發人員多半不會再與網管人員提出新的需求。這種典型的合作關係，並不存在的「彈性」調配資源的策略，僅是單純的提出需求與滿足需求罷了。那麼要將這「彈性調配資源」的策略放在哪一方呢？對於網管人員來說，依其職責應關心的網路流量、CPU 負載統計、HTTP 連線數統計數據，其實是作為「彈性調配」的重要素材，我們無法毫無邏輯憑感覺來決定什麼時間點需投入資源，什麼時間點需要撤銷多餘的資源。

我粗略地將因應雲端服務使用需要的技能區分為二類，一類有能力自製工作蒐集數據，並依數據總結出結論；一類僅能依賴現有工具製作視覺會結果，供人判讀情勢。後者能在工作報告或會議上提出易懂的圖解說明，對於討論或向非技術人員簡報時比較吃香。不過，前者能自製工作蒐集狀態，這更有助於透過目前的資料集合成有效資訊，做出適當的「結論」來判斷是否需要投入或撤銷資源。有將目前現狀「總結」的能力，剩下的就差網管人員或開發人員將這一連串的「推論」寫成自動化的工具，以達成「彈性調配資源」的目的。若是因各種原因網管人員無法支持，那麼「彈性調配資源」就應該落在開發人員身上。總是有人得出來關心這個問題，這樣一樣公司投入資源在雲端服務才能真的有所節省。

「彈性調配」始於觀察記錄，並運用數據掌握現狀，觸發資源再分配。以 AWS 為例，它就提供 AutoScaling 機器，並且內建許多「度量」的項目。廣為人知的如 CPU loading 監測。然而，上圖這般靜止的「彈性調配」結果，可能是無人關心「彈性調配」議題，或覺得責任不在自己身上，等有人指派再來關心的結果。雲對服務對於他們的好處，大概只是資源可以很快地取得，僅止而己。

雲端服務貴在哪裡

即使已經掌握「彈性調配」資源的要義，但有一天你能會發現雲端服務佔據大部分的營運成本，並且這個趨勢會與日俱增：Why Some Startups Say the Cloud Is a Waste of Money 這是篇 2013 年初的文章，有提到一些創新服務的心聲。隨著商業模型漸趨成熟，所使用的雲端資源穩定成長，我們可將它畫成下面的概念：

上圖是由彈性調配資源以達到不浪費為目標的圖例衍生而來，因為當服務的使用者穩定成長後，能彈性調配的空間就會被往上擠，也就是說總負載量的「下界」被提昇了。在那下界以下的地方即為整組服務的「固定成本」，無論如何彈性調配資源，都不會比這個界線再低。要因應這樣的局面，就得調整資源投入的比例，於是「混搭」不同的雲端供應商，或傳統 VPS 甚至搭配自建機房與包月製的頻寬費用都是可能的選項。即使畫成圖示之後的固定成本還是那麼大，但可以將固定成本換成價格較實惠的供應商。反之亦然，有些情況非固定成本的部分反而才是佔據花費的部分，得依讀者的實際情況判斷。

先來談談去除固定成本後，變動遽烈的負載量！以典型的網站服務來說，它平日需要的負載量是可以輕易承受住的，特別是傳統合約固定的網路配額。除此之外，可預估的行銷活動或節日就需要處理超出負載的部分！以我們公司的網站來說，它有週期性行銷活動，時間很固定，流量也固定地超標。由於它是傳統月租型的機房合約，有固定的流量配額，單一日臨時提高上限，需付二倍的價錢。不過，是否能買到足夠的流量額度又是件難以估算的任務。最後的選擇是，有行銷活動的日子，把整組的服務切換成雲端服務。即使將網路流量換算成單價去比較，使用雲端服務也許沒有優勢。不過成本這件事，到底還是看總花費的，別做贏了單價，輸了總成本的選擇。

當累積起足夠的日常使用者後固定成本的部分就會逐漸增加，這跟是否你將網站架構在雲端服務是沒有關聯的。只是差別在於得如何面對這些固定成本，並且試著改變架構與各供應商的組合比例。即使雲端服務可以方便地彈性調配資源，但有些東西就硬是比別人貴一些。同樣「網路流量」為例，AWS CloudFront 在亞太地區的輸出費用約為每 GB 需付新台幣 5.7 元（以 30 元台幣對 1 美元換算）：

或著再多查查不同的供應商，你會發現價格大同小異。例如 Microsoft Azure CDN 的價錢：

當你的服務是以輸出流量為主的，例如昴貴的 CDN 流量將左右公司的營收。這也是為什麼 Rolling Your Own CDN – Build A 3 Continent CDN For $25 In 1 Hour 這篇簡單實用的 Docker 範例那麼受大家歡迎，特別是對於使用量還沒大到能跟供應商議價的服務來說，它絕對是一個必需面對的課題。

不過，以流量費用的觀點，我並不在意標題談到的 25 USD，下面為 DigitalOcean 的價目表，以每月 10 USD 的方案為例，能換算出每 GB 約為 0.005 USD：

成本優化核心

在前一篇 雲端服務與經驗談 [5] 雲服務的成本控制與優化 提到成本優化的策略在於讀懂規則，並始研究服務的成本結構。過了那麼久的日子後，再寫了這篇相同領域但不同概念的文章，有了新的發現：經過講解後的規則，大家都能輕易明白利弊，但問題在於沒有人關心成本。

對於成本優化這件事，我仍是以 performance tuning 的想法來看的。沒有人關心成本的結果，就像是叫個不關心效能的人去對系統做最佳化。不在意問題，使得該有的敏感度下降；不在意問題，即使知道有規則，也不願意動手調整。不在意問題，只要不是在我的責任區就放生它吧。

我們有許多機會讓事情變得更好，就先別考慮角色與責任了，沒有權限動手時，至少當個諌官指出問題，理性地描述更佳的結構，該上雲端就上去，該撤離就立馬走人。任何的廣告、宣傳、推銷都不會影響身為開發者、架構師的理性判斷。