台灣的Web工程師

這樣整個看下來，我們的大架構已經很完整了，不但可以分流，而且當其中的服務器有任何問題的話，可以做到Failover（容錯移轉）；並且如果伺服器不足的話，我們可以在短時間內，透過加入新的伺服器來擴大服務，聽起來似乎都很棒了，不過還是有一些可以改善的空間，狀況是這樣的：

當公司活動結束後，雖然因為活動很成功，所以每天連線的人數有慢慢成長，但是因為還不到當初活動的人數，所以有二～三台機器是閒置的。

如果機器是公司自備的，那麼閒置在那裡的話，還算是可以接受；但是如果是買線上服務的話，因為費用計算是根據開機時間的，所以閒置的機器如果開機的話，等於浪費金錢；不過明明連線人數是緩慢上升的，所以本來就預計會用到閒置的機器，不開機的話，當連線人數太多，又怕服務太慢；在這種二難的情況下，多麼希望有一個理想的狀況是：

當連線人數增加時，我們就把機器增加；當連線人數沒那麼多時，我們就把閒置的機器關機，以節省金錢。

多麼理想的狀況，如果能達成的話，那該有多好。實際上真的有這種機制，這種機制的名稱叫做Auto Scaling（自動彈性化）。

Auto Scaling的原理很簡單，就是：

1. 偵測Load Balance控管下的每一台機器的繁忙程度（可能是依據CPU或記憶體）。

2. 如果繁忙程度超過我們設定的上限，並且尚未超過設定的最大機器數，那麼就自動啟動一台機器，並將啟動完成的機器，自動配置到Load Balance下執行服務。

3. 如果繁忙程度低於我們設定的下限，並且尚未達到設定的最小機器數，那麼就關閉最閒的機器，以節省資源。

原理就是這樣而已，但是實作上卻不簡單，不過現在比較大型的網路伺服器商（例如：AWS，Azure，Google Cloud等）都會有這種服務，使用者只需要透過簡單設定即可利用這項服務；而為了使用這種Auto Scaling的功能，我們會有幾件必須先做的事情。

監看程式（Cloud Watch）

因為Auto Scaling必須知道目前伺服器的繁忙程度，所以必須要有可以監看伺服器的使用程度並回報的機制，這整個部份稱為監看程式。

基本上網路服務商都會有這類的功能，並且它可以配合一些已定義好動作，例如：

• 網路平均每分鐘超過多少MB時，寄信給特定人員，或自動將機器關閉（這在測試機上最好設定一下，以免被攻擊後發送大量封包）。

• 是當我的帳單金額超過多少時，寄信給我。

這一類的設定被可透過監看程式來達成，Auto Scaling只是利用了這一類的功能，讓它去監看Load Balance下的所有機器。

Image（映象檔）

Auto Scaling並沒有聰明到可以判斷那一台機器是Master，那一台機器是Slave，所以比較不適合用在伺服器叢集上。所以需要一個簡單的機制：

• 當一台機器被啟動的時候就把所有的服務都啟動，被加入Load Balance後即可使用。

• 當一台機器被關機或刪除（刪除VM）時，也不會影我們的整體架構。

所以我們必須把所有的機器設定好，確認它在開機後，會自動將所有服務啟動並正常運作，之後我們就將該機器做一次備份，將它做成一個映象檔；再指定這個映象檔給Auto Scaling，當Auto Scaling需要加機器時，就可以使用這個映象檔來建立新的機器，建立好機器並啟動後，即可加入到Load Balance做服務。

為了建立這種映象檔，筆者建議當初在選擇伺服器的「共享Session機制」時，選擇以3th Party提供的機制來實現，原因是伺服器的「叢集」都會指定一台機器當Master，其他的機器當成Salve，而所有的Salve機器都需要跟Master註冊，所有的Session的存取，都會跟Master有關係；換句話說，當一台Slave機器啟動時，不是要修改Slave的設定，不然就是要修改Master的設定，這些事情要做成自動化的話，會比較複雜；而如果是以3th Party的機制來實現的話，只要一台設定成功後，做成Image檔，即可直接交由Auto Scaling來複製並啟動，從開機到啟動服務到關機，這中間可以完全不需要人力介入。

下圖是整個完整的大架構：