Azure App Service 中的自動調整
注意
自動調整適用於所有應用程式類型：Windows 和 Linux (部署為程式碼和容器)。 部署位置流量不支援自動調整。
自動調整是新的擴增選項，可自動處理 Web 應用程式和 App Service 方案的調整決策。 這與預先存在的 Azure 自動調整不同，後者可讓您根據排程和資源定義調整規則。 您可以透過自動調整，調整設定來改善應用程式的效能，並避免冷啟動問題。 此平台會預熱執行個體，使其在擴增時能夠作為緩衝區，以確保效能順暢的轉換。 我們會向您收取每個執行個體每秒的費用，包括預熱的執行個體。
App Service 上可用的擴增和縮減選項比較：
| 手動 | Autoscale | 自動縮放 | |
|---|---|---|---|
| 可用的定價層 | 基本和更高版本 | 標準和更高版本 | 進階 V2 (P1V2、P2V2、P3V2) 和進階 V3 (P0V3、P1V3、P2V3、P3V3、P1MV3、P2MV3、P3MV3、P4MV3、P5MV3) 定價層 |
| 以規則為基礎的調整 | No | Yes | 否，平台會根據 HTTP 流量來管理擴增和縮減。 |
| 以排程為基礎的調整 | No | .是 | No |
| 永遠就緒的執行個體 | 否，Web 應用程式會在手動調整的執行個體數目上執行。 | 否，您的 Web 應用程式會根據針對自動調整規則定義的閾值，在擴增作業期間可用的其他執行個體上執行。 | 是 (最小值 1) |
| 預熱的執行個體 | No | No | 是 (預設 1) |
| 每個應用程式上限 | No | 無 | Yes |
自動規模調整的運作方式
您可以啟用 App Service 方案的自動調整，並為每個 Web 應用程式設定一系列執行個體。 當 Web 應用程式開始接收 HTTP 流量時，App Service 會監視負載並新增執行個體。 當 App Service 方案內的多個 Web 應用程式需要同時擴增時，可能會共用資源。
在下列幾個案例中，您應該進行自動擴增：
- 您不想根據資源計量設定自動調整規則。
- 您希望相同 App Service 方案內的 Web 應用程式以不同且彼此獨立的方式進行調整。
- Web 應用程式已連線到資料庫或舊版系統，而此系統的調整速度可能無法像 Web 應用程式一樣快。 自動調整可讓您設定 App Service 方案可調整的執行個體數目上限。 此設定可協助 Web 應用程式，以免後端不堪負荷。
啟用自動調整
高載上限是 App Service 方案可以根據傳入 HTTP 要求增加的執行個體數目上限。 針對進階 v2 和 v3 方案，您可以設定最多 30 個執行個體的高載上限。 高載上限必須等於或大於為 App Service 方案指定的背景工作角色數目。
若要啟用自動調整，請瀏覽至 Web 應用程式的左側功能表，然後選取 [擴增 (App Service 方案)]。 選取 [自動]、更新 [高載上限] 值，然後選取 [儲存] 按鈕。
設定 Web 應用程式執行個體數目下限
隨時待命執行個體是指定執行個體數目下限的應用程式層級設定。 若負載超過隨時待命執行個體可以處理的內容，則會新增其他執行個體 (最多可達到 App Service 方案所指定的高載上限)。
若要設定 Web 應用程式執行個體數目下限，請瀏覽至 Web 應用程式的左側功能表，然後選取 [擴增 (App Service 方案)]。 更新隨時待命執行個體值，然後選取 [儲存] 按鈕。
設定 Web 應用程式執行個體數目上限
調整限制上限設定 Web 應用程式可調整的執行個體數目上限。 當資料庫之類的下游元件的輸送量有限時，調整限制上限就會有所幫助。 每個應用程式上限可以介於 1 和高載上限之間。
若要設定 Web 應用程式執行個體數目上限，請瀏覽至 Web 應用程式的左側功能表，然後選取 [擴增 (App Service 方案)]。 選取 [強制執行擴增限制]、更新 [調整限制上限]，然後選取 [儲存] 按鈕。
更新預熱的執行個體
預熱執行個體設定會在 HTTP 調整與啟用事件期間，提供暖執行個體作為緩衝區。 預熱的執行個體會繼續緩衝處理，直到達到最大擴增限制為止。 預設預熱的執行個體計數為 1，而且在大部分情節中，此值應維持為 1。
您無法在入口網站中變更預熱執行個體設定，必須改用 Azure CLI。
停用自動調整
若要停用自動調整，請瀏覽至 Web 應用程式的左側功能表，然後選取 [擴增 (App Service 方案)]。 選取 [手動]，然後選取 [儲存] 按鈕。
自動調整是否支援 Azure Function 應用程式？
警告
當 App Service Web 應用程式和 Azure 函式應用程式位於相同的 App Service 方案中時，就會停用自動調整。
否，您只能在想要啟用自動調整的 App Service 方案中擁有 Azure App Service Web 應用程式。 針對 Functions，建議改用 Azure Functions 進階方案。
自動調整如何在幕後運作？
設定為自動調整的應用程式會持續受到監視，而工作者健康情況評估至少每幾秒鐘發生一次。 如果系統偵測到應用程式上負載增加，健康情況檢查會變得更加頻繁。 如果工作者健康情況惡化和要求變慢，則會要求其他執行個體。 新增執行個體的速度會根據個別應用程式的負載模式和啟動時間而有所不同。 啟動時間短暫且負載間歇高載的應用程式，可能會看到每幾秒鐘至一分鐘就新增一部虛擬機器。
一旦負載消退，平台就會起始檢閱進行潛在的縮減。 此流程通常會在負載停止增加後大約 5-10 分鐘開始。 在縮減期間，會以每幾秒鐘到一分鐘一個的最大速率移除執行個體。
此外，如果多個 Web 應用程式部署在相同的 App Service 方案內，平台會盡力根據每個單獨 Web 應用程式的負載，跨可用執行個體配置資源。
如何針對預熱的執行個體計費？
若要了解您如何針對預熱的執行個體計費，請考慮此案例：假設您的 Web 應用程式有五個隨時可用的執行個體，以及一個設定為預設值的預熱執行個體。
當您的 Web 應用程式閒置且未收到任何 HTTP 要求時，其會使用五個隨時可用的執行個體執行。 此時，不會針對預熱的執行個體計費，因為未使用隨時可用的執行個體，因此不會配置任何預熱的執行個體。
不過，您的 Web 應用程式一開始接收 HTTP 要求，且五個隨時可用的執行個體變成作用中，就會配置預熱的執行個體，並開始計費。
如果 HTTP 要求的速率持續增加，且 App Service 決定調整超過初始五個執行個體，則其會開始使用預熱的實執行個體。 這表示當有六個作用中執行個體時，會立即佈建第七個執行個體來填入預熱的緩衝區。
此調整和預熱流程會繼續，直到達到應用程式的最大執行個體計數為止。 請務必注意，若超出最大執行個體計數，不會預熱或啟動執行個體。
為什麼 AppServiceHTTPLogs 具有類似 "/admin/host/ping" 的記錄項目，狀態為 404？
App Service 自動調整會定期檢查 /admin/host/ping 端點，以及平台固有的其他健康情況檢查機制。 這些檢查是特別實作的功能。 有時候，由於現有的平台設定，這些 Ping 可能會傳回 404 錯誤。 不過，請務必注意，這些 404 錯誤不應該影響您應用程式的可用性或調整效能。
如果您的 Web 應用程式傳回 5xx 狀態，這些端點 Ping 可能會導致間歇性重新啟動，但這種情況並不常見。 我們目前正在實作增強功能，以處理這些間歇性重新啟動。 在此之前，請確定您的 Web 應用程式不會在此端點傳回 5xx 狀態。 請注意，無法自訂這些 Ping 端點。
如何在自動調整事件期間追蹤擴增的執行個體數目？
AutomaticScalingInstanceCount 計量會報告應用程式執行所在的虛擬機器數目，包括預熱的執行個體 (如果已部署)。 此計量也可以用來追蹤在自動調整事件期間所擴增 Web 應用程式的執行個體數目上限。 此計量僅適用於已啟用自動調整的應用程式。
ARR 親和性如何影響自動調整？
Azure App Service 會使用稱為 ARR 親和性的應用程式要求路由 Cookie。 ARR 親和性 Cookie 會限制調整，因為其只會將要求傳送至與 Cookie 相關聯的伺服器，而不是任何可用的執行個體。 針對儲存狀態的應用程式，最好進行擴大 (增加單一執行個體上的資源)。 針對無狀態應用程式，擴增 (新增更多執行個體) 會提供更大的彈性和可擴縮性。 根據預設，App Service 上會啟用 ARR 親和性 Cookie。 根據您的應用程式需求，您可能選擇在使用自動調整時停用 ARR 親和性 Cookie。
若要停用 ARR 親和性 Cookie：選取您的 App Service 應用程式，然後在 [設定] 下，選取 [設定]。 接下來選取 [一般設定] 索引標籤。在 [ARR 親和性] 下，選取 [關閉]，然後選取 [儲存] 按鈕。