Azure企業帳號開戶 Azure虛擬機自動擴展配置方法

前言：為什麼需要自動擴展

很多團隊在上雲的早期都會做一件事：先把系統跑起來。等服務穩定後才開始想「如果突然爆量怎麼辦？」或「流量平常很低，能不能少付一點？」自動擴展的價值就在這裡：它把你對容量的直覺，轉成可量化的規則，讓平台在需要時立刻加資源，在不需要時逐步縮回來。

但要把「能自動擴展」變成「擴得對、擴得穩、擴得省」，關鍵不是按幾個按鈕，而是前期設計。指標選錯、閾值設定不合理、部署延遲沒考慮，最後就會出現擴了也救不了、或一直抖動造成成本暴增的狀況。所以本文會以可落地的步驟，帶你建立一套從需求到驗證的完整流程。

第一章：先搞清楚擴展要解決什麼問題

1.1 你要擴的是「容量」還是「效能」

自動擴展通常以「容量變動」來達成效能。也就是：當負載上升，增加實例數；當負載下降，減少實例數。但實際上你的服務可能遇到的是不同瓶頸：

• CPU 長期高：可能是運算型負載，擴 VM 實例數通常有效。
• 記憶體壓力大：擴機器數不一定解決，可能要看是否有記憶體洩漏或需要更適合的映像與參數。
• I/O 或網路瓶頸：擴實例可能改善吞吐，但如果下游儲存/服務本身是瓶頸，仍會卡住。
• 外部依賴慢：例如資料庫或第三方 API 回應慢，VM 數增加未必能降低延遲，反而會放大併發壓力。

因此在設定自動擴展前，先確認你真正要解決的，是「排隊變長」還是「延遲變大」，以及原因是可水平擴展還是需要別的治理。

1.2 你希望怎麼擴：線性、突發、還是保守平滑

擴展策略常見有三種思路：

• 保守：更少的實例變更，避免抖動，但可能在突發時跟不上。
• 即時：更快反應，能在爆量時維持延遲，但需要更合理的預熱與緩衝。
• 混合：平時穩定運行，遇到特定高風險事件才啟動加速策略。

這會直接影響最小/最大容量、冷卻時間（cooldown）、擴展步長（scale out/in 的幅度），以及是否需要多條規則並行。

Azure企業帳號開戶 第二章：理解 Azure VM 自動擴展的核心概念

2.1 VMSS 與自動擴展的關係

Azure企業帳號開戶 在 Azure 上要做到「自動擴展 VM」，通常採用的是 Virtual Machine Scale Sets（VMSS）。它本質上提供一組同構的 VM 模板（Model）與容量管理能力，並能透過自動擴展規則根據指標調整实例數。

換句話說：VMSS 負責「如何批量生成與管理」；自動擴展負責「何時增加或減少」。如果你只有單一 VM，自動擴展就無從談起；如果你有 VMSS 但沒有規則，就只是維持固定容量。

2.2 指標（Metrics）與觸發（Rules）

自動擴展的靈魂是指標與規則。指標可以是 CPU 百分比、平均請求數、或延遲等。觸發通常包括：

• 比較方式：Greater Than / Less Than
• 閾值：例如 CPU > 70%
• 持續時間：例如連續 5 分鐘都超過
• 統計方法：平均值、最大值、或百分位數
• 擴展動作：增加幾台或到某個目標容量

注意：很多團隊只看閾值，忽略「持續時間」與「統計方法」。一個瞬時尖峰可能讓系統擴了又縮，形成抖動；而設定太久又會讓擴展來得太慢。

2.3 Capacity 與調度（Scheduling）

自動擴展不只決定「要不要加」；也要決定「加多少、加多久、何時縮」。常見配置包含：

• 最小實例數：保證服務的基本可用性與預熱能力。
• 最大實例數：避免失控擴張造成成本爆炸。
• 擴展冷卻時間：避免上一輪還沒完成就觸發下一輪。
• 擴展步長：加台數太大可能造成瞬間資源浪費。

你需要把這些和你的部署時間、連線建立時間、以及應用啟動時間對齊。否則就會出現「規則已經要擴了，但新 VM 還在啟動，流量早就已經堆爆」的情況。

第三章：規劃自動擴展的指標與閾值

3.1 選指標：CPU 不一定是最好的答案

Azure企業帳號開戶 CPU 指標容易拿，也最常見，但不是每個系統都適合以 CPU 作為核心依據。建議你從下面幾層去思考：

• 是否是 CPU bound？如果應用大量運算，CPU 高時擴展更有意義。
• 是否有隊列？例如訊息處理系統，隊列長度（或延遲）通常比 CPU 更直接。
• 是否有明確的 SLO？例如 95 分位延遲、錯誤率。當這些接近門檻時再擴，往往更貼近業務。
• 是否受限於下游？若下游資料庫是瓶頸，擴 VM 只會增加併發壓力，甚至讓錯誤率上升。

實務上常見做法是「一主一輔」。例如以請求併發或隊列長度作為主要觸發，再用 CPU 做輔助，避免某些情況下 CPU 低但延遲已經高的盲區。

