關鍵詞：AutoScaling、彈性供應組、彈性、低成本、spot

演講嘉賓簡介：賈少天，阿里雲高級技術專家，2010年加入阿里雲，目前專注於ECS彈性體系的建設，通過彈性伸縮和彈性供應組多種方式來滿足用戶彈性同時降成本的需求，幫助用戶在高可用和低成本間找到更合適的解決方案。

以下內容根據演講視頻以及PPT整理而成。觀看回放
更多課程請進入“玩轉ECS詳情頁”瞭解

本次分享主要圍繞以下三個方面：

一、ECS概況

二、彈性伸縮
三、彈性供應

本次分享主要幫助用戶快速瞭解雲上彈性能力和應用方式，同時通過彈性伸縮和彈性供應組多種方式實現成本優化。

一、ECS概況

1.ECS計算產品家族譜

ECS產品是雲服務器產品，具有各種各樣實例規格，不同的實例規格具有不同是適用場景，用戶可通過自身使用的業務場景或是運行內所需性能等方面的考量選擇適合自己的實例規格。針對不同的場景，我們所推薦的實例規格不同，如下圖所示，對比自身業務領域的情況選擇合適的實例規格。

2.ECS付費方式

阿里推出後付費和預付費兩種付費類型。

後付費按照用戶使用情況付費，按量付費是秒級計費方式，使用一秒鐘或一分鐘則收取一秒鐘或一分鐘的費用。搶佔式實例是根據價格的意向來使用ECS，根據市場價格變化或是需求發展變化系統會隨時進行資源釋放，但可以保障用戶最低一個小時的使用，且用戶必須保證業務產品是無狀態業務產品，這樣可以更大程度上降低業務成本。

預付費模式可按月、按年、按周的方式購買實例規格，如果用戶預期兩年內使用阿里雲服務，則可選擇按年方式購買，在年付費方式的基礎上還具有各種各樣的折扣。如果用戶的業務場景預期以周為單位，例如已知下一週有大的負載情況或做一期業務場景活動推廣等，則用戶可按周的方式購買，同時也可按月方式購買，用戶可根據自身的不同業務場景自定義選擇購買方式。

另外在此基礎上阿里還提供了預留實例，預留實例與包年包月相近，可按照年、月、周的方式購買，但該方式不根據資源實例規格長短定，用戶可選擇自身範圍的實例規格在一定週期內使用，是資源與折扣的解耦。

用戶可能會在這些實例規格和付費類型的選擇方面存在各種各樣的問題，不瞭解在什麼情況下選擇最合適的實例規格和付費類型，所以阿里會推薦一種面向業務的最佳實踐。

購買包年包月資源或預留資源可作為基礎業務負載的保證，例如購買二十臺資源作為日常基礎請求量的負載保證，在此基礎上購買按量付費類型來支撐每天負載發生的變化，只要能快速擴容或是負載快速縮容，就可以使用比包年包月更低成本的資源。另外用戶具有無狀態的業務創建，可做到高容錯，可在此基礎上使用Spot扛最上面的高峰值。

希望通過包年包月、按量、搶佔式三種付費類型的結合，讓用戶整體的成本達到最低的同時擁有高質量的服務器。

3.ECS資源彈性交付方式

阿里雲提供四種ECS資源彈性交付方式，Create Instance是最早期提供的單實例支付方式，每次可交付一個實例。隨著業務的發展在此基礎上提供了Run Instances接口，單次可批量交付100+實例，但該支付方式限制單可用區和單實例規格。隨後阿里提供彈性伸縮和彈性供應兩個產品，來幫助用戶解決更加複雜的業務需求。

彈性伸縮是自動化的交付工具，可以一次性批量交付（2000/50000）實例。

如果伸縮組配置的普通安全組，那伸縮組的最大實例數是2000，如果有更多實例的需求的話就需要配置企業安全組，同時一次配置後可重複使用。

另外，該產品支持定時和觸發等功能，例如CPU達到70%時觸發擴容，少於30%時觸發縮容，或是用戶對於自身業務場景非常清楚擴容的時機則可進行主動觸發，預測功能可通過過去使用情況自動預測未來的發展變化，自動進行擴容縮容。

在此基礎上該產品支持多可用區和多實例規格，方便用戶在不同的可用區做高可用甚至提供更多的實例規格使成功率更高。另外還提供了成本優化模式。

