彈性伸縮

彈性伸縮（Autoscaling），是雲計算中的一種常用方法，通過該方法，伺服器池中的計算資源量（通常根據有效的伺服器數量來衡量）會根據伺服器池中的負載進行動態伸縮。它與負載均衡緊密相關，並以此為基礎。

## 優勢

彈性伸縮具有如下優點：

- 對於服務運行在自建機房的公司，彈性伸縮通常意味著允許一些伺服器在低負載時進入睡眠狀態，從而節省電費（以及用於冷卻機器的水費和水費）。
- 對於使用在託管在雲上的機房的公司而言，自動擴展可能意味著更低的費用，因為大多數雲提供商都基於總使用量而不是最大容量進行收費。
- 即使對於不能在任何給定時間減少運行或支付的總計算能力的公司，它們也可以在低流量時降低伺服器的負載。
- 彈性伸縮解決方案（例如Amazon Web Services提供的解決方案）還可以用來替換異常狀態的實例，從而在一定程度上防止硬體，網路和應用程式故障。
- 在生產工作負載經常變化且不可預測的情況下，彈性伸縮可以提供更長的正常運行時間和更高的可用性。

彈性伸縮與每天，每周或每年固定的伺服器使用周期不同，它可以響應實際的使用模式，從而減少了因流量負載而配置的伺服器太少或太多的潛在弊端。例如，如果流量通常在午夜時分較低，則靜態伸縮方案可能會將某些伺服器安排在夜間休眠，但這可能會導致在使用者碰巧在夜間需要使用服務時（例如由於病毒性傳播的新聞）出現宕機。與之相度的，彈性伸縮可以更好地應對預期外的流量高峰。

## 術語

在下面的列表中，我們使用亞馬遜雲計算服務提供的術語. 但是我們會標註出術語的別名，並且不會使用特定於Amazon服務名稱的術語。

名稱(AWS 的名稱)｜含義｜別名 (Google Cloud Platform, Microsoft Azure, 或其他平台)

實例｜屬於伺服器組的一部分的，用於彈性伸縮的單個伺服器或電腦

彈性伸縮組｜具有自動伸縮功能的實例的集合以及所有相關的策略和狀態資訊｜託管實例組 (Google Cloud Platform)

尺寸｜當前屬於彈性伸縮組的實例數

所需容量（或所需大小）｜彈性伸縮組在任何給定時間點應具有的實例數。如果尺寸小於所需大小，則彈性伸縮組將嘗試啟動（設置和追加）新實例。如果尺寸大於所需大小，則彈性伸縮組將嘗試刪除（分離並終止）實例

最小尺寸｜系統允許的實例數的最小值

最大尺寸｜系統允許伸縮的實例數最大值

測量指標｜與彈性伸縮組關聯的度量（例如CPU利用率，記憶體使用，網路使用），會定期生成時間序列的數據點。可用於設置伸縮策略的指標閾值。指標可以是彈性伸縮組實例指標的匯總，也可以是和伸縮組關聯的負載均衡的指標。

伸縮策略｜用於指定彈性伸縮組的所需容量（或其最小和最大值）的更改，以響應超過特定閾值的指標的策略。擴容策略可以具有關聯的冷卻時間，這可以防止在特定擴容操作之後立即發生其他擴容操作。對所需容量的更改可以是增量的（增加或減少一個特定的值），也可以指定所需容量的新值。增加所需容量的策略稱為「向外擴展」或「擴大」策略，而減少所需容量的策略稱為「向外擴展」或「縮小」策略。

健康檢查｜自動伸縮組確定與其連接的實例是否正常運行的一種方法。運行狀況檢查可以基於實例是否仍然存在並且可訪問，也可以基於實例是否仍在註冊並在關聯的負載均衡器中使用。

啟動配置｜啟動新實例時使用的參數和腳本的描述。這包括實例類型，購買選項（例如，在AWS中為現貨或按需購買），可能的啟動可用區域，機器映像以及在啟動時運行的腳本。｜實例模板 (Google Cloud Platform)

手工伸縮｜手動執行的伸縮操作。

按計劃擴展｜在特定時間執行伸縮操作的策略。比如，每天執行，每月執行，沒年執行。更多請查看 #Scheduled scaling

## 實踐

### 亞馬遜雲服務 (AWS)

亞馬遜雲計算服務在 2006 年 8 月啟動了 亞馬遜彈性計算雲 (EC2)，來允許開發人員編程啟動和結束實例（機器）。在最初啟動時，AWS不提供自動縮放功能，但是通過編程方式創建和終止實例的能力使開發人員可以靈活地編寫自己的代碼以進行自動伸縮。