3.2 閾值與持續時間：用歷史資料校準

如果你完全憑感覺設閾值，通常要反覆調參。更穩的方法是先看歷史負載曲線：

• 找出負載變化的典型區間：平峰、尖峰、極端峰。
• 觀察在負載上升時，延遲或錯誤率何時開始惡化。
• 以惡化點附近回推合理閾值，並留出緩衝。

持續時間同樣重要。短到 1 分鐘可能太敏感；長到 20 分鐘又可能反應不及。通常建議從 3 到 10 分鐘的區間嘗試，配合冷卻時間調整，讓整體行為更平滑。

3.3 避免抖動：設定合理的縮容條件

擴容通常比縮容更「安全」，因為你擴多一點，至少先把請求接住；但縮容太快容易觸發再次擴容，形成振盪。縮容規則要更保守一些：

• 縮容閾值可以設得低一些，例如 CPU < 40% 才開始縮。
• 縮容持續時間可以更長，例如連續 10 分鐘低於門檻才縮。
• 使用冷卻時間避免頻繁變更。

你也可以考慮分級策略：小幅縮容、小步回到安全區間；等負載真正穩定後再進一步調整。

第四章：建立 VMSS 與自動擴展配置的落地流程

Azure企業帳號開戶 4.1 前置準備：映像、初始化與健康檢查

自動擴展的速度，取決於新實例從「被建立」到「能接流量」的時間。這段時間通常包括：

• VM 建立與網路啟動
• 系統啟動與必要套件安裝（若使用自動安裝腳本，時間會拉長）
• 應用部署與初始化
• 健康檢查通過

因此你要做到兩點：第一，盡量讓 VM 的啟動過程可預期、可重複；第二，健康檢查要能真正反映「這台實例已能服務」。若健康檢查過於寬鬆，流量可能被送到尚未準備好的實例；若過於嚴格，擴容會因為健康檢查通過慢而延遲。

4.2 設定最小/最大容量與擴展上限

最小容量決定可用性與冷啟動成本。最小值太低，流量一來就要擴；而擴的成本包括部署時間，也包括新實例尚未就緒前的服務品質下降。

最大容量則是成本的安全欄杆。你要先估算在最壞情況下可承受的成本或資源上限，並把最大值設在合理範圍。很多事故不是因為規則完全失效，而是最大值沒有設，導致突發流量讓成本失控。

4.3 建立自動擴展規則：兩條以上更常見

常見配置會包含至少兩種規則：

• 擴容規則（Scale Out）：例如 CPU 平均 > 70%，持續 5 分鐘，增加一到兩台。
• Azure企業帳號開戶 縮容規則（Scale In）：例如 CPU 平均 < 40%，持續 10 分鐘，減少一台或恢復到目標。

如果你的應用是跨層的，建議增加第三條「防護規則」：當錯誤率上升或延遲超過門檻時，採用較快的擴容節奏。但注意錯誤率可能是下游引起，如果下游不可水平擴展，這條規則可能需要更仔細的驗證。

4.4 擴展動作與部署時間：把冷卻時間設在正確位置

自動擴展的冷卻時間（cooldown）要覆蓋一次完整擴展的「建立與可服務」時間。假設你的新 VM 從啟動到健康檢查通過平均需要 6 分鐘，冷卻時間如果只設 3 分鐘，下一次觸發很可能在第一台還沒就緒時就發生。

這會造成容量其實還沒帶來改善，反而讓你繼續加台，形成不必要的堆積。反過來，冷卻設太長又可能錯過第二波負載上升的最佳加速時機。

4.5 與負載平衡的關係：流量導入要可控

擴容不是把 VM 做出來就好，還要確保流量能正確分配到新實例。實務上通常會搭配負載平衡器或應用程式閘道（App Gateway）進行健康檢查與流量分發。

你需要確認兩件事：

• 健康探測對應正確的路徑與條件：例如返回 200 且包含必要初始化完成標記。
• 新實例加入節點的節奏：不要讓它在未 ready 前就承接流量。

當這兩點做好，自動擴展才會像你預期的那樣「擴了就立刻改善延遲」。

第五章：用實例說明一套合理配置（可自行套用）

5.1 假設情境

假設你有一個 Web API，使用 VMSS 提供多實例服務，並有基本的健康檢查。你觀察到：

• 平峰流量：CPU 約 20%~35%，延遲穩定在 100ms 左右。
• 尖峰流量：CPU 會在 5~8 分鐘內升到 70%~85%，延遲開始爬升到 250ms。
• 回落：CPU 會在 10 分鐘內降到 30%~45%。
• 平均新實例就緒時間（健康檢查通過）：約 6 分鐘。

Azure企業帳號開戶 5.2 建議的容量與規則（示例）

你可以先設定：

• 最小實例：2
• 最大實例：10
• 冷卻時間：10 分鐘
• 擴容步長：增加 1 台（或最多 2 台，依你壓力承受能力）
• 縮容步長：減少 1 台

