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

雲端服務與經驗談 [4] 架構與供應商相依問題 << 前情

PAY AS YOU GO

在參加各雲端供應商的研討會時，最常聽到雲端運算的優點：pay as you go。即為用多少，付多少，相較於傳統的一次性購入或是以月計費的 VPS，相當不同的，計費的模型式改變了，最小的時單位可以是小時、分鐘，也多出了次數與數量的彈性計費。這些特性被廣為宣傳，並植入這是「優點」的印象。看見「廣告」主打的優點時，必需同注意它有哪些缺點。這樣才算是理性、聰明的消費者。如一般的成藥廣告，主打不傷肝的同時，它的副作用可能是傷胃。

Pay as you go 的優點是用多少，付多少。那麼若未對於使用量加以注意，你付出的往往比你想得多。這也是這篇經驗分享的主要目的，將自己未加注意而多付出金錢的經驗分享出來。雲端服務的成本控制與優化，本質上是一種「規劃」的遊戲。想要得高分，就必需弄懂規則。該怎麼做才能避免非必要的花費？要怎麼做是對整體有利的？

成本控制的啟蒙

在這個系列文章的開始，我分享如何成為雲端「運算」的使用者，在哪之前公司只有使用 AWS S3 服務。公司的產品需要放置 plugin bundle 供使用者下載，若是單純放在一般的機房固定的網路頻寬，是無法供多個使用者同時更新 plugin bundle 的。那時我的建議是使用 AWS S3 服務，這很適合我們上傳一次被下載很多次的用法，讓流量的負擔「委外」給 AWS 去承受。運用雲端儲存服務，我們不用去掙扎是否要將機房的網路頻寬換成更多流量的問題。特別是這換一次就是一個月要多付那麼多錢，但實際上只有產品升級後的一週會用到較大的流量。這裡算是初嚐 pay as you go 的甜頭。

大半年後，我們啟動新的計劃（即此系統最初的二篇文章），也就是利用 AWS EC2 租用機器做資料運算。我們在美東地區執行二台 m1.small instance。若以每個月 720 小時計，m1.small 每小時 0.08 美元計算，單純付 instance 的錢就需 115.2 美元（720 *2 * 0.08），再加上把資料由 AWS 傳回自家伺服器的錢，平均每個月要支援 160 美元左右。當時算起來挺值得的，一個月才 5000 台幣以內，利用雲端主機運算結果，動態調整服務提昇產品品質。同時心理想著，如果有新型態的品質維護服務要加進來，是不是成本也都是 160 美元起跳呢？

這個疑問，直到我參加了一些技術分享的聚會與 AWS 官方辦的研討會，才有了解答，另一方面也是角色上有所轉變。本來我只是機器的「使用者」，後來因為用最多，所以這類服務的管理就自然落在我的身上。新的角色會有不同的觀點，以我們小公司來說，設計一個服務還是得將錢花在刀口上，勤儉持家為好。試著研究 AWS 產品與付價型態，發現有 reserved instance 的購買方式。也就是你先付出一筆錢，約定要使用一年或三年，AWS 提供你另一種比 on-demand instance 更為便宜的價錢。

舉例來說，我們選用 linux 主機方案，並選擇 m1.small 高使用率 3 年租約的價格：

需先支付 257 美元，每小時就能以 0.012 計價。若是同樣 2 台在美東的 m1.small 跑 3 年需花費：

257 * 2 + 3 * 12 * 720 * 2 * 0.012 = 1136.079 (每月均攤 31.557 美元)

若以 on-demand instance （假設 3 年皆不調價）需支付：

3 * 12 * 720 * 2 * 0.08 = 4147.199 (每月均攤 115.199 美元)

計算下來確實價錢差距很大，使用 reserved instance 是一個降低成本的方案。不過這個想法在參加 AWS 辦的實作 Lab 後，有了新的做法。在實作課中，看見講師示範如何以 ELB 配合 Auto Scaling 啟用機器，並且在重讀文件的過程認識不同的計價方式 spot instance。spot instance 簡單地說是 AWS 將閒置的 instance 拿出來讓大家競標，而價錢算起來有機會標到貼近 reserved instance 或更低的價格。不過，當你的出價不再具有優勢時，會被收回 instance（被其他人標走）。由於價格是浮動的，他的成本需由 spot instance 的歷史記錄估算。

由於我們的服務是後端運算的，不會直接服務使用者，並且有使用 job queue 記錄工作事項。即使遭遇 spot instance 被回收，也能在新的 spot instance 啟動後接續工作。最終的方案就是採用 auto scaling + spot instance 的方式運作。以帳單的記錄，這個方案單純算 spot instance 的花費約 20 美元左右。價格由 115 美元，降至 20 美元。這並不是變魔術，只是單純了解產品的支付方案與配合服務的使用型態調整使用方法。

成本優化策略

讀懂規則後，配合規則調整使用型態竟然讓成本有如此大差距。各位看倌是否對於研究您的供應商提供的價目表細節更有興趣了呢？「想要得高分，就必需弄懂規則」是我很喜歡的話，特別是在計劃與程式校能調校方面，它算是極為重要的「心法」。面對雲端服務成本也是如此，本質上這也是一種程式校能調校。只是所面對的不是 CPU 使用率，不是記憶體使用總量或配置的控制，也不是如何讓佔時間的函式跑得更快。共通的是它得有一個「整體」的印象分數，除了細節部分變得更好之外，不能有嚴重的副作用讓「總分」變糟。對於調整程式來說，只要是系統崩潰了，那麼總分肯定不及格。而對於成本控制來說，得控制在合理的預算內。特別是 startup 公司運用雲端服務，無法控制預算，就可能直影響公司的壽命。得把錢流向雲端的速度減低！

