Windows Azure 的成本架構

TechNet 雜誌文章 http://technet.microsoft.com/zh-cn/magazine/gg213848.aspx

Windows Azure 這類雲端運算和平台被宣為 IT 行業中的“下一個大題材”。想到雲端運算集萬千優勢於一身，這麼說似乎確實不為過。

您可以隨時按需使用計算和儲存，而且只需為有效使用付費。不過，這也帶來一個問題。如果像設計普通應用程式那樣設計一個雲應用程式，該應用程式的成本很可能將不容樂觀。

不同的度量標準

在傳統 IT 行業中，IT 人員將購買一套硬體（網路基礎結構、伺服器等），對其進行設定、執行配置過程並串連到 Internet。這是一次性投資，由員工來控制“旋鈕”和“螺栓” — 就是這樣。

而對於雲端運算，成本模型將替代該投資模型。根據伺服器功能和儲存的有效使用支付這類資源的費用。對於 Windows Azure 這類雲平台，您可以使用下列度量值計算月度費用：

• 保留虛擬機器 (VM) 的小時數 — 表示為已部署的應用程式付費，即使該應用程式當前沒有運行
• VM 中 CPU 的數量
• 頻寬（以每次傳入/傳出 GB 為單位）
• 使用的儲存量（以 GB 為單位）
• 儲存中的事務數
• SQL Azure 中的資料庫大小
• Windows Azure 平台 AppFabric 中的串連數

您可以在 Windows Azure 網站 microsoft.com/windowsazure/offers 上找到所有定價詳細資料。從以上列表中可以看出，要考慮許多因素。

限制虛擬機器

下面從實用角度進行分析。限制正在啟動並執行 VM 的數量是一種很好的節約成本的方式，但是對於 Web 角色，最好具有至少兩個可用的 VM 來實現Server Load Balancer。使用 Windows Azure 診斷 API 測量這些執行個體中的 CPU 使用率、HTTP 要求量和記憶體使用量率並在適當時縮小應用程式的大小。

每月在 Windows Azure 上啟動並執行任意角色的每一個執行個體都會使帳單上的小時數增加一倍。例如，在幾乎沒有任何工作負載的情況下，平均運行 3 個角色執行個體（有時 2 個，有時 4 個）將比始終運行 4 個執行個體便宜 25%。

對於工作者角色，也最好具有至少兩個角色執行個體來執行幕後處理。這樣有助於確保當其中一個角色執行個體出現故障，需要更新或重新啟動角色時，應用程式仍然可用。您可以使用 Windows Azure 提供的工具將某個工作者角色直接配置為僅供執行某一個任務專用。

例如，如果您正在運行照片分享網站，您需要使用一個工作者角色來調整映像大小，使用另一個角色來寄送電子郵件通知。遵循“至少 2 個執行個體”規則將意味著運行 4 個工作者角色執行個體，這將產生相當大的一筆費用。調整映像大小和寄送電子郵件實際上不佔用 CPU，因此，僅兩個工作者角色就應足以完成這兩個任務。對運行 Windows Azure 來說，這將節省 50% 的月度費用。在工作者角色中實現線程機制以使各個線程執行其專門負責的工作也相當容易。

Windows Azure 提供了下列四種大小的 VM：小型、中型、大型和特大型。各個大小之間的區別在於可用的 CPU 數量、可用的記憶體和本機存放區量以及 I/O 效能。在為 Windows Azure 實際部署 VM 之前，最好想清楚適當的 VM 大小是多少。一旦應用程式開始運行，就無法更改大小。

當您收到月度清單時，您將注意到所有計算小時在帳單上都被轉換為小型執行個體時數。例如，一個中型計算執行個體的 1 小時將按照小型執行個體比率顯示為兩個小型計算執行個體時數。如果您正在運行兩個中型執行個體，將按 720 x 2 x 2 個小時付費。

請在調整 VM 的大小時考慮此因素。您可以使用小型執行個體實現幾乎相同的計算能力。假設您有四個小型執行個體，則按 720 x 4 個小時付費。價錢是一樣的。您可以在適當時縮減到兩個執行個體，即按 720 x 2 個小時付費。如果您不需要更多 CPU、更多記憶體或更多儲存，請堅持使用小型執行個體，因為相對於大型執行個體來說，小型執行個體的調整層級更為精細。

