Azure國際企業帳號 Azure 開戶後的主機擴容教學

前言：開戶之後，你的「主機」真的夠用嗎？

Azure 開戶的那刻，心情通常會像剛搬進新家：燈亮了、水來了、雲也看起來很乾淨。但接下來的現實往往是——使用量開始增加、服務變慢、CPU 不爽、磁碟也開始抱怨：「我只是個磁碟，不是許願池！」

這時候你就會需要「主機擴容」。但問題是：Azure 擴容到底要擴什麼？是擴 VM？擴磁碟？擴網路？還是擴整個架構？

放心，本文用最實務的方式帶你做一次完整教學：從確認現況、選擇擴容策略，到實際操作、驗證與回滾。你不必成為雲端魔法師，但你會變成「擴容小隊的指揮官」。

擴容前先做一件事：確認你到底在擴什麼

很多人一聽到擴容，腦中就浮現「把規格拉高就好」。是沒錯，但「拉高」可能拉在不同地方：CPU、記憶體、磁碟效能、或是服務的整體承載能力。

先用以下問題快速盤點：

• 你是因為 效能不足（CPU/記憶體飽和、延遲變高）才需要擴容？
• 你是因為 儲存瓶頸（磁碟 IOPS/延遲高）才需要擴容？
• 你是因為 連線量增加（並發、吞吐）才需要擴容？
• 你是因為 可用性需求（避免單點）而需要調整架構？

簡單說：先確定瓶頸在那裡，擴容才能有效，不然就會變成「把車換大輪胎，但方向盤還卡住」。

進入正題：你應該知道的 Azure 擴容類型

Azure 常見擴容方式可以用兩個字概括：垂直與水平。

1）垂直擴容（Vertical Scaling）— 把主機變更大隻

通常指的是調整 VM 的大小（例如從 B 系列換到 D 系列、或提升 CPU/記憶體）。優點是：

• 操作相對直觀
• 程式通常不需要大改

缺點是：

• 可能需要重新開機（視情況）
• 終究會有上限，長期可能不是最經濟的方案

2）水平擴容（Horizontal Scaling）— 再加幾台，讓工作分散

通常指增加 VM 數量、或配合負載平衡器/自動擴縮。優點：

• 可擴到更大的規模
• 容錯更好（其中一台掛了，其他頂上）

缺點：

• 通常需要更完整的架構設計（例如無狀態服務、共享儲存或資料庫策略）
• 設定相對多步驟

實作前的準備：擴容不是魔法，是工程

你在操作擴容前，建議先做以下「低成本保命措施」。

1）確認你有什麼服務類型

Azure國際企業帳號 你現在的主機是：

• 一般 VM（Windows/Linux）？
• 還是 Azure 虛擬機擴展集（VM Scale Set）？
• 或你的服務是容器（AKS/Container Apps）？

本文主軸以「一般 VM 為例」講垂直擴容，同時也會在後面提到水平擴容的方向，讓你至少知道下一步怎麼走。

2）備份與變更計畫

你不需要一天內做完所有事情，但你至少要知道：

• 擴容是否會導致短暫中斷？（可能）
• 你是否有可回復的方法？（例如 VM snapshot、或磁碟快照）

把它想成搬家：要不要打包？你當然可以不打包直接搬，但如果東西掉在地上你就會開始後悔。工程人永遠要有「後悔預防針」。

Azure國際企業帳號 第一種情境：垂直擴容 VM（把主機變更大隻）

下面以 Azure Portal 的常見操作流程為範例。實際按鈕名稱可能因介面版本略有不同，但邏輯一致。

步驟 1：進入你的 VM

登入 Azure Portal 後：

• 找到「虛擬機（Virtual machines）」
• 點選你要擴容的 VM

你會看到 VM 的概覽頁面，通常包含狀態、大小、區域、網路設定等。

步驟 2：查看目前大小與指標

在概覽頁面或「指標（Metrics）」中查看：

• CPU 使用率
• 記憶體（若有啟用監控代理，可能可看）
• 磁碟 I/O 與延遲
• 網路吞吐

如果你 CPU 已經長期滿載，而且延遲明顯上升，垂直擴容通常很對症。

步驟 3：調整 VM 大小（Size）

在 VM 的設定中找到「大小（Size）」或「變更大小」。

然後你會看到可選的 VM 規格清單。選擇時可以這樣想：

• 如果是 CPU 壓力：選更高 CPU/效能的 VM
• 如果是記憶體壓力：選更高記憶體的規格
• Azure國際企業帳號 如果是混合壓力：可以選更均衡的系列

這裡提醒一點：不是所有 VM 系列之間都能隨便互換，有些情況會受限於硬體世代、區域容量等。

步驟 4：處理停機/重開機需求

在變更大小後，系統可能會提示：

• 是否需要停止（deallocate）再調整
• 調整完成後是否自動啟動

你可以用一句話記住：擴容要變更主機硬體，通常就會碰到停機。

因此建議在低流量時段做。你也可以跟你的團隊講清楚：「今晚可能會像電影院放映中突然換機器，請大家忍耐一下。」

步驟 5：檢查磁碟與快取策略（別只看 CPU）

很多人擴容後以為一切會變快，結果發現其實瓶頸在磁碟。

在 VM 的設定中檢查：

• 資料磁碟是否足夠（容量是否快滿）
• 磁碟類型（例如 Standard HDD / Standard SSD / Premium SSD）
• 是否能調整 IOPS（若適用）

如果你的服務是資料庫（例如 MySQL/PostgreSQL/SQL Server），磁碟效能常常是隱藏主因。