彈性供應在原有基礎上提供了交付資源至交付計算力的環節，同時也是ECS原生大規劃交付方式。原先用戶交付1000個實例，現在可以交付1000vCPU或是其他緯度的業務場景，變成一種靈活度很高的產品形態。同產品伸縮相同批量交付實例規格達（2000/50000），以及配置的重複使用。同時也支持按量+Spot+RI的組合。

4.雲上彈性面臨的挑戰

用戶在雲上彈性方面面臨各種各樣的挑戰：

 例如某創業公司在app爆紅後頻繁無法訪問，是由於業務突然大量湧入後業務增添的負擔支撐不住這麼大的壓力；

 或是在線視頻網站每天早八點或中午十二點都會迎來業務的高峰期，而對於如何應對高峰期則可能需要定時的擴容縮容；
 或藝人爆出八卦引發社交用戶的熱議，突然變為之前頻率流量的十倍左右的負載，如何快速解決該類問題的擴容來滿足業務場景；
 或是雙十一大促銷需要臨時擴容時企業如何準備；
 以及業務低谷期也保有全量資源，閒置成本非常高時包年包月成本如何解決。

在雲上很多時候會認為不可同時做到高可用和低成本，如果做到低成本可能顧不到高可用，在後面講師會分享某些場景上可以同步做到高可用和低成本。

二、彈性伸縮

1.彈性伸縮概述

彈性應用的產品應該滿足的業務場景有幾種。首先是傳統模式，會保有一部分資源，但該資源剛好可以扛住平時的高峰期，在低峰期就會形成資源浪費，或是在高分期扛不住，只能扛住業務的平均值時，那麼在高峰期時會無法支持業務導致崩潰或不可用，又或是到一定程度需要擴容時要進行人工擴容，但是需要收容時還需人工自行判斷。所以採用彈性伸縮就會自動根據整體業務負載的情況自動做擴容縮容，保證用戶用最少的資源負載業務整體的變化。

從下圖右邊中可看到關於彈性伸縮整體提供的能力：

伸縮組最大實例數：以組的方式進行管理，最大實例數值為2000/50000。

組合方式：支持五種可用區和十種實例規格提高了整體資源交付的成功率。
三種策略：提供優先級策略、均衡策略及成本優化策略。優化策略是指用戶可設置一批資源，該策略按照每種資源創建的成功率自動判斷每種資源當前交付使用最快最高成功率的方式。均衡策略是指用戶設置多個可用區後，在多個可用區下進行整體均衡的分配，這樣可保證一旦某一個可用區下發現整體不可用時業務依舊可以繼續有效運行。成本優化策略結合Spot+RI場景可幫助用戶在穩定的同時做到低成本。
五種伸縮模式：定時、動態、人工、固定和健康檢查模式。動態模式分為三種：簡單、目標追蹤和預測。簡單伸縮策略可以定義為CPU達到70%時增加五臺，CPU小於20%時減少三臺，用戶可根據自身經驗判斷當天需要擴縮的數量。目標追蹤可定義為整體業務需要保持CPU達到60%，當業務高峰期CPU達到80%時這時系統會自動幫用戶換算具體需要擴容多少資源才能滿足業務不受損，當CPU降到40%或30%時系統會判斷當前整體減少多少資源來保證業務最低運行。預測策略根據過去使用情況來預測未來的使用情況。
通過雲監控實現彈性：支持十七種雲監控指標進行觸發包括ASMA、SLS等。
提供事件通知能力：事中+事後整體的事件訂閱，可保證業務起到全局控制。

2.彈性伸縮核心概念

彈性伸縮的核心概念主要分為四種，如下圖所示。

在伸縮組上設置彈性伸縮配置，例如實例規格種類，整體啟動腳本的樣式，使用登錄方式以及鏡像等，設置完可隨時使用和修改。

在此基礎上設置伸縮規則和通知，伸縮規則是指具體增加多少臺減少多少臺，或者按照目標追蹤的方式設置CPU保持在70%，另外在每次成功或失敗時可以訂閱最終的結果到雲監控或MNS消息隊列中進行編程，來應對每次成功或失敗的結果，裡面會包含成功時擴容多少資源，資源ID是什麼樣的，或者對接到雲監控系統或者釘釘，可以知道導致失敗的原因並快速做出預警進行干預。

伸縮任務具有定時任務，支持一年和臨時提醒功能，在一年期限到達前會及時進行提醒，報警任務涉及到CPU或Memory等，另外伸縮任務還可進行自動或手動觸發。

