App Service Environment 的異地分散規模調整

  • 發行項

概觀

若應用程式案例需要高度擴充，則可能會超過單一應用程式部署可用的計算資源容量。 例如，投票應用程式、體育活動及電視娛樂活動，都屬於需要極高延展性的案例。 水平擴充應用程式便可符合高度擴充需求。 若要處理極端的負載需求，則可在單一區域內及跨區域部署許多應用程式。

App Service 環境是水平擴增的理想平台。在選取可支援已知要求率的 App Service 環境組態之後，開發人員即可透過「千篇一律」的方式部署其他 App Service 環境，以獲得所需的尖峰負載容量。

例如，假設在 App Service 環境組態上執行的應用程式已經過測試，每秒可處理 20K 個要求 (RPS)。 若所需的尖峰負載容量為 100K RPS，則可建立並設定五 (5) 個 App Service 環境，以確保應用程式可處理最大預測負載。

由於客戶通常會使用自訂 (或虛名) 網域存取應用程式，因此開發人員必須要有將應用程式要求分散到所有 App Service 環境執行個體的方法。 使用 Azure 流量管理員設定檔來解析自訂網域，便是達成此目標的好方式。 流量管理員設定檔可設定為指向所有個別的 App Service 環境。 流量管理員會根據流量管理員設定檔中的負載平衡設定，將客戶自動分散至所有的 App Service 環境。 無論所有的 App Service 環境是部署在單一 Azure 區域，還是跨多個 Azure 區域部署於世界各地，此方法都可運作。

此外，由於客戶是透過虛名網域存取應用程式的，因此無從得知執行應用程式的 App Service 環境數目。 因此，開發人員可以根據觀察到的流量負載，快速且輕鬆地新增和移除 App Service 環境。

下方的概念圖表說明在單一區域內以水平方式相應放大至三個 App Service 環境的應用程式。

Conceptual architecture diagram of geo-distributed app service with Traffic Manager.

本主題的其餘部分將逐步解說使用多個 App Service 環境為範例應用程式設定分散式拓撲所需的步驟。

規劃拓樸

在建置分散式應用程式的使用量之前，最好先備妥幾項資訊。

  • 應用程式的自訂網域： 客戶將用來存取應用程式的自訂網域名稱為何？ 針對範例應用程式，自訂網域名稱為 www.asabuludemo.com。
  • 流量管理員網域：建立 Azure 流量管理員設定檔時，選擇網域名稱。 此名稱會與 trafficmanager.net 尾碼結合，以註冊流量管理員所管理的網域項目。 就範例應用程式而言，選擇的名稱是 scalable-ase-demo。 因此，流量管理員所管理的完整網域名稱是 scalable-ase-demo.trafficmanager.net。
  • 調整應用程式使用量的策略： 應用程式使用量是否會分散到單一區域中的多個 App Service 環境？ 多個區域嗎？ 兩種方法混合搭配使用嗎？ 決策依據為客戶流量預期的來源位置，以及其餘應用程式所支援的後端基礎結構擴充性。 例如 100% 無狀態的應用程式，則可讓每個 Azure 區域搭配許多 App Service 環境，再將 App Service 環境部署於許多 Azure 區域，便可大量擴充應用程式。 由於有 15 個以上的全球 Azure 區域可供選擇，客戶將可真正建置全球性超高延展性的應用程式使用量。 本文所用的範例應用程式在單一 Azure 區域 (美國中南部) 建立了三個 App Service 環境。
  • App Service 環境的命名慣例： 每個 App Service 環境都需要唯一名稱。 有兩個或更多 App Service 環境時，命名慣例將有助於識別每個 App Service 環境。 範例應用程式採用簡單的命名慣例。 三個 App Service 環境的名稱分別是 fe1ase、fe2ase 和 fe3ase。
  • 應用程式的命名慣例：由於將會部署多個應用程式執行個體，每個部署的應用程式執行個體都要有名稱。 App Service 環境有一項鮮為人知的便利功能：多個 App Service 環境可使用相同的應用程式名稱。 由於每個 App Service 環境都有唯一的網域尾碼，開發人員可以選擇在每個環境中重複使用相同的應用程式名稱。 例如，開發人員可以將應用程式命名如下：myapp.foo1.p.azurewebsites.net、myapp.foo2.p.azurewebsites.net、myapp.foo3.p.azurewebsites.net，依此類推。不過，範例應用程式的每個應用程式執行個體也都有唯一名稱。 所使用的應用程式執行個體名稱是 webfrontend1、webfrontend2 和 webfrontend3。

設定流量管理員設定檔

將應用程式的多個執行個體部署在多個 App Service 環境上之後，可以使用流量管理員來註冊個別的應用程式執行個體。 針對範例應用程式，scalable-ase-demo.trafficmanager.net 需要流量管理員設定檔，才能將客戶路由傳送至已部署的下列應用程式執行個體：

  • webfrontend1.fe1ase.p.azurewebsites.net： 部署在第一個 App Service 環境上的範例應用程式執行個體。
  • webfrontend2.fe2ase.p.azurewebsites.net： 部署在第二個 App Service 環境上的範例應用程式執行個體。
  • webfrontend3.fe3ase.p.azurewebsites.net： 部署在第三個 App Service 環境上的範例應用程式執行個體。

