調整計算資源
雲端的一個重要優點是能夠視需要將資源調整為系統。 相應增加 (佈建更大型的資源) 或相應放大 (佈建額外的資源) 有助於降低系統上的負載，這是因為工作負載的容量提升且散佈更廣，使得使用率得以減少之故。
縮放後，由於可以執行大量要求，回應能力 (以及從使用者的角度感受到的效能) 會因為輸送量的增加而獲得改善。 這也有助於減少尖峰負載期間的延遲，因為會在單一資源的尖峰負載期間，將較少的要求數目排入佇列。 此外，縮放也能改善系統的可靠性，因為這樣會減少資源使用率，避免系統接近中斷點。
請務必注意，雖然雲端可讓我們輕鬆地佈建較新或更好的資源，但成本始終是需要考慮的相對因素。 因此，即便相應增加或相應放大很有好處，也請務必明辨相應縮小或相應減少的時機，藉此節省成本。
水平縮放 (相應縮小與相應減少)
水平縮放是一種將額外的資源新增至系統，或隨著長期運作從系統中移除無關資源的策略。 如果系統中的負載會以不一致或無法預期的方式而浮動，這種縮放類型對伺服器層很有幫助。 由於負載的浮動性質，使得這種縮放不可或缺，因為這樣才能佈建正確數量的資源，以便隨時都能處理負載。
但有幾種疑慮會讓這種縮放便得困難：
- 執行個體 (例如虛擬機器) 的起轉時間
- 雲端服務提供者的計價模式
- 由於未及時相應縮小而降低服務品質 (QoS) 的潛在收益損失。
圖 5：負載模式範例。
以上方圖 5 中的負載模式為例。
假設我們使用 Amazon Web Services，每個時間單位相當於 1 小時的實際時間，且我們需要一部伺服器來處理 5,000 個要求。 在時間單位 6 和 8 之間，以及時間單位 14 和 16 之間，需求會達到尖峰。 我們取後者為例。 我們可以偵測到需求在時間單位 16 左右下降，資源的配置數量開始降低。 由於我們要在 3 小時期間內從大約 90,000 個要求降至 10,000 個要求，經過計算，我們可以節省十幾個額外執行個體的成本，這些執行個體原本會在時間 15 上線運作。
圖 6 顯示的縮放模式會即時調整執行個體數量來配合負載模式，當中的執行個體數量顯示為紅色。 在尖峰需求期間，執行個體數量會分別相應放大為 20 和 18，藉此提供處理流量所需的資源。 在其他時間，執行個體數量會減少 (相應縮小)，讓資源使用率保持相對不變。 如果我們假設每個執行個體的成本為一小時 20 美分，則持有 20 個執行個體 24 小時的成本就是 96 美元。 縮放執行個體計數 (如圖所示) 可將成本降至約 42 美元，每年可節省超過 15,000 美元。 對於幾乎所有 IT 預算而言，這都是相當大的金額。
圖 6：依需求相應縮小和放大。
調整取決於流量的特性，以及其隨後在 Web 服務上產生的負載。 如果流量遵循可預測的模式，例如以人會在夜間從 Web 服務中串流電影等行為作為根據，則縮放就「可預測」，藉此維持 QoS。 不過，許多情況下流量並無法預測，因此縮放系統必須根據不同的準則來「應變」。
值得注意的是，您可以使用容器執行個體和 VM 執行個體來執行相應縮小與相應放大。 VM 中的工作負載傳統上是在雲端中執行，但在容器中執行的情況已越來越普遍。 藉由增加和減少 VM 數量，您能夠隨 VM 式工作負載而達成縮放。 同樣地，容器式工作負載也可能會隨容器數量的變更而縮放。 由於容器的啟動速度通常比 VM 快，新容器執行個體的上線時間比 VM 執行個體更短，因此彈性較大一些。
垂直縮放 (相應增加和相應減少)
水平縮放是一種獲得彈性的方式，但不是唯一選項。 假設您的網站流量在每個時間單位很少超過 15,000 個要求，而您佈建了可處理 20,000 個要求的單一大型執行個體，足以良好處理一般流量，而且也能應付較小的尖峰。 如果網站的負載成長，您可以將伺服器執行個體取代為具有兩倍 CPU 核心和兩倍 RAM 的伺服器執行個體，以適度地容納流量的增加。 這就是「相應增加」。
垂直縮放的主要難題是，通常會遭遇到可視為停機時間的切換時間。 這是因為，為了從較小的執行個體將所有作業移至較大的執行個體，即使切換時間只有數分鐘，服務品質也會在該間隔內降低。
垂直縮放的另一個限制是資料粒度降低。 如果您有 10 個伺服器執行個體上線，且需要暫時增加 10% 的容量，您可以從 10 個執行個體相應放大為 11 個，藉此達到預期結果。 但是，透過垂直縮放，下一個較大執行個體的大小通常約為前一個執行個體容量的兩倍，相當於從 10 個執行個體水平縮放為 20 個，卻只為了容納 10% 的流量增加。 相較於水平縮放，這種方法不太符合成本效益。
最後一個使用垂直縮放時需要考量的疑慮是可用性。 如果您有一個要為所有網站客戶提供服務的大型執行個體，該執行個體停機時，網站也會停止運作。 相反地，如果您佈建 10 個小型執行個體來處理相同負載，其中一個執行個體停機，使用者可能會發現效能稍微降低，但仍能存取網站。 因此，即使負載可預測，且會隨著越來越多人使用服務而穩定增加，許多雲端管理員也會選擇水平縮放，而非垂直縮放。
縮放伺服器層
相較於單純佈建更多資源 (相應放大) 或較大型資源 (相應增加)，延展性有時更加細微。 在伺服器層上，需求的增加可能會提高特定資源類型 (例如 CPU、記憶體和網路頻寬) 的競爭。 雲端服務提供者通常提供的 VM 已針對計算密集型工作負載、記憶體密集型工作負載和網路密集型工作負載而最佳化。 掌握自己的工作負載並挑選正確的 VM 類型，和針對問題而增加 VM 的數量或大小一樣重要。 比起採用 10 部 VM 來處理計算密集型工作負載，五部是更好的選擇，即使針對 CPU 密集型工作負載而最佳化的 VM 比一般 VM 的成本高出 20% 亦同。
增加硬體資源不一定是提高服務效能的最佳解決方案。 提高服務使用的演算法效率，也可以減少資源競爭並改善使用率，不需縮放實體資源。
進行縮放時，狀態的有無也是一個重要考量。 無狀態服務的設計適用於可縮放的架構。 無狀態服務基本上表示用戶端的要求中包含伺服器處理要求時所需的所有資訊。 伺服器不會在執行個體中儲存任何與用戶端相關的資訊，而且會在伺服器執行個體中儲存所有與工作階段相關的資訊。
無狀態服務有利於隨意切換資源，無需任何設定就能針對後續要求維護用戶端連線的內容 (狀態)。 如果服務具狀態，則資源的縮放需要採取策略，以便將內容從現有設定傳輸至新設定。 請注意，有些技術可以用來實作具狀態服務，例如維護網路快取，以便在伺服器之間共用內容。
縮放資料層
在資料導向的應用程式中，如果資料庫或儲存系統有大量的讀取和寫入 (或兩者皆有)，則每個要求的來回時間通常會受到硬碟讀取和寫入時間所限制。 大型執行個體可提供較高的 I/O 效能，這可以改善硬碟的搜尋時間，進而減少服務的延遲。 雖然資料層中有多個資料執行個體可以藉由提供容錯移轉備援來改善應用程式的可靠性和可用性，但是，如果用戶端會由實際上較接近它的資料中心提供服務，則在多個執行個體之間複寫資料會有減少網路延遲的額外優點。 跨多個資源的資料「分區化」或分割，是另一個水平資料調整策略，其不只會在多個執行個體之間複寫資料，而是會將資料分割成區段並儲存於多部資料伺服器上。
調整資料層的另一個挑戰是維護一致性 (所有複本上的讀取作業都一樣)、可用性 (讀取和寫入一律會成功)，以及分割區容錯 (當失敗導致無法跨節點通訊時，保證會維護系統中的屬性)。 這通常稱為「CAP 定理」，其表示在分散式資料庫系統中，很難完全取得這三個屬性，因此，最多可能會呈現兩個屬性的組合1。
參考資料
- 維基百科。 CAP 定理。 https://en.wikipedia.org/wiki/CAP_theorem.