3.多種伸縮模式

阿里雲彈性計算提供不同的伸縮的規則，對應了不同的伸縮模式，包括：

健康模式：通過健康檢查發現一些不健康ECS實例時會進行自動清理，並創建新實例來替換不健康實例。

固定模式：可設置最大值最小值實例期望數量來保證業務正常運行。
手工模式：用戶如果對自己業務場景有非常詳細的瞭解或自有監控系統時，可通過API方式執行手工模式。
定時模式：例如在線視頻網站每天早八點或中午十二點會迎來業務的高峰期，可以在此期間進行定時擴容，度過高峰期的兩三個小時後再縮容。
動態模式：通過負載變化進行擴容縮容。

4.多種伸縮模式靈活組合

圖片中顯示在不同場景下不同模式的表現。

定時模式是在一個時間點擴容運行幾個小時後再縮容，整體線條是直上直下的。

動態模式是服務器的變化走向是與整體負載環境的變化走向一致，趨向於負載的變化。
手動+動態模式購買包年包月資源作為底座來扛日常業務，高峰期的負載環境變化通過按年的方式擴容縮容來保證，這樣整體穩定性更高，因為已有60%或70%的負載情況被cover，剩下的30%負載情況通過動態的方式cover。
定時+動態模式說的則是例如資源擴容完後可能會發生數量變化，如有新電影或電視劇上映時具有高熱度，此時原先擴容的值會不夠用，則需要通過監控指標的變化在此基礎上進一步擴容。

**動態模式-預測模式
**
預測模式通過過去1-14天的CPU使用情況或實例個數的變化進行建模，通過機器學習預測算法預測未來2天整體的使用情況，並自動進行擴容縮容操作。

此場景適合非常規則的週期性場景，每天的業務在固定的時間點上進行固定變化，圖片中展示的場景就很規律，每天都在固定的時間點周圍進行擴容和縮容，這樣所達到的預測結果會更加準確，所以推薦規則性的場景使用預測模式效果會更好。

該模式好處在於不用感知CPU的設置值，它會自動進行運算並自動判斷多少實例可在此基礎上滿足當前的業務需要，是因為歷史上實際的整體情況已經被納入到所考慮的範圍內。如果用戶某一天做活動或推廣的業務期間突然湧入大量流量時，也可疊加目標追蹤模式，預測模式+目標追蹤模式疊加後在發生變化時可自動感知和擴容，並在此基礎上再進行擴容或縮容，所以頻率性在遇到特殊的抖動或是特殊的變化時是有相關的規避方式的。

5.成本優化方案

前面講解瞭解到阿里雲ECS的多種付費方式以及彈性伸縮的多種策略之後，用戶可以利用這兩種能力來實現成本優化。接下來會講解多種成本優化方案，用戶可根據自身情況自行選擇。

在ECS付費方式中提到了包年包月、按量付費和搶佔式Spot等不同付費類型，這些付費類型可組合成多種成本優化方案。用戶可根據上圖中顯示的六種方案選擇成本最低穩定性更高的使用方式。

然而在方案選擇上阿里平臺則非常推薦A（預付費/RI+按量+Spot）方式，該方式將穩定性和低成本做到相對較好的結合，從上圖右邊圖片中看出A方式的位置在四項中相對較好。但在此基礎上也與其他產品進行了對比，例如B是預付費/RI+按量方式，C是預付費/RI+Spot方式，D是按量+Spot方式，E是全按量方式，F是全Spot方式。

因為Spot場景價格非常低，所以F方式的成本很低，而系統帶來的一些釋放行為，也是導致F方式的穩定性最差的原因。因此希望在F方式的基礎上作出成本更低穩定性更高的使用方式，所以推出了成本優化模式新功能。

F方式（全Spot）在原先全部適用於一種實例規格的基礎上，在此實例規格上做出一些調整，允許實例打散，將多種實例規格組合來滿足資源的交付。下圖中從左邊一種實例規格到右邊多種實例規格混合交付的方式，如果一次性交付是三種或四種，這樣即便有一種實例規格出現問題也不會影響整體使用關聯性。

