# 到底雲端平台的 PaaS 環境提供的 Auto Scaling 功能應該給予什麼樣的期待

本週 [Microsoft Build Cloud Skills Challenge](https://aka.ms/buildCSC?WT.mc_id=DT-MVP-4015686) 正式開賽，我在參加 [Azure Developer Challenge](https://learn.microsoft.com/en-us/learn/challenges?id=b1ac64ec-f0d3-45fa-beee-f230f9a75e81&WT.mc_id=DT-MVP-4015686) 的時候，有個 [Scale apps in Azure App Service](https://learn.microsoft.com/en-us/learn/modules/scale-apps-app-service/?WT.mc_id=DT-MVP-4015686) 模組最後的[知識檢定](https://learn.microsoft.com/en-us/learn/modules/scale-apps-app-service/6-knowledge-check?WT.mc_id=DT-MVP-4015686)提到了一個有點爭議的問題，它提到在哪種情境下適合使用 PaaS 的自動調整功能(Auto-scaling)，答案值得讓人深思！

![PaaS](https://stwillblogassets.blob.core.windows.net/files/images/external/user-images.githubusercontent.com/2003bbfd52c57877672c-170651520-f2e3f620-95ad-4983-a160-aebbbbe70cef.jpg)

原始的題目是這樣的：

![2022-05-27\_13-01-28](https://stwillblogassets.blob.core.windows.net/files/images/external/user-images.githubusercontent.com/a330b34fe5b3b8f7ee8f-170632968-36aa7392-223f-46ea-a0e7-b178ed3bdb43.jpg)

我來簡單翻譯一下：

```
2. 以下哪種案例適合使用自動調整？

    [ ] 需要存取應用程式的使用者人數會隨著規律的排程而變化。例如：週五使用系統的使用者人數比其他時間更多。

    [ ] 系統偶爾會受制於突然蜂擁而至的要求，這會導致系統當機。

    [ ] 您的組織正在執行一些行銷活動，你可以預期接下來幾週網站流量都會增加。
```

我們想要採用 PaaS (Platform-as-a-Service) 的一個很重要的理由，就是想要降低平台的管理負擔，然而當流量忽大忽小的時候，能夠提供一種「自動調整」或「自動延展」的機制 (Auto-scaling)，那就真的是太完美了，不是嗎？我們如果基於這樣的「期待」來思考問題，那麼這三個選項照理來說都應該是「正確答案」才對，是吧？

因此我在作答這個問題時，便進行了一場相當深層的思考，我想著「我原本對 PaaS 的理解或期待有問題嗎？」

接著我們來抽絲剝繭一下這題的三個選項，因為這三個選項似乎都有可能是**正確答案**。

1.  需要存取應用程式的**使用者人數**會隨著**規律的排程**而變化。
    
    這句話的重點在「規律的排程」，也就是在「已知的」流量增長情境下，可以透過「自動調整」改善流量暴增與資源不足等問題。
    
2.  系統偶爾會受制於**突然蜂擁而至的要求**，這會導致系統當機。
    
    這句話的重點在「突然蜂擁而至的要求」，也就是在「未知的」流量增長情境下，可以透過「自動調整」改善流量暴增與資源不足等問題。
    
3.  您的組織正在執行一些行銷活動，你可以預期**接下來的幾週**網站流量都會增加。
    
    這句話的重點在「接下來的幾週」，也就是在**一段時間內**「已知的」流量增長情境下，可以透過「自動調整」改善流量暴增與資源不足等問題。
    

我先說正確答案是 1️⃣，至於為什麼，請繼續看下去！

首先，大家還是要有一個觀念，無論是**雲端**還是**地端**，都需要有「伺服器」才能運作，一定會有硬體的基礎建設，才能夠在網路上提供服務。而當你在使用 PaaS 提供的各項資源時，雲端平台會幫你對這些資源進行管理，因此你可以在既有 PaaS 提供的平台下進行應用程式開發，大幅減少管理維護的成本，也可以透過平台提供的 API 自動化許多部署工作。

在**地端**實現「自動調整」不是一件很容易的事，除了要管理 IT 基礎建設外，還要設計許多自動延展的機制，還要確保**高可用**與**負載平衡**，有非常多工作要做，而且**預留硬體資源**也是一個**不小的成本**。

在**雲端**實現「自動調整」就顯得非常輕鬆自在，你完全不用擔心 IT 基礎建設，也不用花任何一毛錢在還用不到的預留資源上，當流量來的時候，可以設定一些觸發條件，自動取得所需的資源，讓網站可以順利的負擔突如而來的流量。但是各位也不要忘記了，使用雲端的 PaaS 服務，這些工作雖然不需要你費心思設計，但是任何一家雲端業者也不會預先幫你準備好可用的資源 (除非你花錢保留)，**任何資源的準備**都是需要**時間**的。所以這裡的重點，就是在「**時間**」二字！

> 換句話說，實現「自動調整」最主要的目的就是「將費用花在刀口上」，簡單來說就是為了要「省錢」，沒有別的了！

這個問題的三個選項，我認為真正的亮點，就在於你在「希望省錢」的前提下對「時間」的期待為何？我們在不同的情境下，對於「時間」的需求都不太一樣，但唯一不變的需求，就是**絕對不能花錢在用不到的東西上**，對吧！ 😄

接著我們重新檢視一下這題的三個選項：

1.  需要存取應用程式的**使用者人數**會隨著**規律的排程**而變化。
    
    我們如果已經知道一個系統會在每個月的第一個上班日，湧入大量的使用者進行操作，這是一個相當「規律」的流量需求，非常容易進行資源規劃。
    
    透過 Azure App Service 的「自動調整」機制，非常容易做到這一點，因為「已知的排程」可以讓我們預先準備好雲端所需的資源，因此流量大的時候，依然是可以預先做好準備的。
    
    因此，這個選項是「正確答案」！
    
2.  系統偶爾會受制於**突然蜂擁而至的要求**，這會導致系統當機。
    
    如果我們無法預知流量何時會進來，準備 Azure App Service 所需的計算資源 (VM Instance) 都需要時間，短則數十秒，多則數分鐘，當你真的有「**突然蜂擁而至的要求**」進來時，我想 PaaS 服務很難可以在短時間內**自動擴展**到可以應付流量，也就是你無法透過「自動調整」機制在「短時間內」改善流量暴增與資源不足等問題，一定會有使用者被影響到！
    
    如果你非常強調一個網站或系統的**高可用性**，PaaS 平台的「自動調整」機制並無法幫助你達成目標喔！（因此這是個不合格的選項）
    
    那該如何解決這個問題呢？當然就是「預先準備好充足的資源」應戰，相對的你就做不到「省錢」這件事，因為你肯定會把錢化在**用不到的資源上**，而這些預留的資源，就是為了應付**突然蜂擁而至的要求**所準備的！
    
3.  您的組織正在執行一些行銷活動，你可以預期**接下來的幾週**網站流量都會增加。
    
    雖然說「**接下來的幾週**」是一個相對上「已知的」流量增長，但事實上卻是一個「**不固定的時間點**」，而雲端平台提供的「自動調整」機制，是在條件觸發的同時才會準備資源給你，幫助你把錢花在刀口上。對於這種**不固定的**流量增長需求，使用「自動調整」機制，很有可能會「來不及」提供足夠的資源因應突如其來的流量，所以這種情境下，就會跟上述第 2 個選項一樣，在時間到的時候，預留足夠的雲端資源才是比較正確的作法。（因此這也是個不合格的選項）
    

以上就是我對這一題的想法，如果你有不同的觀點，歡迎大家留言跟我討論！ 👍