關於自動規模化的迷思

在雲端的時代中，我們可以利用 Auto Scaling（自動規模化）的方式來自動的增加或者減少伺服器的數量。也因此很多人會認為這是一個針對「大流量」的機制，也會把它當作一個解決「突發狀況」的解決方案，然而實際上真的是這樣嗎？

實際上 Auto Scaling 是一種「預算管理」的工具，我們並不能用來解決突然暴增的大流量狀況。

如果有看過設定的面板，會發現大多會採取「臨界值」的方式來處理，像是 CPU（中央處理器）的使用率達到 60% 的時候，在五分鐘內沒有恢復，那麼就增加一台伺服器並且在 30 分鐘後再次檢查。

像這樣的設定，我們透過自動增加一台伺服器去分攤掉運算來緩解「增加的使用量」的情況，利用這樣的特性我們就可以在「尖峰時段」自動的增加機器一兩個小時，等到使用者減少了再減少到維持網站運作的最低數量。

然而，像這樣的運作模式看似可以解決「突發大流量」的狀況，現實層面上更多的是「來不及反應」更多。

Auto Scaling 之所以能做到預算管理，是因為可以根據最近一段時間的「用量」去反映出適合的伺服器數量，然而在「瞬間暴增」的狀況下，只會看到異常的數字，是無法正確反映出瞬間流量的狀況。

這也是為什麼各大企業依然會有 SRE（Site Reliability Engineering，網站穩定性工程）這樣的職位存在，遇到這樣的狀況是要依靠適當的監控機制，由人工的方式來「判斷」調整。

這是因為 Auto Scaling 依然會有「最大值」的限制存在，這也反映著預算的範圍，同時在對應瞬間流量的問題時，我們還需要區分「可預期」和「不可預期」的情況，如果是前者那們勢必會先做好準備，讓使用者完全感受不到卡頓。如果是後者，那麼就是一間公司平常在危機處理、系統架構設計是否完善的考驗，如果都能夠對應，那麼即使是非預期的瞬間流量也不會有太大的問題。

程式本身還是自動化的手段之一，並不存在一種萬用的做法。即使我們的預算無上限可以無限的 Auto Scaling 好了，也還是會遇到「瓶頸」的問題。

舉例來說，資料庫通常是很難擴充的，一但要可以擴充必定會放棄某些優點（例如，區塊鏈儲存是很慢的）在這種狀況下，即使我們可以無限的擴充網站的節點，最後也會讓資料庫無法支撐而停止運作。

也因此，必須要做出取捨。是要放棄資料的「正確性」來強化資料庫的能力，還是進行限流讓使用者無法對系統造成這麼大的壓力。如果有體驗過演唱會搶票或者購物節，常常會突然多出名額或者必須等待，都是前述的手段之一。

至於該如何取捨，就要看業務性質跟是否有更好的系統架構設計可以來改善。

封面圖片使用 Unsplash 上 Markus Spiske 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。