Auto Scaling

Auto Scaling 自動擴增 ，到底需要這個東西做什麼呢?

我們講講實際案例，流量這東西不是一開始就這麼多的。

當可預期的流量增加，你可以提前增加硬體的，但是當不可預期的流量增加，你要怎麼做呢?

而且可預期的流量也不是一開始就可以預期的，而是服務上線一陣子才會發現流量的規律。

所以一開始，我們就買一個超強的機器! CPU 用最好、RAM 開最高，讓它能夠處理所有的任務。

但是呢....實際狀況是機器一開始就開很大....成本太高，而且這個服務根本才剛起步，會成功還是失敗也說不一定，導致一開始就太多閒置資源 或許可以拿去挖礦? 。

機器開太小，服務開始變慢，使用者體驗變差，跟著也就流失用戶、流失商機。

那如果有個能 依據實際的 CPU、RAM 的使用量來自動增加處理效能 ，豈不美哉~

換句話說，Auto Scaling 就是協助自動增減 Instance 工具。

AWS 很多服務都有支援 Auto Scaling，以下我會針對 最常使用的 EC2 Auto Scaling 來做說明。

EC2 Auto Scaling

EC2 的 Auto Scaling 分了以下三個部分:

• Auto Scaling Group

  • 會自動增長 EC2 Instance 的群組

• Launch Template / Launch Configuration

  • 啟動範本跟啟動組態

• Scaling Policy

  • Instance 擴增、縮小的條件

建立 Auto Scaling Group，都必須指定Launch Template 、 Launch Configuration 或 EC2 Instance。

使用 EC2 Instance 建立 Auto Scaling Group 時，Amazon EC2 Auto Scaling 會自動建立 Launch Configuration，並將其與 Auto Scaling Gruop 建立關聯。

AWS 官方強烈建議使用 Launch Template

不要再使用 Launch Configuration！因為 Launch Configuration 不提供 Amazon EC2 Auto Scaling 或 Amazon EC2 的完整功能。

AWS 的官方部落格在 2021 年 10 月宣布之後不再提供更新，請 參考

Launch Template / Launch Configuration

Launch Template 和 Launch Configuration 是 Auto Scaling 群組用於啟動 EC2 Instance 設定檔。

可以指定執行個體的資訊，包括 Amazon Machine Image (AMI) 的 ID、執行個體類型、金鑰對，一或多個安全群組。

Launch Template 和 Launch Configuration 的 差異 在於以下:

• Launch Configuration 一旦建立後就不能修改它，若要變更 Auto Scaling Group 的啟動組態，只有建立另外一個新的並且更新 Auto Scaling Group 才能解決。
• Launch Template 擁有版本控制，可以有多個版本可以創建完整參數集的子集，然後重用它來創建其他模板或模板版本。
• Launch Template 具備最新功能和改善項目。

建議使用 Launch Template 取代 Launch Configuration 的功能

Scaling Policy

Instance 擴增、縮小的條件，以下幾種常見的情景會對應到不同的解決方式:

• 情境1 - 服務很重要，確保一定會有機器可用
  • 目標在於 維持固定數量 ，可用 Maintain Size
• 情境2 - 在固定時段機器流量會增加或是這段時間會跑每日的排程
  • 在固定時間內增加機器，其他時間就減少至穩定數量，可用 Schedule Scaling
• 情境3 - 不確定的流量或是 CPU 、 RAM 使用率突然增加
  • 依據一些效能指標來判斷，有以下三種可以使用: Simple Scaling 、 Step Scaling 、 Target tracking Scaling
  • Simple Scaling 是依據指標設定閥值，超過閥值就增加機器，低於閥值就減少機器。
  • Step Scaling 是依據指標設定級距逐步增加 Instance。例如 CPU 達 40 % 增加 1 個 Instance，達 80 % 在增加 1 個 Instance。
  • Target tracking Scaling 為 ELB 設置的一系列 Target 追蹤技術，可指定 Amazon CloudWatch 中的指標設定理想的平均使用率或輸送量水平的目標值。例如: 建立平均 CPU 使用率目標為 50% ，讓整個 EC2 Auto Scaling Group 的 Instance 保持在 50% 左右，不管在處理尖峰流量或是平時的流量都不會有過多的閒置資源。

水平擴充能力 & 垂直擴充能力

「水平擴充能力」（horizontal scalability）與「垂直擴充能力」（vertical scalability）

垂直擴充能力，就是個體能力值上升，但是總體數量不變。

水平擴充能力，就是個體能力值不變，但是總體數量上升。

舉例來說:

​ 垂直擴充就是增加伺服器的 CPU 或是 RAM 。

​ 水平擴充則是多一台 Server 來分擔原本的工作量。

我們就已資料庫來說好了，資料庫在日常作業中最常用到無非兩種: 讀、寫。

如果實際情況是 讀的情況比較多的話，應該使用垂直擴充 。

如果實際情況是 寫很多的比較多的話，應該使用水平擴充 。

以下是我從 w3c 菜鳥教程 節錄的。

【讀操作擴充套件】

如果你的系統讀操作非常多，那麼通過關係型資料庫如 mysql 或者 postgresql 來垂直擴充套件資料儲存是一個不錯的選擇。結合你的關係型資料庫通過使用 memcached 或者 cdn 來構建一個健壯的快取系統，那麼你的系統將非常容易擴充套件。在這種模式中，如果資料庫超負荷執行，那麼將更多的資料放入快取中 來緩解系統的讀壓力。當沒有更多的資料往快取中放時，可以更換更快的資料儲存硬體或者買更多核的處理器來獲取更多的執行通道。摩爾定律使通過這種方法來垂 直擴充套件變得和購買更好的硬體一樣簡單。

【寫操作擴充套件】

如果你的系統寫操作非常多，那麼你可能更希望考慮使用可水平擴充套件的資料儲存方式，比如 riak，cassandra 或者 Hbase。和大多數關係型資料管理系統不同，這種資料儲存隨著增長增加更多的節點。

由於你的系統大部分時間是在寫入，所以快取曾並不能像在讀操作比較頻繁的系統中起到那麼大作用。很多寫頻繁的系統一開始使用垂直擴充套件的方式，但是很快發現並不能根本解決問題。為什麼？

因為硬碟數和處理器數在某一點達到平衡，在這個邊界上再增加一個處理器或者一個硬碟都會是每秒鐘的 i/o 運算元呈指數性增長。相反，如果對寫頻繁的系統採取水平擴充套件策略，那麼你將達到一個拐點，在這個拐點之後如果在增加一個節點都遠比使用更多的硬碟來的實惠。

現在雲服務只有是有關 彈性調整的服務大多都使用水平擴充 。

是不是真的需要自動調整資源的分配真的是看服務實際的策略。

不需要一次開太多浪費錢，但是也不能降低服務的可用性 ，這才是彈性調整的本意。

參考資料

• w3c菜鳥教程。理解水平擴充套件和垂直擴充套件
• What is the difference between AWS ASG Launch Templates and Launch Configurations?