從 2008 年 4 月開始，AWS 的第三方彈性伸縮軟體開始出現。這其中包括 Scalr 和 RightScale。RightScale 被 Animoto 使用，從而能應對 Facebook 的流量伸縮。

2009年5月18日，作為Amazon Elastic Compute Cloud的一部分，Amazon 推出了自己的彈性伸縮功能以及 Elastic Load Balancing。現在，自動縮放是Amazon EC2產品不可或缺的組成部分。Amazon Web Services 上的自動縮放是通過Web瀏覽器或命令行工具完成的。2016年5月，AWS ECS服務中也提供了自動伸縮功能。

影片點播提供商Netflix記錄了他們在Amazon Web Services中使用自動縮放功能來滿足其高度可變的消費者需求的情況。他們發現積極地擴大規模，延遲和謹慎地縮小規模最能實現其正常運行時間和響應能力的目標。

在描述 TechCrunch 的文章中, Zev Laderman, Newvem（一個用來優化 AWS 雲基礎設施的服務）的聯合創始人， CEO 推薦說在項目起步階段使用彈性伸縮是他們的花費保持在較低的水平。

各種適用於AWS的最佳實踐指南都建議即使在負載不變的情況下也要使用其自動縮放功能。這是因為自動縮放具有另外兩個優點：自動替換由於任何原因（例如硬體故障，網路故障或應用程式錯誤）而變得不正常的任何實例。並且自動替換因價格或容量原因而中斷的競價型實例，這使得將競價型實例用於生產目的更加可行。Netflix的內部最佳實踐要求每個實例都在一個彈性伸縮組中，並且其一致性猴子（Netflix 內部的測試工具）會終止不在自動伸縮組中的所有實例，以實施此最佳做法。

### 微軟的 Windows Azure

2013年6月27日，微軟 公布其 Windows Azure 雲計算平台支持彈性伸縮功能。文檔可參考 微軟開發者網路.

### 甲骨文雲

Oracle Cloud Platform 允許伺服器實例通過定義自動擴展規則自動收縮或擴展集群。這些顧澤主要利用 CPU 和記憶體的利用率來決定何時增加和刪除節點。

### 谷歌雲平台

2014年11月17日，Google Compute Engine 發布了貪生伸縮的 beta 版本試用功能。As of March 2015, the autoscaling tool is still in Beta.

### Facebook

在2014年8月的部落格文章中，一位Facebook工程師透露，該公司已開始使用自動縮放功能以降低能源成本。部落格文章報導了在低流量時間（午夜左右）能耗下降了27％，在典型的24小時周期內能耗下降了10-15％。

### Kubernetes 水平 Pod 伸縮器

Kubernetes Horizontal Pod Autoscaler 自動的調整 pods 在 replication controller , deployment 或 replicaset 中的數量。調整主要基於對 CPU 的監控(其 beta 版也可以監控其他一些指標 application-provided metrics )

## 可選的彈性伸縮決策方案

默認情況下，自動縮放使用``被動決策方法來處理流量縮放：縮放僅響應於度量標準的實時更改而發生，在某些情況下，特別是當更改發生得很快時，這種被動縮放方法是不夠的。下面介紹了另外兩種自動縮放決策方法。

### 按計劃擴展方案

這是一種自動縮放的方法，其中在一天的特定時間更改自動縮放組的最小大小，最大大小或所需容量。例如，如果已知流量負載在 一天中的特定時間，但是更改太突然了，以至於基於響應式方法的自動縮放無法足夠快速地響應.AWS自動縮放組支持計劃的縮放。

### 預測性彈性伸縮

這種自動縮放方法使用predictive Analytics，其想法是將最近的使用趨勢與歷史使用數據以及其他類型的數據結合起來，以預測將來的使用情況，並根據這些預測進行自動縮放。

Netflix發現，對於部分基礎架構和特定的工作負載，其預測分析引擎Scryer比Amazon的反應式自動縮放方法提供了更好的結果。它特別適合以下場景：

- 在不久的將來識別需求的巨大峰值，並提前一點準備好產能
- 處理大規模中斷，例如整個可用區和區域的故障
- 處理可變的流量模式，根據一天中不同時間的典型需求水平和變化率，在橫向擴展或縱向擴展速率上提供更大的靈活性

在2018年11月20日，AWS宣布將在其自動擴展產品中提供預測擴展功能。