Azure App Service 中間歇輸出連線錯誤疑難排解

本文協助您針對 Azure App Service 中的間歇性連線錯誤和相關的效能問題進行疑難排解。 這針對來源網路位址轉譯 (SNAT) 連接埠耗盡的問題,提供詳細資訊和疑難排解方法。 如果您在本文中任何地方需要協助,請連絡 MSDN Azure 和 Stack Overflow 論壇上的 Azure 專家。 或者,提出 Azure 支援案件。 請移至 Azure 支援網站,然後選取 [取得支援]

徵兆

裝載於 Azure App 服務的應用程式和函式可能出現下列一或多個徵兆:

  • 服務方案中所有或部分執行個體的回應時間很慢。
  • 間歇性 5xx 或不正確的閘道錯誤
  • 逾時錯誤訊息
  • 無法連線至外部端點 (例如 SQLDB、Service Fabric、其他 App Service 等)

原因

間歇性連線問題的主要原因是建立新的輸出連線時達到限制。 可能達到的限制包括:

  • TCP 連線:可建立的輸出連線數目有限制。 輸出連線的限制與使用的背景工作角色大小有關。
  • SNAT 連接埠:Azure 中的輸出連線描述 SNAT 連接埠限制及其如何影響輸出連線。 Azure 與公用 IP 位址通訊時,使用來源網路位址轉譯 (SNAT) 和 Load Balancer (未向客戶公開)。 Azure App 服務上的每個執行個體最初都預先配置 128 個 SNAT 連接埠。 SNAT 連接埠限制影響對同一組位址和連接埠建立的連線。 如果應用程式對相混的位址和連接埠組合建立連線,則不會耗盡 SNAT 連接埠。 重複呼叫同一組位址和連接埠會耗盡 SNAT 連接埠。 連接埠一經釋放,即可視需要重複使用。 Azure 網路負載平衡器只能等 4 分鐘之後,才從關閉的連線回收 SNAT 連接埠。

當應用程式或函式快速開啟新的連線時,可能很快耗盡預先配置的 128 個連接埠配額。 然後應用程式或函式就停滯,直到透過動態配置更多的 SNAT 連接埠,或重複使用回收的 SNAT 連接埠,而有新的 SNAT 連接埠可用為止。 如果應用程式耗盡 SNAT 連接埠,則會發生間歇性輸出連線問題。

避免問題

有幾個解決方案可讓您避開 SNAT 連接埠限制。 其中包含:

  • 連線集區:共用連線可避免建立新的網路連線來呼叫同一組位址和連接埠。
  • 服務端點:服務端點保護的服務不受 SNAT 連接埠限制。
  • 私人端點:私人端點保護的服務不受 SNAT 連接埠限制。
  • NAT 閘道:NAT 閘道提供 64k 個輸出 SNAT 連接埠,可供傳入流量的資源使用。

若要避免 SNAT 連接埠問題,您要避免對同一組主機和連接埠重複建立新連線。 連線集區是較明顯解決該問題的方式之一。

如果目的地是支援服務端點的 Azure 服務,您可以使用區域 VNet 整合和服務端點或私人端點,以避免 SNAT 連接埠耗盡問題。 當您使用區域 VNet 整合,並將服務端點放在整合子網路上時,應用程式到這些服務的輸出流量不受輸出 SNAT 連接埠限制。 同樣地,如果您使用區域 VNet 整合和私人端點,該目的地不會有任何輸出 SNAT 連接埠問題。

如果目的地是 Azure 外面的外部端點,則使用 NAT 閘道會給您 64k 個輸出 SNAT 連接埠。 還給您專用的輸出位址,不與任何人共用。

可能的話,請改善程式碼來使用連線集區,徹底避免此情況。 不一定來得及變更程式碼以減輕此情況。 如果無法及時變更程式碼,請改採其他解決方案。 問題的最佳解決方案是盡可能結合所有解決方案。 至於其他情況,請嘗試對 Azure 服務和 NAT 閘道使用服務端點和私人端點。

緩和 SNAT 埠耗盡的一般策略會在Azure 檔的輸出連線問題解決一節中討論。 在這些策略中,以下適用於 Azure App 服務上裝載的應用程式和函式。

將應用程式修改成使用連線共用

下列一組連結說明以不同解決方案堆疊來實作連線共用。

節點

根據預設,NodeJS 的連線不會保持運作。 以下是連線共用的熱門資料庫和套件,其中包含如何實作的範例。

HTTP 保持連線

Java

以下是 JDBC 連線共用常用的程式庫,其中包含實作範例:JDBC 連線共用。

HTTP 連線集區

PHP

雖然 PHP 不支援連線共用,但您可以嘗試對後端伺服器使用持續性資料庫連結。

Python

以下是連線共用的熱門資料庫和模組,其中包含如何實作的範例。

HTTP 連線集區

  • 要求模組中,預設會啟用 Keep-alive 和 HTTP 連線共用。
  • Urllib3

將應用程式修改成重複使用連線

