Microsoft AZ-305: 運算與應用程式架構 — 學習指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

屬於 Microsoft Azure Solutions Architect Expert AZ-305 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

容器與 Kubernetes

Azure Container Instances (ACI) 提供快速、無伺服器的容器，無需管理叢集。容器群組 (container group) 會共用一個網路命名空間、IP 和儲存體磁碟區；可利用 sidecar 模式 (例如，在應用程式容器旁放置一個日誌代理程式) 和多容器設定，將緊密耦合的程序部署在同一位置。透過子網路委派 (subnet delegation) 進行 VNet 整合，可啟用私有位址空間、輸出控制 (egress control) 和用於相依性的私有端點 (private endpoints)；這有助於從私有環境執行突發性或隨選的工作。ACI 非常適合需要秒級到分鐘級啟動時間的短暫任務、CI/CD 步驟和尖峰工作負載，但不適用於複雜的服務網格 (service mesh) 或進階排程。

Azure Kubernetes Service (AKS) 負責管理 Kubernetes 控制平面 (control plane)，提供可選的 Uptime SLA，並支援系統和使用者節點池 (node pool)。使用一個最小且經過污染 (tainted) 的系統節點池來執行核心元件，並為每種工作負載類型 (例如 GPU、Spot、Windows) 建立獨立的使用者節點池。整合 Spot 節點池以節省可容錯工作負載的成本，並搭配使用 tolerations 和 PodDisruptionBudgets。叢集自動擴縮器 (cluster autoscaler) 會根據無法排程的 pod 來調整節點池中的節點數量；可將其與 Horizontal Pod Autoscaler (HPA) 結合使用，若需事件驅動的擴縮，則可搭配 KEDA。Azure CNI 會將 VNet IP 直接指派給 pod，簡化了網路原則、服務探索以及透過可路由位址與地端環境的整合，但會消耗較多 IP；Azure CNI Overlay 則在保留 CNI 語意的同時，減少了 VNet IP 的消耗。Kubenet 使用 NAT，只需較少的 VNet IP，但增加了 SNAT 的複雜性，且進階網路功能有限。企業級網路和原則應選擇 CNI，位址空間受限的小型叢集應選擇 kubenet，而若想在不造成 CIDR 擴張的情況下實現大規模 pod 密度，則應選擇 Overlay。為節點池採用可用性區域 (availability zones)，使用浪湧升級 (surge upgrades) 以將中斷降至最低，並利用節點/映像檔升級通道來維持安全態勢。

Batch 與 Service Fabric

Azure Batch 可協調大規模的平行和 HPC 工作負載，無需自行建構排程器。集區 (Pool) 定義了運算資源：VM 大小 (包含 GPU/HPC)、映像檔 (Marketplace、自訂或 Shared Image Gallery)，以及用於環境啟動 (bootstrapping) 的啟動工作 (start task)。應用程式套件 (Application package) 可對您的二進位檔進行版本控制；憑證和受控識別 (managed identity) 則能安全地整合祕密。作業 (Job) 將多個工作 (task) 組成群組，這些工作可以宣告相依性、使用多重執行個體協調，並利用每個 VM 的工作位置 (task slot)。作業排程 (Job schedule) 可自動提交週期性作業。自動擴縮公式會參考內建指標 (例如 $PendingTasks、$RunningTasks) 和目標計數 (targetDedicatedNodes、targetLowPriorityNodes)，並透過邏輯來應對佇列深度、執行時間平均值和成本限制。自動集區 (Autopool) 會為每個作業建立專屬集區以提供乾淨的環境；持續性集區 (persistent pool) 則可為頻繁執行的作業分攤初始化成本。混合使用低優先權 (Spot) 節點以降低成本，並搭配容錯邏輯和檢查點 (checkpointing) 機制。

Azure Service Fabric 是一個用於微服務的分散式系統平台，具備強大的狀態管理能力。無狀態服務 (Stateless service) 可水平擴展且易於復原，而有狀態服務 (stateful service) 則使用 Reliable Collections 和複寫 (replication) 來滿足低延遲、記憶體內狀態 (in-memory state) 的需求，同時具備磁碟持久性。分割 (Partitioning) 可分散負載和狀態；複本集 (replica set) 則維持可用性。叢集可靠性層級 (Bronze、Silver、Gold、Platinum) 定義了種子節點 (seed node) 和仲裁 (quorum) 的要求，進而影響容錯能力和升級並行性。升級網域 (Upgrade domain) 透過隔離故障影響來協調整個叢集的滾動升級；健康狀態原則和自動回復則可確保安全性。Service Fabric 適用於需要高輸送量有狀態處理、複雜工作流程，或當強式一致性及與運算資源共置 (co-location) 至關重要的情境。

Azure VMware Solution 與運算決策框架

Azure VMware Solution (AVS) 在 Azure 裸機上提供全受控的 vSphere、vSAN 和 NSX-T 堆疊。私有雲在 Azure 區域中運行，可透過 vCenter 存取並使用熟悉的 VMware 工具。連線能力使用 AVS ExpressRoute 線路，透過 ExpressRoute Global Reach 與 Azure VNet 對等互連；再從那裡透過現有的 ExpressRoute 或 VPN 連線到地端環境。NSX-T 網路提供微分段和南北向路由。HCX 支援即時 vMotion、大量移轉、複寫輔助 vMotion 和網路延伸，以實現低停機時間的資料中心撤離和現代化階段。AVS 非常適合用於資料中心退場、與 VMware 架構緊密耦合的應用程式組合，以及後續可透過私有連結與原生 Azure 服務整合的過渡性登陸區。

選擇運算服務遵循明確的經驗法則：