Windows Azure 服務從您部署應用程式開始計費，無論角色執行個體處於活動狀態，還是已關閉。Windows Azure 門戶中有很清楚的說明。該門戶上有一個大型映像框。“當該框顯示為灰色時，大可放心。當該框顯示為藍色時，開始計費。”（感謝 Brian H. Prince 的這句俏皮話。）

在您將應用程式部署到暫存或運行環境並在使用後將其關閉時，請不要忘了還要取消部署應用程式。您不希望為任何不活動的應用程式付費。另外還要記住在適當時縮減應用程式。這將直接影響月度運營成本。

增加和縮減應用程式時，最好使一個角色執行個體至少運行一個小時，因為您是按小時付費的。在工作者角色中建立多個工作者線程。這樣，工作者角色就可以執行多個任務，而不是僅僅執行一個任務。如果您不需要更多 CPU、更多記憶體或更多儲存，請堅持使用小型執行個體。再次重申，當您不使用應用程式時，請確保取消部署。

頻寬、儲存和事務

頻寬和事務是兩個比較複雜的度量標準。除了查看月度費用以外，目前沒有什麼很好的方法來測量這些資料。沒有您可以查閱和用來調整應用程式的即時監視。頻寬在這兩個度量標準中比較容易測量。使用的網路流量越少，成本越低。就是這麼簡單。

在多個 Windows Azure 地區內部署應用程式時，事情會複雜一些。假設您在“北美”地區內運行 Web 角色，在“西歐”地區內運行儲存體帳戶。在這種情況下，用於 Web 角色和儲存之間的通訊的頻寬將計費。

如果 Web 角色和儲存都位於同一地區（例如，都位於“北美”地區），則 Web 角色和儲存之間的通訊將不產生頻寬費用。請記住，設計異地分布式應用程式時，最好使搭配使用的服務位於同一 Windows Azure 地區內。

使用 Windows Azure 內容傳遞網路 (CDN) 時，您可以利用另一項有趣的降低成本的措施。CDN 的計量方式與 Blob 儲存體相同，即按每月每 GB 儲存量計費。向 CDN 發出請求後，它將從 Blob 儲存體中擷取原始內容（包括已計費的頻寬消耗）並對其進行本機快取。

如果將緩衝到期時間 header 報文設定得太短，它將消耗更多頻寬，因為 CDN 緩衝將更頻繁地進行自我更新。如果將緩衝到期時間設定得太長，Windows Azure 會延長內容在 CDN 中儲存的時間並按每月每 GB 儲存量計費。針對每個應用程式考慮此因素，以便確定最佳緩衝到期時間。

Windows Azure 診斷監視器還將 Blob 儲存體用於診斷資料，如效能計數器、追蹤記錄檔、事件記錄等。它按照預先指定的時間間隔將此資料寫入您的應用程式。每分鐘寫入將增加儲存中的事務計數，從而導致額外成本。將寫入的時間間隔設定為 15 分鐘就會使儲存事務減少。不過，這樣做有一個缺點，即診斷資料將始終是至少 15 分鐘以前的資料。

此外，Windows Azure 診斷監視器不會清除其資料。如果您不親自清除資料，就可能要為許多隻包含舊的、已到期的診斷資料的儲存付費。

按 10.000/事務計費。這個數字可能看起來很高，但實際上您得為事務付費。儲存體帳戶中的每項操作都是一個事務。建立一個 Blob 容器、列出 Blob 容器的內容、將資料存放區在表格儲存體上的表中、瀏覽隊列中的訊息 — 所有這些都是事務。例如，當執行 Blob 儲存體這類操作時，您將首先檢查 Blob 容器是否存在。如果不存在，則必須建立一個，然後儲存一個 Blob。這至少是兩個（可能 3 個）事務。

此計數方式同樣適用於在 Blob 儲存體中承載靜態內容。如果您的網站在一頁上承載了 40 個小映像，就相當於 40 個事務。這可在高流量應用程式的帶動下快速增加。只需確保在應用程式啟動時存在 Blob 容器並跳過檢查每個後續操作，您就可以將事務數量減少幾乎 50%。通過這樣的巧妙處理，可以減少費用。

索引可能很昂貴

SQL Azure 是一種很有趣的產品。您能以極低的月價購買 1GB、5GB、10GB、20GB、30GB、40GB 或 50GB 的資料庫。您完全可以直接購買 5GB 的 SQL Azure 資料庫，這非常安全。即便您僅使用其中 2GB 的容量也不打緊，因為您實際用的並不是按使用方式付費模型，對不對？

在某些情況下，將您的資料分發給不同的 SQL Azure 資料庫比使用一個大型資料庫可能更經濟高效。例如，您可以使用一個 5GB 和一個 10GB 的資料庫，而不是使用一個包含 5GB 的未使用容量的 20GB 的資料庫。如果您巧妙地處理此類型的策略儲存並且此儲存方式適用於您的資料類型，對您減少所付的費用將極有好處。

每個對象都佔用儲存空間。索引和表可能會佔用大量資料庫儲存容量。大型表可能佔用資料庫的 10%，某些索引可能佔用資料庫的 0.5%。

如果您按資料庫大小劃分 SQL Azure 訂閱的月度成本，將得出一個按儲存情況計算成本的單位。考慮一下您資料庫中的對象。如果索引 X 每月的成本為 50 分且實際上並沒有使效能顯著提高，那麼只需將其丟棄。雖然半美元並不多，但是如果您消除一些表和一些索引，這許多個半美元加起來就是一筆可觀的數目。可在 SQL Azure 團隊部落格文章“索引的實際成本”(blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx) 中找到與此相關的一個有趣樣本。

應用程式開發方面有一項巨大轉變，即不再在資料庫中使用預存程序，而是在應用程式邏輯中對資料使用對象關係對應程式並執行大量計算。

這種做法本身並無任何問題，但考慮到 Windows Azure 和 SQL Azure 時，就有意思了。在應用程式中執行資料計算可能需要其他 Web 角色或工作者角色執行個體。如果改成在 SQL Azure 中進行這些計算，則在這種情況下您將節省一個角色執行個體。因為 SQL Azure 是按儲存情況（而不是 CPU 使用率）計費的，所以您實際上可在資料庫中獲得免費 CPU 週期。

開發人員影響

編寫代碼的開發人員對成本有直接影響。例如，構建以 Windows Azure 為宿主的 ASP .NET 網站時，您可以使用 Windows Azure 備份儲存工作階段狀態提供者在不同的角色執行個體間進行分發。此提供者將會話資料存放區在 Windows Azure 表格服務中。將度量該表格服務中使用的儲存量、使用的頻寬量和事務計數以進行計費。請看以下用於確定每個請求中的使用者語言的程式碼片段：

複製代碼

if (Session["culture"].ToString() == "en-US") {  // .. set to English ...}if (Session["culture"].ToString() == "nl-BE") {  // .. set to Dutch ...}

沒有任何問題？技術上是沒有問題，但您可以從成本角度對它進行最佳化以使成本降低 50%：

複製代碼

string culture = Session["culture"].ToString();if (culture == "en-US") {  // .. set to English ...}if (culture == "nl-BE") {  // .. set to Dutch ...}

這兩個程式碼片段的功能完全一樣。第一個程式碼片段讀取了兩次會話資料，而後者僅讀取了一次。這就意味著後者將在頻寬和事務計數方面節約 50% 的成本。對隊列來說同樣如此。每次讀取一條訊息，讀取 20 次，將比一次讀取 20 條訊息昂貴得多。

可以看出，雲端運算為承載應用程式帶來了不同的經濟和定價細節。與傳統資料中心相比，雲端運算可以算是運營成本方面的一項重大改進，但是在設計雲時，您必須注意應用程式體繫結構中的一些注意事項。

Maarten Balliauw 是 RealDolmen（比利時最大的一家 ICT 公司）的 Web 技術領域的技術顧問。他主要研究 ASP.NET MVC、PHP 和 Windows Azure。他是 Microsoft 最有價值的 ASP .NET 專家，已在 PHP 和 .NET 文獻中發表了許多文章，例如《MSDN 雜誌》、《Belgium》和《PHP Architect》。Balliauw 經常在各種省/地區和國際活動中發表演講。請訪問 blog.maartenballiauw.be 查看他的部落格。