調整資源
雲端的一個重要優點是能夠視需要將資源調整為符合系統。 擴大 (佈建較大型資源) 或擴增 (佈建額外的資源)，可藉由提高容量或更廣泛地散發工作負載來減少使用率，以協助降低單一資源上的負載。
調整可藉由提高輸送量來協助改善效能，因為現在可服務大量要求。 這也有助於減少尖峰負載期間的延遲，因為會在單一資源的尖峰負載期間，將較少的要求數目排入佇列。 此外，這可將資源使用率降低到遠離資源中斷點，藉此協助改善系統的可靠性。
請務必注意，雖然雲端可讓我們輕鬆地佈建較新或更好的資源，但成本始終是需要考慮的相對因素。 因此，即使擴大/擴增有所助益，但也請務必辨識何時要縮小/縮減以節省成本。 在多層式架構 (N-Tier) 應用程式中，您還必須指出瓶頸的位置，以及要調整的階層 (不論是資料層或伺服器層)。
調整資源時可利用負載平衡 (如稍早所述)，這有助於將其隱藏在一致的端點後方，以遮罩系統的調整層面。
調整策略
水平調整 (擴增和縮減)
水平調整是一種策略，可將額外的資源新增至系統，或從系統中移除無關的資源。 當系統上負載無法預期且以不一致的方式變動時，這種類型的調整對於伺服器層而言很有助益。 變動性負載其本質對於有效率地佈建正確的資源數量以隨時處理負載很重要。
執行個體的啟動時間、雲端服務提供者的計價模式，以及由於未及時擴增而降低服務品質 (QoS) 的潛在收益損失等一些考量，使得這成為一項挑戰工作。 例如，請考慮下列負載模式：
圖 6︰範例要求負載模式
假設我們正在使用 Amazon Web Services。 此外，假設每個時間單位相當於 3 小時的實際時間，而我們需要一部伺服器來服務 5,000 個要求。 如果您考慮在時間單位 16 到 22 期間的負載，則負載中會有相當大的變動。 我們可以偵測到剛好在時間單位 16 附近的需求降低，並開始減少配置的資源數目。 由於我們要在 3 小時內從大約 50,000 個要求降至幾乎 0 個要求，因此理論上可省下在時間 16 一直處於上線狀態的 10 個執行個體成本。
現在，改為假設每個時間單位相當於 20 分鐘的實際時間。 在此情況下，在時間單位 16 縮減所有資源只是為了在 20 分鐘之後擴增新的資源，實際上會增加而不是節省成本，因為 AWS 會針對每個計算執行個體每小時計費一次。
除了上述兩個考量以外，服務提供者也必須在時間單位 20 提供較低的 QoS，以評估其所產生的損失 (如果其容量只有 90,000 個要求，而不是 100,000 個要求)。
調整取決於流量的特性，以及其隨後在 Web 服務上產生的負載。 如果流量遵循可預測的模式 (例如根據人類行為在晚上從 Web 服務串流處理電影等)，則調整是「可預測的」，以維持 QoS。 不過，在許多情況下都無法預測流量，而調整系統必須根據不同的準則來「回應」，如上述範例所示。
垂直調整 (擴大和縮小)
對於服務提供者而言，有些負載類型比其他類型更容易預測。 例如，如果您從歷程記錄模式得知要求數目始終為 10,000-15,000，則可放心假設一部可服務 20,000 個要求的伺服器，便足以達成服務提供者的目的。 這些負載未來可能會增加，但只要以一致的方式增加，就可將服務移至可服務更多要求的較大型執行個體。 這適用於會遇到較少流量的小型應用程式。
垂直調整的挑戰在於一律會有一些可視為停機時間的切換時間。 原因在於為了將所有作業從較小型執行個體移至較大型執行個體，即使切換時間只有數分鐘，QoS 也確實會在該間隔內降低。
此外，大部分雲端提供者會透過將資源的計算能力加倍，以增加計算能力來提供計算資源。 因此，擴大的細微性不如水平調整一樣細緻。 因此，即使負載是可預測且會隨著服務熱門程度的提高而穩定增加，許多服務提供者也會選擇水平調整，而非垂直調整。
調整考量
監視
監視是有效調整資源的最重要元素，因為其可供使用計量來解譯系統的哪些部分需要調整，以及何時需要調整。 為了將 QoS 及收益最大化，監視能夠分析流量模式或資源使用率，以便就何時及如何調整資源方面憑經驗進行評定。
有數個層面的資源會受到監視，以便觸發資源調整。 最常見的計量是資源使用率。 例如，監視服務可以追蹤每個資源節點的 CPU 使用率，並在使用量過高或太低時調整資源。 例如，若每個資源的使用率超過 95%，則新增更多資源可能是個好主意，因為系統負載過重。 服務提供者通常會藉由分析資源節點的中斷點來判斷其何時開始失敗，以及詳細提出其在各種負載層級中的行為來決定這些觸發點。 儘管基於成本因素，務必要充分利用每個資源，但還是建議保留一些空間讓作業系統能夠進行經常性活動。 同樣地，如果使用率大幅降低到 50%，則可能不是所有資源節點都是必要的，有些可以取消佈建。
實際上，服務提供者通常會監視數個不同資源節點計量的組合，以評估調整資源的時機。 這其中包括 CPU 使用率、記憶體耗用量、輸送量和延遲。 Azure 提供 Azure 監視器作為額外的服務，以監視任何 Azure 資源並提供這類計量。
無狀態
無狀態服務的設計適用於可縮放的架構。 無狀態服務基本上表示用戶端的要求中包含伺服器處理要求時所需的所有資訊。 伺服器不會在執行個體上儲存任何與用戶端相關的資訊，且會在伺服器執行個體上儲存任何與工作階段相關的資訊。
無狀態服務有利於隨意切換資源，無需任何設定就能針對後續要求維護用戶端連線的內容 (狀態)。 如果服務是具狀態的，則資源調整需要一個策略，以將內容從現有節點設定傳送至新的節點設定。 請注意，有些技術可用來實作具狀態服務；例如，使用 Memcached 維護網路快取，以便在伺服器之間共用內容。
決定要調整的內容
視服務的本質而定，必須根據需求需要調整不同的資源。 針對伺服器層，隨著工作負載的增加，視應用程式類型而定，可能會增加 CPU、記憶體、網路頻寬或以上所有資源競爭的情況。 監視流量可供識別哪個資源逐漸受到限制，並適當地調整該特定資源。 雲端服務提供者不一定只為調整計算或記憶體而提供可擴縮性資料粒度，但確實會提供不同類型的計算執行個體，其專為滿足大量計算或記憶體繁重的負載。 例如，對於記憶體工作負載吃重的應用程式，建議相應增加記憶體已最佳化的執行個體資源。 至於需要處理大量要求，但不一定需要大量計算或大量記憶體的應用程式，相應放大多個標準計算執行個體會是比較好的策略。
提高服務效能的最佳解決方案不一定是增加硬體資源。 提高服務所用的演算法效率，也有利於減少資源競爭並改善使用率，如此即不需要調整實體資源。
調整資料層
在資料導向的應用程式中，資料庫或儲存系統如有大量的讀取和寫入 (或兩者)，則每項要求的來回時間通常會受到硬碟 I/O 讀取和寫入時間所限制。 較大型執行個體可提供較高的讀取和寫入 I/O 效能，這可改善硬碟上的搜尋時間，進而大幅改善服務延遲。 在資料層中擁有多個資料執行個體，可藉由提供容錯移轉備援來改善應用程式的可靠性和可用性。 將資料複寫到多個執行個體時，如果用戶端是由地緣上較近的資料中心所服務，則對降低網路延遲會有額外優勢。 跨多個資源的資料分區或分割是另一種水平資料調整策略，其不只是在多個執行個體之間複寫資料，而是將資料分割到多個分割區並儲存在多部資料伺服器中。
調整資料層的另一個挑戰是維護一致性 (所有複本上的讀取作業都相同)、可用性 (讀取和寫入一律會成功)，以及分割區容錯 (當失敗導致無法跨節點通訊時，保證維護系統的屬性)。 這通常稱為 CAP 定理，其表示在分散式資料庫系統中很難完全取得這三種屬性；因此，系統最多只會呈現兩種屬性的組合。 您會在稍後的課程模組中深入了解資料庫調整策略和 CAP 定理。