App Service 環境を使用した geo 分散スケール

概要

きわめて大規模なスケーリングを必要とするアプリケーション シナリオでは、単一のアプリ デプロイメントで使用できるコンピューティング リソース容量では足りないことがあります。 投票アプリケーション、スポーツ イベント、テレビ放送される娯楽イベントは、いずれも非常に高いスケールを必要とするシナリオの例です。 高スケールの要件には、アプリを水平方向にスケールアウトすることで対応できます。 極端な負荷要件に対応できるように、1 つのリージョン内および複数のリージョン内で、多数のアプリのデプロイを行うことができます。

App Service Environment は、水平方向のスケールアウトに最適なプラットフォームとなっています。既知の要求率をサポートできる App Service Environment 構成を選択していれば、開発者は追加の Azure App Service Environment を "ひな型" 方式でデプロイして、必要なピーク時負荷容量を確保できます。

たとえば、App Service Environment の構成で実行されるアプリが、20K RPS (1 秒あたりの要求数) を処理することがテストでわかっているとします。 必要なピーク時負荷容量が 100K RPS である場合、5 つの App Service Environment を作成して、予想される最大負荷をアプリケーションで処理できるように構成できます。

顧客は通常、カスタム ドメイン (またはバニティ ドメイン) を使用してアクセスするため、開発者は、App Service 環境のすべてのインスタンスにアプリの要求を分散する方法を必要とします。 この目的を実現する優れた方法が、Azure Traffic Manager プロファイルを使用したカスタム ドメインの解決です。 Traffic Manager プロファイルは、個々の App Service 環境をすべてポイントするように構成できます。 Traffic Manager は、Traffic Manager プロファイルの負荷分散設定に基づいて、すべての Azure App Service Environment 間での顧客の分散を自動的に処理します。 このアプローチは、すべての App Service 環境が単一の Azure リージョンにデプロイされている場合はもちろん、世界の複数の Azure リージョンに展開されている場合でも、問題なく機能します。

さらに、顧客はバニティ ドメインを使用してアプリにアクセスするため、アプリを実行する App Service 環境の数を意識することがありません。 結果として開発者は、観測されたトラフィック負荷に基づいて、App Service 環境の追加や削除を迅速かつ簡単に実行できます。

次の概念図は、単一リージョン内の 3 つの App Service 環境で水平方向にスケールアウトされたアプリを示しています。

このトピックの残りの部分では、複数の App Service 環境を使用してサンプル アプリの分散トポロジを設定するのに必要な手順について説明します。

トポロジを計画する

分散アプリケーションのフットプリントを構築する前に、いくつかの情報を前もって用意しておくと作業がスムーズになります。

• アプリのカスタム ドメイン: 顧客がアプリへのアクセスに使用するカスタム ドメイン名な何でしょう? このサンプル アプリで、カスタム ドメイン名は www.asabuludemo.com です。
• Traffic Manager ドメイン: Azure Traffic Manager プロファイルを作成する際にドメイン名を選択します。 この名前は、Traffic Manager が管理するドメイン エントリに登録するために、trafficmanager.net サフィックスと組み合わされます。 サンプル アプリでは、scalable-ase-demo という名前を選択しています。 結果的に、Traffic Manager で管理される完全なドメイン名は、scalable-ase-demo.trafficmanager.net になります。
• アプリ フットプリントのスケーリングに関する戦略: アプリケーションのフットプリントは、単一リージョン内の複数の App Service Environment に分散されますか? リージョンは複数ですか? 両方のアプローチの組み合わせが最適ですか? これは、顧客のトラフィックが発生する場所に加えて、アプリをサポートするバックエンド インフラストラクチャの他の部分がどの程度適切にスケーリングできるかという見込みに基づいて決定する必要があります。 たとえば、完全にステートレスなアプリケーションでは、各 Azure リージョンで多数の App Service Environment を組み合わせ、これに多くの Azure リージョンにデプロイされた App Service Environment を掛け合わせることで、大規模なスケーリングを実現できます。 選択できるグローバルな Azure リージョンは 15 以上あるため、顧客はスケーラビリティのきわめて高いアプリケーション フットプリントを世界規模で構築できます。 この記事に使用されるサンプル アプリでは、単一の Azure リージョン (米国中南部) に 3 つの App Service Environment を作成しています。
• App Service 環境の命名規則: 各 App Service 環境に一意の名前が必要です。 App Service Environment の数が 1 つか 2 つを超える場合、名前付け規則を用意すると、各 App Service Environment を識別する上で便利になります。 サンプル アプリでは、シンプルな名前付け規則が使用されています。 ここでの 3 つの App Service Environment の名前は fe1ase、fe2ase、fe3ase です。
• アプリの命名規則: デプロイされるアプリのインスタンスは複数あるため、デプロイされたアプリの各インスタンスに名前が必要です。 App Service Environment のあまり知られていない便利な機能の 1 つとして、同じアプリ名を複数の App Service Environment で使用できる、ということがあります。 App Service 環境ごとに一意のドメイン サフィックスがあるため、開発者は各環境でまったく同じアプリ名を再利用できます。 たとえば、開発者は、myapp.foo1.p.azurewebsites.net、myapp.foo2.p.azurewebsites.net、myapp.foo3.p.azurewebsites.net のようなアプリ名を設定できます。ただし、このサンプル アプリでは、各アプリ インスタンスに一意の名前を設定しています。 使用されているアプリ インスタンス名は webfrontend1、webfrontend2、webfrontend3 です。