若要註冊在相同 Azure 區域內執行的多個 Azure App Service 端點，最簡單的方式即是透過 Powershell Azure Resource Manager 流量管理員支援。

第一個步驟是建立 Azure 流量管理員設定檔。 下列程式碼說明如何為範例應用程式建立設定檔：

$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName yourRGNameHere -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"

請留意 RelativeDnsName 參數如何設為 scalable-ase-demo。 此參數可建立網域名稱 scalable-ase-demo.trafficmanager.net，並與流量管理員設定檔建立關聯。

TrafficRoutingMethod 參數會定義負載平衡原則，供流量管理員判斷如何將客戶負載分散至所有可用端點。 此範例已選擇加權方法。 由於這項選擇，系統便會根據各端點相關的相對權數，將客戶要求分散至已註冊的所有應用程式端點。

在建立設定檔後，每個應用程式執行個體都會新增至設定檔做為原生 Azure 端點。 下列程式碼會擷取各前端 Web 應用程式的參考。 接著便會透過 TargetResourceId 參數，將各應用程式新增為流量管理員端點。

$webapp1 = Get-AzWebApp -Name webfrontend1
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend1 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –EndpointStatus Enabled –Weight 10

$webapp2 = Get-AzWebApp -Name webfrontend2
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend2 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –EndpointStatus Enabled –Weight 10

$webapp3 = Get-AzWebApp -Name webfrontend3
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend3 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp3.Id –EndpointStatus Enabled –Weight 10

Set-AzTrafficManagerProfile –TrafficManagerProfile $profile

請留意，對於每個應用程式執行個體分別會有一個 Add-AzureTrafficManagerEndpointConfig 呼叫。 每個 PowerShell 命令的 TargetResourceId 參數皆會參考三個已部署應用程式執行個體中的其中一個。 流量管理員設定檔會將負載分散在設定檔中所註冊的所有三個端點上。

三個端點都會使用相同的值 (10) 做為 Weight 參數。 在此狀況下，流量管理員會讓客戶要求較平均分散於全部三個應用程式執行個體。

將應用程式的自訂網域指向流量管理員網域

最後一個必要步驟是將應用程式的自訂網域指向流量管理員網域。 針對範例應用程式，請指向 scalable-ase-demo.trafficmanager.net 的 www.asabuludemo.com。 透過管理自訂網域的網域註冊機構，完成此步驟。

若使用註冊機構的網域管理工具，必須建立一個將自訂網域指向流量管理員網域的 CNAME 記錄。 下圖顯示此 CNAME 組態的範例：

Screenshot of configuring CNAME record on DNS.

雖然本主題並未說明，但請記住，每個應用程式執行個體也都需要註冊其自訂網域。 否則，若應用程式執行個體收到要求，且應用程式尚未註冊該應用程式的自訂網域，要求將會失敗。

在此範例中，自訂網域為 www.asabuludemo.com，且每個應用程式執行個體皆有其相關聯的自訂網域。

Screenshot of App Service custom domain setting.

如需了解 Azure App Service 應用程式註冊自訂網域的重點回顧，請參閱註冊自訂網域。

嘗試使用分散式拓撲

使用流量管理員與 DNS 設定的最終結果，是 www.asabuludemo.com 的要求會歷經下列順序的流程：

  1. 瀏覽器或裝置會針對 www.asabuludemo.com 進行 DNS 查閱
  2. 網域註冊機構上的 CNAME 項目使 DNS 查閱重新導向至 Azure 流量管理員。
  3. 對其中一個 Azure 流量管理員 DNS 伺服器執行 scalable-ase-demo.trafficmanager.net 的 DNS 查閱。
  4. 根據 TrafficRoutingMethod 參數先前指定的負載平衡原則，流量管理員會選取其中一個設定的端點。 接著便會將該端點的 FQDN 傳回瀏覽器或裝置。
  5. 由於端點的 FQDN 為 App Service 環境所執行應用程式執行個體的 URL，因此瀏覽器或裝置會要求 Microsoft Azure DNS 伺服器將 FQDN 解析為 IP 位址。
  6. 瀏覽器或裝置會將 HTTP/S 要求傳送至此 IP 位址。
  7. 要求會送達在其中一個 App Service 環境上執行的應用程式執行個體之一。

範例應用程式自訂網域的 DNS 查閱如下列主控台圖片所示。 此 DNS 查閱成功解析為在三個範例 App Service 環境之一 (此處為三個 App Service 環境中的第二個) 中執行的應用執行個體：

Screenshot of DNS lookup result.

PowerShell Azure Resource Manager 流量管理員支援的相關文件。

注意

如果您想要在註冊 Azure 帳戶前先開始使用 Azure App Service，請前往試用應用程式服務，您可以在應用程式服務中立即建立暫時的入門 Web 應用程式。 無需信用卡，也無需簽定合約。