另外，Spot在此基礎上又提供了提前補償機制，Spot實例在釋放前五分鐘可通過事件示例訂閱此消息，在Spot實例釋放前五分鐘時自動開啟補償機制，知道某些實例被釋放後就開始創建替換實例，創建完後立刻將Spot釋放的實例替換掉，這樣就不會出現圖中左邊斷崖式釋放。否則，在Spot實例釋放完後再重新創建替換實例中間的時間週期會導致一定的抖動，而右邊提前五分鐘在Spot實例還沒有釋放完時新的實例已經創建出來，所以業務上不會出現抖動情況。需要注意的一點是使用Spot實例時一定要保證業務是無狀態的。

6.事件驅動

彈性伸縮提供的事件驅動能力，阿里在提供開放接口（OpenApi）的基礎上又提供事件通知（Notification）和生命週期掛鉤（Hook）的能力。通過這三種方式的結合可以讓用戶擁有更全面控制彈性伸縮組的能力。

關於事件通知和生命週期掛鉤的職能，從圖中可以看到擴容時需要創建資源、關聯RDS白名單、啟動中、運行中、掛載SLB並且最終加入到ESC彈性伸縮組中，而縮容時是從ESC彈性伸縮組挪出、取消SLB掛載、關機、取消RDS白名單、移除最終釋放。

無論是擴容還是縮容最後執行結果時都會有事件通知，該事件通知可以通過事件訂閱，例如MNS消息隊列、CMS雲監控、OOC運維編排方式訂閱信息，然後將信息進行相關處理，可集成到自身系統中待資源成功時添加到系統當中，如果失敗可進行自動化重試。

而生命週期掛鉤在每一次擴容或縮容時會先發出消息，在用戶接受到消息時可以判斷當前這次擴容或縮容能否進行，例如創建實例後在掛載SLB之前會給用戶發送消息，訂閱消息後就可知道當前多少實例創建成功，並通過自身業務場景進行判斷這些實例是否需要繼續往下走，是否需要掛載SLB，是否需要最終交付到彈性伸縮組中。如果不需要，可直接選擇Rollback，這些資源將會自動清理掉，如果需要就繼續往下走最後添加到彈性伸縮組中。

縮容也是同樣，當某些資源需要被釋放時會將消息發送給用戶，提示當前要釋放哪些資源，用戶在獲取到消息後可以進行驗證，看資源上的任務是否進行完畢，是否有數據需要進行同步和備份。

如果任務還未進行完畢時，用戶可以選擇等待或者直接取消，如果所有任務進行完畢且符合預期則可以繼續往下走並進行釋放。

通過生命週期掛鉤能力和事件通知能力可以讓用戶瞭解到一個事件中所有行為的全面感知，這樣無論是自己做業務報警還是系統集成，都擁有更全面的控制能力。

三、彈性供應

1.彈性供應（Auto provisioning）介紹

彈性供應是一種全新算力交付方式，可以整合包年包月、按量和Spot多種能力的付費類型實例，並且跨實例規格族、跨可用區的計算集群交付。

其優勢在於相比以前交付1000資源，現在在彈性供應上交付1000vCPU、交付1000Memory或者用戶自身定義緯度應該交付的資源權重的樣式，按照權重定義資源數量。

圖中顯示可定義當前伸縮組所有資源的比例，如33%按量資源和67%Spot資源，這樣用戶可在整體成本上自行控制，在自身想要的成本情況下來滿足自身業務需要。最終交付的成果如圖A、B、C、D，是多種實例規格多種可用區資源的整體結構。

2.彈性供應的基本組件

目標容量：定義目標容量，可以定義vCPU的維度、實例維度或者其他需要的維度。
實例權重：為每個實例規格都定義自己的權重，如果是按照vCPU維度定義的權重，最終交付的資源整體容量是以vCPU為維度，如果是以用戶自己業務產品計算力或是推出能力去定義，最終的效果就是以自己產品的權重容量交付，此能力最大的好處在於完全依照自身方式去定義期望的結果。
實例優先級：交付實例時可以定義每一種實例先後順序，這樣在創建時可以優先極高的實例。
Instance Pool To Use Count：指在成本優化策略時，可以選擇最便宜的實例規格數量，進行一定程度的多種實例規格打散，在彈性收縮中使用一種Spot實例時有可能出現大面積的Spot資源全部清零的情況，然而現在可以用Instance Pool設定幾種可接觸的最低價的Spot實例數量，例如數量設定為三種時，資源創建的時候救可以選擇最低價的三種Spot實例進行創建，這樣即便出現一種Spot實例釋放也不會導致整體業務受到損失。

3.彈性供應的產品優勢