在這裡我們並不是要教導讀者如何計算費用，這些看價目表或使用各供應商精美的費用計算器，很快的都能算出。你能事先想到的問題通常不是問題，問題都是發生在你預料之外的事。打開帳號，第一時間心理的 OS：「怎麼會這樣！？」

舉個通用的例子：網路流量計費。無論您使用哪一家供應商，只要不是固定額度、固定費用的網路費用，就會是用越多繳越多，這通常是難以估計的情況。以服務使用者來說，你可能無法預計使用者會帶走多少資料，或是以運算工作的單位來說，理論上在網路上交換資料的次數，與工作數量成正比，工作越多網路就會使用越多。但由於不同供應商的計費方式，就會讓你付出的成本不同。

以 AWS EC2 為例，網路資料的流入是否計費，無論多少都不計費，而資料流出是否計費要看目的。若你是傳到同區使用內部 IP 的 EC2 或 S3 就不算費用（但你會產生 S3 的儲存費用），若你是傳到不同區的 EC2 會有一點折扣，若是傳到 AWS 之外的地方，那就是最標準的計費。所有的流量是同一份帳單，各種服務（排除 CDN）合併計算；以 MiCloud 為例，網路流入流出都計費，但是要超過 200GB 門檻才計費，此門檻是以機器為單位，非單一帳號的總量為單位。

上述二種不用的計價規則，會讓你朝向不同的方式建構你的服務。單純以運算來說，AWS 只要你有本事把資料控制在只進不出（配合區內的資料流動與 S3 或 EBS 存放資料），真的需要時才取資料，那能將網路流出量控制在極低的情況。以 MiCloud 來說，由於它是以機器為單位計算的，超量前重開就不需要替網路的流量付出額外的費用。

當你試著控制對於成本變化極大的項目後，你自身預估的成本才會貼近預測的數字。試著每個月瀏覽帳單試著漸漸去掉那些不見得需要存在又影響你預估準度的項目，以下我提供一些實際經驗過的例子。

案例一：EBS IO 費用

我們有一個影像處理的程式，它會對一部影片取得一些描述資訊與剪輯。這些資料說大不大，說小不小，但跑起來其實也不太耗資源，所以我們選用 EC2 裡最小的 m1.micro instance 執行它。它最終會產生一些檔案與描述資訊，過程都被暫存在 EC2 的磁碟上（我們選用的磁碟是 EBS 型態的）。即使我們使用 spot instance 是很便宜的，但長期觀察帳單，發現一個現象：EBS IO 費用約佔該服務的 40%。這表示有 4 成的費用浪費在暫時性的檔案內。這樣的問題它會也被發在大量的 log 輸出，如果你放在 EC2 的 log 並不會有機會被人分析，那就是一件浪費錢的事情。

這個種浪費就會影響成本估算總是比想像中多花一點錢。它的解決方法只能減少 EBS IO，具體來說該如何做，得看你程式是否能適當改寫成：
1. 不使用暫存檔，直接在記憶體內一次搞定然後送往目的地
2. 如果你非得要有暫存檔，那畫一個 ramfs 出來寫在上面，反正記憶體的 IO 又不算錢。

我當時的情況必需產生暫存檔，所以畫了一個 100 MB 的 ramfs 將檔案輸出在該磁碟分割。

案例二：網路超量（規則理解錯誤）

由於一開始使用 AWS 部分程式，將它的收費規則先入為主記在腦袋。後來因部署地區的需求，使用 MiCloud 的部分。我在上面部分一個網路流入極大，流出極小的運算程式。某天接到 MiCloud 關切，大意是說我的網路流量超過免費額度，所以他們來關心一下我的主機是否有中毒。從那次開始，我才真的熟記了 MiCloud 的計費規則是流入、流出合併計算的。

最終修改了 instance 管理程式，並加裝 vnstat 即使監看 instance 目前流量，在超量前自動重建運算主機。

案例三：網路超量（流入、流出角色混淆）

我們在 EC2 上部署了許多運算程式，並且有自制的 Job Queue。在最初的設計中，Job Queue 的流出、流入量是均勻的，放在 EC2 外佔總成本不大，但會佔據一定的比例的費用。由於每日的 Job 數很多，累積合算起來，比開一台 m1.small 的 spot instance 要多上許多，我們把它移到 EC2 內，減少使用 Job Queue 派發工作的成本。

後來仿 Simple Queue Server 設計新的 Job Queue，讓它流出、流入的比例改成對使用 AWS 計價方式有利的比重。為了觀察是否真的省了很多錢，使用子帳號進行測試，由於是不同帳號開出的 EC2 所以是算網內的費用，一開始沒想清楚它對彼此來說都算流出。加上調整了流出、流入比例，使得網路使用成本更是雪上加霜，費用變成二倍的 EC2 流量的網內價格。

正確的用法就是回到最初的計算，把 Job Queue 搬離 EC2。讓 AWS 之外，使用固定費用的主機提供 Job Queue，對任何 EC2 機器來說，都是流入不予計費。只要放對位置，它是比第一代 Job Queue 便宜的，而放錯了位置，那就是隻肥大的吸血怪物。

以上簡單的舉例，相信可以開啟一些讀者對於雲端服務成本優化策略的參考。當你無法確定你的設計時，可以試著小規模試跑看看。不過建議是用完全尚未產生費用的帳號測試，這方法雖然原始，但是相當可靠。花小錢買經驗，總比將白花花的銀子灑向雲端好。

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