第一種情境的延伸：磁碟擴容與效能提升

假設你的 CPU 還沒滿載，但磁碟延遲很高，怎麼辦？把 CPU 再加上去也許不是最划算的解法。

步驟 1：確認磁碟利用率

在 VM 裡面（Windows 或 Linux）查看磁碟剩餘空間與 I/O 狀況，例如：

• 磁碟空間（剩多少 GB）
• 應用是否出現大量讀寫
• 資料庫是否在做大量索引重建、或查詢慢導致大量 I/O

步驟 2：調整資料磁碟大小或更換效能等級

在 Azure 中，對資料磁碟你通常可以選擇：

• 提高磁碟容量（容量不夠就加）
• 提高磁碟效能（提升磁碟類型或 IOPS）

注意：有些變更需要 VM 停機或對應步驟（例如 OS 內需要擴分區）。

這一步就像在餐廳外面加一個出餐窗口：你不是只換招牌就會變快，還要確保內部流程接得上。

第二種情境：水平擴容（加入更多主機，組成團隊）

當你遇到「連線數一直增加」或「服務不能中斷」時，水平擴容通常更符合長期需求。

水平擴容的核心精神是：讓多台主機一起扛，並且讓流量自動分配。

常見做法 1：負載平衡器（Load Balancer）+ 多台 VM

基本概念：

• 建立多台 VM（同一套服務部署）
• 放在負載平衡器後面
• 對外流量由負載平衡器分配

Azure國際企業帳號 這樣其中一台掛了，其他仍可提供服務，系統容錯更好。

常見做法 2：VM Scale Sets + 自動擴縮（Autoscale）

如果你想要「流量大就自動加台，流量小就縮回來」，那 VM Scale Sets + Autoscale 是常見選擇。

你可以設定條件，例如：

• CPU 超過某值，增加 VM
• 延遲或隊列長度超過某值，增加 VM

當然，Auto scaling 的前提通常是你的服務要能水平擴展（例如多台共享資料層或資料能被一致管理）。

擴容後你要做的驗證：別只看「看起來有變快」

擴容做完，不代表你贏了。就像你把主機換更大顆後，還是要驗證「服務真的穩定、資料沒出事、監控沒壞」。

步驟 1：觀察監控指標

至少觀察：

• CPU/記憶體使用率是否下降且趨於穩定
• 磁碟延遲是否下降
• 網站/ API 的回應時間是否改善
• 錯誤率（HTTP 5xx/應用錯誤）是否下降

步驟 2：做功能性測試（最容易被忽略）

你要確認：

• 登入/交易流程是否正常
• 背景任務是否正常（例如排程任務）
• 資料庫連線正常（連線字串、權限、連線池）

很多系統在擴容後不是「會不會跑」的問題，而是「跑了但某個設定沒跟上」的問題。這就像新鞋穿上了，但鞋帶沒綁好走兩步就會開始腳底打結。

步驟 3：做壓測或至少跑一段模擬流量

若你原本遇到延遲或瓶頸，現在你就要確認瓶頸真的被解決。

• 觀察壓測期間的回應時間分位數（例如 p95/p99）
• 觀察資源利用率是否在合理範圍

如果指標改善但仍有少量尖峰，可能要再做更精準的擴容策略（例如改磁碟、調參數、或走水平擴容）。

回滾策略：你要知道「如果不行怎麼辦」

任何變更都可能翻車，重點是你有沒有「翻車就能收拾」的能力。

常見回滾方式：

• 若擴容前有做 VM snapshot / 備份，可以還原
• 如果只是改 VM 大小，可能可以再改回原規格（仍可能需要停機）
• 若是磁碟變更，可能需要在 OS 端調整分區或檢查檔案系統

建議你先把回滾手冊寫在一張紙（或 Wiki），因為真的出事時你不想靠記憶力跟雲端搏鬥。你不是福爾摩斯，你只是工程師。

常見踩坑清單：擴容時最容易遇到的事

下面這些坑，很多人都踩過（包括但不限於我看過的案例），你可以當作「預先通關」。

• 只看 CPU，不看磁碟：結果磁碟延遲仍然高，性能沒有預期提升。
• 忽略停機影響：擴容在高峰時段做，造成服務中斷，團隊火氣上來。
• 擴容後沒有驗證：看似跑起來但指標或功能其實異常。
• 資料庫與應用耦合太深：水平擴容時遇到資料一致性/連線池問題。
• 監控沒有覆蓋：擴容後監控告警仍用舊閾值，導致告警失準或漏報。

如何選擇擴容方案：一句話幫你做決策

給你一個簡單的決策口訣：

• 需求是「短期變快、改動少」：先做 垂直擴容
• 需求是「長期擴到更大、不中斷、可容錯」：做 水平擴容
• 瓶頸在儲存：優先看 磁碟/IOPS/延遲，不要盲目加 CPU

這口訣不是萬靈丹，但足夠你在 80% 的情境下做出正確方向。

結語：把 Azure 擴容做成「可重複流程」

你開戶後的第一個主機，像是第一次踏出海邊：可以游泳，但你要知道潮汐的力量。Azure 擴容也是一樣：你每次做都要能重複、能驗證、能回滾。

如果你照著本文流程走：先釐清瓶頸、再選擴容類型、做必要備份、執行變更、驗證並準備回滾——那你就不是在「賭運氣」，而是在做「可控的工程」。

最後，送你一句很實在的話：擴容不是把主機變大而已，是讓系統變得更穩、更能扛、更不需要半夜救火。

祝你擴容順利，指標好看，告警安靜，錢包也能比較安分。