將應用程式修改成使用較不積極的重試邏輯

使用 Keepalive 來重設輸出閒置逾時

App Service 專用的更多指導:

  • 負載測試應該以穩定輸送速度模擬真實世界的資料。 在實際壓力下測試應用程式和函式,可及早識別並解決 SNAT 連接埠耗盡的問題。
  • 請確定後端服務可以快速傳回回應。 如需針對 Azure SQL Database 效能問題進行疑難排解,請檢閱使用 Intelligent Insights 針對 Azure SQL Database 效能問題進行疑難排解
  • 將 App Service 方案擴增到更多執行個體。 如需有關調整的詳細資訊,請參閱在 Azure App Service 中調整應用程式規模。 App Service 方案中的每個背景工作執行個體都配置有一些 SNAT 連接埠。 如果將使用量分散到更多執行個體,則每個執行個體的 SNAT 連接埠使用量可能低於對每個唯一遠端端點建議的限制,即 100 個輸出連線。
  • 請考慮移至 App Service 環境 (ASE),其中會分配單一輸出 IP 位址給您,而且連線和 SNAT 連接埠的限制較高。 在 ASE 中,每個執行個體的 SNAT 連接埠數目是以 azure 負載平衡器預先設定資料表為基礎。 例如,具有 1-50 個背景工作執行個體的 ASE 每個執行個體有 1024 個預先配置連接埠,而具有 51-100 個背景工作執行個體的 ASE 則每個執行個體有 512 個預先配置埠。

因為輸出 TCP 限制是由背景工作角色的大小設定,避開限制較容易解決。 您可以查看沙箱跨 VM 數值限制 - TCP 連線中的限制

限制名稱 描述 小型 (A1) 中型 (A2) 大型 (A3) 隔離層 (ASE)
連線 整個 VM 的連線數目 1920 3968 8064 16,000

若要避開輸出 TCP 限制,您可以增加背景工作角色的大小,或水平擴增。

疑難排解

了解兩種輸出連線限制及應用程式在做什麼,應該會較容易疑難排解。 如果您知道應用程式頻繁呼叫相同的儲存體帳戶,您可能懷疑受到 SNAT 限制。 如果應用程式完全透過網際網路很頻繁呼叫端點,您會懷疑已達到 VM 限制。

如果您不夠了解應用程式的行為,而無法快速查明原因,App Service 中有一些工具和技術可幫助您判斷。

尋找 SNAT 連接埠配置資訊

您可以使用 App Service 診斷來尋找 SNAT 連接埠配置資訊,並觀察 App Service 網站的 SNAT 連接埠配置計量。 若要尋找 SNAT 連接埠配置資訊,請遵循下列步驟:

  1. 若要存取 App Service 診斷,請在 Azure 入口網站中瀏覽至您的 App Service Web 應用程式或 App Service 環境。 在左側導覽中,選取 [診斷並解決問題]
  2. 選取 [可用性和效能] 類別
  3. 在類別下可用的圖格清單中,選取 [SNAT 連接埠耗盡] 圖格。 習慣上是保持低於 128。 真有需要的話,您仍然可以提交支援票證,支援工程師會為您從後端取得計量。

由於 SNAT 連接埠使用量不是計量,無法根據 SNAT 連接埠使用量來自動調整,也無法根據 SNAT 連接埠配置計量來設定自動調整。

TCP 連線和 SNAT 連接埠

TCP 連線和 SNAT 連接埠沒有直接關係。 任何 App Service 應用程式的 [診斷並解決問題] 管理頁面中,都有 TCP 連線使用量偵測器。 搜尋「TCP 連線」一詞即可找到。

  • SNAT 連接埠僅用於外部網路流程,而 TCP 連線總計包含本機迴路連線。
  • 如果不同流量的通訊協定、IP 位址或連接埠不同,則可以共用 SNAT 連接埠。 TCP 連線計量計算每個 TCP 連線。
  • TCP 連線限制發生在背景工作執行個體層級。 Azure 網路輸出負載平衡不使用 TCP 連線計量來偵測 SNAT 連接埠限制。
  • 沙箱跨 VM 數值限制 - TCP 連線中說明 TCP 連線限制
  • 當新的輸出 TCP 工作階段從 Azure App Service 來源連接埠時新增,現有的 TCP 工作階段會失敗。 您可以使用單一 IP 或重新設定後端集區成員來避免衝突。
限制名稱 描述 小型 (A1) 中型 (A2) 大型 (A3) 隔離層 (ASE)
連線 整個 VM 的連線數目 1920 3968 8064 16,000

WebJob 和資料庫連線

如果 SNAT 連接埠耗盡,而導致 WebJob 無法連線至 SQL Database,沒有計量可顯示每個 Web 應用程式流程開啟的連線數目。 若要找出有問題的 WebJob,請將幾個 WebJob 移到另一個App Service 方案,看看情況是否改善,還是其中一個方案仍有問題。 重複此流程,直到找出有問題的 WebJob 為止。

其他資訊