Traffic Manager プロファイルを設定する

アプリの複数のインスタンスを複数の App Service 環境にデプロイしたら、個々のアプリ インスタンスを Traffic Manager に登録できます。 サンプル アプリでは、顧客を次のデプロイ済みアプリ インスタンスのいずれかにルーティングする scalable-ase-demo.trafficmanager.net 用に、Traffic Manager プロファイルが必要です。

• webfrontend1.fe1ase.p.azurewebsites.net: 1 つ目の App Service 環境にデプロイされているサンプル アプリのインスタンス。
• webfrontend2.fe2ase.p.azurewebsites.net: 2 つ目の App Service 環境にデプロイされているサンプル アプリのインスタンス。
• webfrontend3.fe3ase.p.azurewebsites.net: 3 つ目の App Service 環境にデプロイされているサンプル アプリのインスタンス。

同じ Azure リージョンで実行される複数の Azure App Service エンドポイントを登録する最も簡単な方法は、PowerShell で Azure Resource Manager による Traffic Manager のサポートを使用することです。

最初の手順では、Azure Traffic Manager プロファイルを作成します。 次のコードでは、サンプル アプリ用プロファイルの作成方法を示しています。

$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 が作成され、Traffic Manager プロファイルに関連付けられます。

TrafficRoutingMethod パラメーターには負荷分散ポリシーが定義されており、Traffic Manager はこのポリシーを使用して、顧客の負荷を利用可能なすべてのエンドポイントに分散する方法を判断します。 この例では、"重み付け" 方式が選択されています。 この選択により、顧客の要求が、各エンドポイントに関連付けられている相対的な重みに基づいて、登録済みのすべてのアプリケーション エンドポイント間で分散されます。

作成されるプロファイルに対して、各アプリ インスタンスがネイティブ Azure エンドポイントとして追加されます。 次のコードにより、各フロントエンド Web アプリへの参照がフェッチされます。 次に、TargetResourceId パラメーターを介して、各アプリが Traffic Manager エンドポイントとして追加されます。

$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 が、1 回ずつ呼び出されている点に注意してください。 各 PowerShell コマンドの TargetResourceId パラメーターによって、デプロイされた 3 つのアプリ インスタンスのうちの 1 つが参照されます。 Traffic Manager プロファイルにより、プロファイルに登録されている 3 つのエンドポイントすべての間で負荷が分散されます。

3 つのエンドポイントすべてで、Weigh (重み) パラメーターに同じ値 (10) が使用されています。 この状況では、Traffic Manager によって顧客の要求が 3 つすべてのアプリ インスタンス間で比較的均等に分散されます。

アプリのカスタム ドメインが Traffic Manager ドメインをポイントするように設定する

必須手順の最後として、アプリのカスタム ドメインが Traffic Manager ドメインをポイントするように設定します。 サンプル アプリの場合は、www.asabuludemo.com が scalable-ase-demo.trafficmanager.net をポイントするようにします。 この手順は、カスタム ドメインを管理するドメイン レジストラーを通じて実行します。

利用しているレジストラーのドメイン管理ツールを使用して、カスタム ドメインが Traffic Manager ドメインをポイントするように、CNAME レコードを作成します。 次の図に、この CNAME の構成がどのようになるかの例を示します。

このトピックでは説明しませんが、アプリ インスタンスごとにカスタム ドメインを登録する必要があることも、忘れないでおいてください。 要求がアプリ インスタンスに到達しても、アプリケーションにカスタム ドメインが登録されていないと、要求は失敗します。

この例では、カスタム ドメインは www.asabuludemo.com であり、これに関連付けられたカスタム ドメインを、各アプリ インスタンスが使用します。

Azure App Service アプリにカスタム ドメインを登録する方法のまとめは、カスタム ドメインの登録でご確認ください。

分散トポロジを試す

Traffic Manager と DNS を構成すると、最終的に www.asabuludemo.com への要求は、次のシーケンスを通過することになります。

1. ブラウザーまたはデバイスが www.asabuludemo.com の DNS ルックアップを行います
2. ドメイン レジストラーの CNAME エントリによって、DNS ルックアップが Azure Traffic Manager にリダイレクトされます。
3. Azure Traffic Manager の DNS サーバーのいずれかに対して、scalable-ase-demo.trafficmanager.net に関する DNS ルックアップが実行されます。
4. 先ほど TrafficRoutingMethod パラメーターに指定した負荷分散ポリシーに基づいて、構成済みのエンドポイントのいずれかが Traffic Manager によって選択されます。 次に、そのエンドポイントの FQDN がブラウザーまたはデバイスに返されます。
5. エンドポイントの FQDN は App Service Environment で実行されるアプリ インスタンスの URL であるため、ブラウザーまたはデバイスは FQDN を IP アドレスに解決するよう Microsoft Azure DNS サーバーに要請します。
6. ブラウザーまたはデバイスは、その IP アドレスに HTTP/S 要求を送信します。
7. 要求は、App Service 環境のいずれかで実行されているアプリ インスタンスのいずれかに到達します。

次のコンソール画像は、サンプル アプリのカスタム ドメインの DNS 参照を示しています。 ここでは、3 つのサンプル App Service Environment のいずれか (この場合は 3 つの App Service Environment の 2 つ目) で実行されるアプリ インスタンスに正しく解決されています。

その他のリンクおよび情報

PowerShell の Azure Resource Manager による Traffic Manager のサポートに関するドキュメント。