規則可以先採用「CPU 為主」的版本：

• Scale Out：CPU 平均 > 70%，連續 5 分鐘 → +1 台
• Azure企業帳號開戶 Scale In：CPU 平均 < 40%，連續 10 分鐘 → -1 台

如果你有隊列或延遲指標，也可以補一條：

• 快速擴容（備援）：延遲（例如 95 分位）> 門檻 且持續 3 分鐘 → +1 台

這種設計的邏輯是：平時靠 CPU 維持；但當 CPU 沒那麼高、卻已經出現延遲惡化時，啟動備援規則。

5.3 為什麼這套配置比較穩

冷卻時間 10 分鐘能涵蓋新增實例就緒的 6 分鐘，避免擴容一波接一波；縮容持續時間 10 分鐘則讓縮容更保守，不容易在負載回落初期就縮過頭。最大值 10 形成成本上限，避免極端情境失控。

當你真的進行壓測或觀察時，如果發現「擴太慢」，你再調整延遲指標或縮短 Scale Out 的持續時間；如果發現「擴太敏感導致抖動」，你就提高 CPU 閾值、或延長持續時間。

第六章：監控、驗證與迭代調參

6.1 自動擴展不等於免運維

自動擴展讓系統更能自我調節，但不代表你可以不看。至少要建立三層監控：

• 擴展行為監控：實例數變更是否符合預期、擴縮容次數是否過多。
• 應用健康監控：健康檢查通過率、錯誤率、延遲分布。
• 成本與資源監控：擴到上限的次數、最高實例數出現的比例。

特別是擴縮容行為，如果你看到「每隔幾分鐘就擴一次」這通常代表規則沒有穩定在合理區間。

6.2 如何做驗證：從小流量開始，再做受控尖峰

驗證建議分三步：

• 基準：保持低於閾值的負載，確認不會誤觸發擴容。
• 緩升：逐步提高負載到接近閾值，觀察延遲何時開始惡化、規則何時觸發。
• 受控尖峰：模擬真實尖峰，觀察擴容到達後延遲是否下降，以及縮容是否在負載回落後逐步恢復。

如果尖峰期間新實例就緒後延遲沒有改善，問題可能不是實例數不足，而是下游瓶頸、快取策略、或連線資源耗盡。

6.3 常見問題與對策

• 擴了但沒變好：檢查下游是否瓶頸（資料庫連線池、第三方 API 限流），也檢查是否存在共享資源爭用。
• 頻繁擴縮抖動：提高縮容持續時間、拉開擴容與縮容閾值差距，調整冷卻時間。
• 擴容來不及：檢查新實例就緒時間是否過長（初始化腳本、映像大小），或負載導入策略是否過早。
• 資源跑到上限：重新評估最大容量是否足夠，或把觸發條件改成更早或更快的策略（例如加入延遲指標的快速擴容規則）。
• 成本爆表：核對最大實例數與自動擴展上限，並檢查是否有其他規則疊加造成連鎖擴張。

第七章：最佳實務（讓配置更長期可維護）

7.1 把規則做成可讀的「策略文件」

很多團隊最後不是技術失敗，而是「沒有人知道當初為什麼這樣設」。你可以用簡單的文字把策略記錄成：

• 我們選的指標是什麼？為什麼？
• 閾值與持續時間的依據是什麼（大致基於哪些歷史觀察）？
• 冷卻時間與就緒時間如何對齊？
• 最大值的成本估算範圍是多少？

這會讓後續調參更快，也能降低交接成本。

7.2 讓映像與初始化可控：減少「擴容後才痛」

若你在 VM 啟動後才做大量安裝與配置，擴容會變成「延遲被放大」。最好是把常用依賴固化在映像或採用快速部署流程。至少要確保應用啟動與健康檢查通過時間在可預期的範圍內。

7.3 以服務品質指標驅動，而不是只看資源

CPU、記憶體當然重要，但真正影響用戶體驗的是延遲與錯誤率。當你的系統成熟後，可以逐步把規則從單一資源指標，提升為更貼近 SLO 的組合。

例如：延遲惡化優先擴容；錯誤率上升先檢查下游或啟用更保守的策略；隊列積壓則啟動擴容。這種從「資源」走向「服務品質」的演進，通常能讓自動擴展更準。

結語：把自動擴展做成系統的一部分

Azure 虛擬機自動擴展不是單次設定任務，而是一個持續調整的過程。你需要先理解瓶頸與可水平擴展性，再選擇合適指標與觸發條件，最後用監控與受控驗證把行為校準。當你把冷卻時間、就緒時間、健康檢查和流量導入一起納入設計，自動擴展就能從「看起來能用」變成「穩定可靠，且成本可控」。

Azure企業帳號開戶 如果你願意從最小可行版本開始（先用 CPU 或延遲指標建立一套保守規則），再逐步用歷史資料與壓測調參，通常可以在不大幅增加複雜度的前提下，快速收斂到滿意的效果。下一步就該做的是：記錄你的指標選擇理由、校準閾值、並持續觀察擴縮容頻率與服務品質的關係。