當您需要作業系統層級的控制、自訂映像檔、特殊硬體 (GPU/HPC) 或有舊版相依性時，請使用 Azure VM。新增可用性設定組/區域和 PPG 以滿足 SLA 和延遲目標。應用 Spot 執行個體以進行可中斷的成本優化。
當您使用標準框架託管 Web API/網站，且希望擁有受控平台、內建的 DevOps 位置，並在無容器/Kubernetes 複雜性的情況下自動擴展時，請使用 App Service。當您需要 VNet 整合和企業級功能時，請選擇 Premium 或 Isolated 層級。
對於事件驅動、高突發性或工作流程導向的任務，且營運開銷極低時，請使用 Azure Functions；Premium 方案可消除冷啟動並啟用 VNet/私有存取。採用 Durable Functions 進行協調流程和長時間執行的活動。
對於暫時性的容器和作業、快速擴展，以及作為來自管線或 AKS 虛擬節點的無伺服器執行目標時，請使用 ACI。對於私有工作負載，請選擇與 VNet 整合的 ACI。
對於微服務、可攜性、進階排程、服務網格以及大規模標準化容器 DevOps，請使用 AKS；根據 IP 需求和網路原則要求選擇 CNI 模型。根據工作負載特性和可用性區域來分割節點集區，並啟用自動擴展。
對於平行運算、渲染、蒙地卡羅和 ETL 工作負載，且需要排程、自動擴展的經濟效益和低優先權容量時，請使用 Azure Batch。
對於高吞吐量的具狀態微服務，或需要強一致性、可靠的 actor 模型以及對升級/放置的精確控制時，請使用 Service Fabric。
使用 AVS 快速遷移 VMware 資產、保留營運模型，並在現代化過程中與 Azure 網路和服務整合。

實務問題情境

Contoso Retail 正在現代化其電子商務平台，以應對快閃銷售，要求其 API 層與快取層之間的延遲低於 10 毫秒，在單一區域內滿足 99.99% 的 SLA，在正常需求期間將成本降至最低，並遷移仍在 VMware 上運行的舊版訂單管理系統。該解決方案必須公開公用 API、處理非同步事件，並在不影響線上網站的情況下，執行夜間的推薦模型評分作業。

將核心運算資源放置在具有三個可用性區域的區域中，並建立一個鄰近放置群組 (PPG)。將 API 層託管在 PPG 內的區域性 VMSS (使用 Premium SSD v2、加速網路) 中，以最小化與 Redis Enterprise 和區域性 SQL/Cache 資源之間的延遲。此選擇為熱門路徑提供了精細的效能控制、PPG 層級的延遲降低和區域層級的彈性。
根據請求率和自訂佇列深度指標設定 VMSS 自動擴展，並為預期的快閃銷售設定排程設定檔。啟用帶有健康狀態探查和自動映像檔升級的滾動升級。這確保了在極端負載下仍能維持彈性容量和安全的部署，同時滿足 SLA。
將面向客戶的 Web 前端部署在 Azure App Service Premium v3 上，並使用部署位置進行藍綠部署。透過 Private Endpoints 將應用程式與 VNet 整合，以實現對後端 API 和資料存放區的私有輸出。選擇 App Service 是為了卸載平台管理工作，並透過安全交換來簡化持續交付流程。
使用 Azure Functions Premium 實作非同步訂單處理，透過 Service Bus 觸發器和 Durable Functions 進行協調 (例如用於庫存檢查、付款授權和通知的 fan-out/fan-in 模式)。Premium 方案可消除冷啟動、支援 VNet 整合，而 Durable Functions 則提供可靠的 saga 協調。
使用 Azure Batch 在一個預先載入模型相依性的持續性集區中，跨低優先權 (Spot) 節點執行夜間的推薦模型評分。自動擴展公式根據待處理任務和預計執行時間來設定目標節點數。Batch 將繁重的運算工作負載與營運資料存放區隔離，並透過 Spot 容量和可設定檢查點的任務來優化成本。
針對由 CI/CD 觸發的突發性、臨時性資料轉換作業，以及針對特定租用戶的報告生成，新增 ACI。將容器群組部署到委派的子網路中，以確保所有處理都在私有位址空間內進行。選擇 ACI 是因為它能近乎即時地啟動，且對於零星的任務沒有叢集管理開銷。
為舊版訂單管理系統建立 Azure VMware Solution，使用 HCX 透過複寫輔助 vMotion 進行遷移，並在過渡期間將地端網路延伸至 AVS。透過 ExpressRoute Global Reach 將 AVS 連接到應用程式 VNet。AVS 保留了原有的營運工具，並在無需重構的情況下加速了資料中心的退場。
對於未來的微服務，部署 AKS，包含區域性使用者節點集區、一個受汙染 (tainted) 的系統集區，以及一個用於可容錯工作負載的 Spot 集區。選擇 Azure CNI Overlay 以節省 VNet IP 空間，同時保留原則功能。啟用叢集自動擴展器 (cluster autoscaler) 和 HPA 進行分層擴展。AKS 為 Contoso 定位，使其能朝著協調流程可增值的容器原生方向發展。

此組合透過用於熱門路徑的 VMSS 搭配 PPG 和區域，滿足了低延遲和高可用性的需求；透過 App Service 簡化了 Web 交付；高效地使用無伺服器和批次處理來進行非同步和批次運算；利用 ACI 處理暫時性任務；並採用 AVS 遷移依賴 VMware 的系統——所有這些都透過 VNet 和 Private Endpoints 進行私有整合，以維持安全性和效能。

← 資料儲存與資料庫解決方案 · 所有領域 · 網路與連線能力 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →