Web AppsのリソースプールはApp Service Planです。 ASEのコンテキストでは、App Service Planは点線であり、計算リソースの境界を強制します。実際の計算リソース(「ハードウェア」)は、ワーカープールに存在します。アプリケーションサービスプランは、ワーカープール内の1つ以上のインスタンスにまたがることができます。ここで
は鳥瞰図です:
あなたは混在させることができ
WORKER POOL 1
**********************************
* *
* App Service Plan "A" *
* +--------------------+ *
* | Web App 1 | *
* | Web App 2 | *
* | API App 1 | *
* | API App 2 | *
* +--------------------+ *
* *
**********************************
WORKER POOL 2
**********************************
* *
* App Service Plan "B" *
* +--------------------+ *
* | Web App 3 | *
* | API App 3 | *
* +--------------------+ *
* *
**********************************
と一致、つまりワーカープール1(3つのインスタンス)アプリのサービスプランA(のは、2つのインスタンスをしましょう)とアプリケーションサービスプランB(両方をホストする可能性があります1インスタンス)。
App Service Environment v2 will get rid of worker pools and make scaling out straight forward
これは非常に明確な感謝です。この図では、Worker Pool 1の場合は4つのVMインスタンスが必要ですが、Worker Pool 2の場合は2つのVMインスタンスが必要ですか? – Slicc
ワーカープールを個別にスケールすることができます。その後、App Service Plansを拡張して、Worker Poolに追加された新しいインスタンスを利用することができます。これにより、App Service Plan内のアプリの馬力が強化されます。 VM-to-appsバインディングはありません。これはアプリケーションからリソースのプールにすぎません。 2つのインスタンスを持つ1つのワーカープールに26のWebアプリケーションを持つ1つのApp Service Planを持つことができます。または3つのワーカープール(各プランは2つのインスタンスにまたがる)上の6つのAppサービスプラン。すべてあなた次第。 – evilSnobu