Implementación del escalado por aplicación para hospedaje de alta densidad

Nota:

Se recomienda usar el módulo de PowerShell de Azure Az para interactuar con Azure. Para comenzar, consulte Instalación de Azure PowerShell. Para obtener información sobre cómo migrar al módulo Az PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Puede escalar las aplicaciones de Azure App Service mediante el escalado del plan de App Service en el que se ejecutan. Por defecto, la propiedad perSiteScaling del plan es false, y cada aplicación y ranura de implementación utiliza todas las instancias disponibles del plan.

Cuando perSiteScaling es true, cada aplicación y espacio de despliegue puede tener su propio siteConfig.numberOfWorkers límite. Por ejemplo, un plan puede tener una capacidad configurada de 10 trabajadores mientras que una aplicación tiene un límite configurado de cinco trabajadores. Cada ranura de despliegue tiene su propio límite; configurar la aplicación de producción no configura también sus ranuras.

Nota:

El escalado por aplicación solo está disponible para los planes de tarifa Estándar, Premium, Premium V2, Premium V3 y Aislado .
Un límite por aplicación no reduce la capacidad dedicada configurada para el plan de App Service ni su facturación por sí sola.

Mantén estos valores distintos:

Capacidad configurada del plan: El valor de sku.capacity del plan.
Límite de aplicación o de trabajadores de slot configurados: El valor del siteConfig.numberOfWorkers recurso.
Instancias de aplicaciones activas observadas: Una observación puntual del tiempo de ejecución. El número real no puede superar el número de trabajadores disponibles del plan. La integración gradual del plan puede reducir este recuento por debajo del límite configurado de aplicaciones o franjas.

La plataforma coloca una aplicación en distintos empleados disponibles mediante un enfoque de mejor esfuerzo. El posicionamiento es independiente de la métrica.

Scenario	Semántica de valores
Límite de `1`	La app o la franja pueden usar como máximo un trabajador disponible del plan. Elige este valor solo cuando la asignación de un solo trabajador sea aceptable para la carga de trabajo.
Límite mayor que `1`	El valor limita cuántos trabajadores distintos del plan puede usar la aplicación o la ranura de implementación. Las instancias activas reales pueden ser menos.
Límite superior a la capacidad disponible del plan	Las instancias de trabajo disponibles del plan determinan el límite real de las instancias de la aplicación o de la ranura.
Planificar la reducción de escala	La aplicación o franja puede ejecutarse con menos trabajadores de los que ha sido configurado una vez que se eliminan los trabajadores del plan.

El escalado por aplicación se basa en una asignación fija, independiente de las métricas, dentro de los trabajadores disponibles del plan. No responde a la demanda ni cambia la capacidad del plan. Para cambiar la capacidad según la demanda, utiliza escalado automático o Azure Monitor autoescalado.

Importante

La redundancia por zonas distribuye instancias del plan de servicios de aplicaciones; no crea réplicas ocultas de apps. Con el escalado por aplicación, un límite de aplicación o de ranura de 1 permite la implementación en como máximo una instancia del plan y no debe tratarse como una réplica simultánea entre zonas. Límites de 2 o superiores permiten la ubicación en varios procesos de trabajo distintos del plan, pero no ofrecen una garantía pública de que esas instancias de la aplicación se distribuyan entre varias zonas físicas. Para orientación sobre diseño de fiabilidad, véase Fiabilidad en Servicios de Aplicaciones.

Modelo de propiedad y requisitos previos

Utiliza un nivel de precios soportado, una cuenta que pueda actualizar el plan, la app y la franja, y la versión actual de la herramienta que elijas. Los ejemplos utilizan CLI de Azure 2.89.1 y Az PowerShell 16.2.0.

Ámbito	Propiedad de recurso	Ejemplo
Función de plan	`properties.perSiteScaling`	`true`
Planeamiento de la capacidad	`sku.capacity`	`10`
Límite deseado por la app	`properties.siteConfig.numberOfWorkers`	`5`
Límite deseado de ranura	`properties.siteConfig.numberOfWorkers`	`2`
Configuración de la app o ranura GET respuesta	`properties.numberOfWorkers`	`5` o `2`

En CLI de Azure, las opciones con nombres similares tienen alcances distintos: az appservice plan ... --number-of-workers establece la capacidad del plan, mientras que az webapp config set ... --number-of-workers establece el límite de la aplicación o de la ranura.

Configurar el escalado por aplicación

Usa la pestaña de tu herramienta preferida. Sustituye los nombres y ubicaciones provisionales antes de ejecutar un comando o desplegar una plantilla.

Elige entre el paso de creación o el de actualización para el plan. El paso de actualización solo cambia perSiteScaling; no cambia la capacidad del plan existente.

resourceGroup='<resource-group-name>'
planName='<app-service-plan-name>'
appName='<app-name>'
slotName='staging'
location='westus3'

# Create a plan with capacity 10 and per-app scaling.
az appservice plan create \
    --resource-group $resourceGroup \
    --name $planName \
    --location $location \
    --sku P1V3 \
    --number-of-workers 10 \
    --per-site-scaling

# Or enable per-app scaling on an existing plan without changing its capacity.
az appservice plan update \
    --resource-group $resourceGroup \
    --name $planName \
    --set properties.perSiteScaling=true

# Configure the production app and its staging slot independently.
az webapp config set \
    --resource-group $resourceGroup \
    --name $appName \
    --number-of-workers 5

az webapp config set \
    --resource-group $resourceGroup \
    --name $appName \
    --slot $slotName \
    --number-of-workers 2

Aquí, el plan --number-of-workers 10 es la capacidad. La opción de configuración de la aplicación web con el mismo nombre corresponde al límite deseado de aplicaciones o ranuras. Inspecciona los valores configurados:

az appservice plan show \
    --resource-group $resourceGroup \
    --name $planName \
    --query "{planCapacity:sku.capacity, perSiteScaling:perSiteScaling}"

az webapp config show \
    --resource-group $resourceGroup \
    --name $appName \
    --query "{appWorkerLimit:numberOfWorkers}"

az webapp config show \
    --resource-group $resourceGroup \
    --name $appName \
    --slot $slotName \
    --query "{slotWorkerLimit:numberOfWorkers}"

Para obtener más información sobre los comandos, consulta az appservice plan y az webapp config.

Elige Set-AzAppServicePlan o New-AzAppServicePlan. Cuando Set-AzAppServicePlan cambie la configuración del plan, repite -PerSiteScaling $true explícitamente para que el estado previsto de la función quede claro.

$ResourceGroup = '<resource-group-name>'
$AppServicePlan = '<app-service-plan-name>'
$WebApp = '<app-name>'
$Slot = 'staging'
$Location = 'westus3'

# Create a plan with capacity 10 and per-app scaling.
New-AzAppServicePlan -ResourceGroupName $ResourceGroup `
    -Name $AppServicePlan `
    -Location $Location `
    -Tier PremiumV3 `
    -WorkerSize Small `
    -NumberofWorkers 10 `
    -PerSiteScaling $true

# Or set the intended capacity and feature state on an existing plan.
Set-AzAppServicePlan -ResourceGroupName $ResourceGroup `
    -Name $AppServicePlan `
    -NumberofWorkers 10 `
    -PerSiteScaling $true

Set-AzWebApp -ResourceGroupName $ResourceGroup `
    -Name $WebApp `
    -NumberOfWorkers 5

Set-AzWebAppSlot -ResourceGroupName $ResourceGroup `
    -Name $WebApp `
    -Slot $Slot `
    -NumberOfWorkers 2

Utiliza los cmdlets correspondientes Get para inspeccionar los valores del plano, la app y las ranuras:

$Plan = Get-AzAppServicePlan -ResourceGroupName $ResourceGroup -Name $AppServicePlan
[pscustomobject]@{
    PlanCapacity = $Plan.Sku.Capacity
    PerSiteScaling = $Plan.PerSiteScaling
}

(Get-AzWebApp -ResourceGroupName $ResourceGroup -Name $WebApp).SiteConfig.NumberOfWorkers
(Get-AzWebAppSlot -ResourceGroupName $ResourceGroup -Name $WebApp -Slot $Slot).SiteConfig.NumberOfWorkers

Para detalles de cmdlet, véase New-AzAppServicePlan, Set-AzAppServicePlan y Set-AzWebApp.

Este archivo de Bicep crea un plan, una aplicación y una ranura de ensayo con valores de ejemplo.

param location string = resourceGroup().location
param appServicePlanName string
param appName string

resource appServicePlan 'Microsoft.Web/serverfarms@2024-11-01' = {
  name: appServicePlanName
  location: location
  sku: {
    name: 'P1v3'
    tier: 'PremiumV3'
    capacity: 10
  }
  properties: {
    perSiteScaling: true
  }
}

resource app 'Microsoft.Web/sites@2024-11-01' = {
  name: appName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      numberOfWorkers: 5
    }
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2024-11-01' = {
  parent: app
  name: 'staging'
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      numberOfWorkers: 2
    }
  }
}

Guarda el archivo como main.bicep, compílalo con az bicep build --file main.bicep, y desplázalo con az deployment group create --resource-group <resource-group-name> --template-file main.bicep. Una compilación exitosa valida la sintaxis y los tipos de recursos; inspecciona los valores configurados tras el despliegue. Para definiciones de recursos, consulte planes de servicios de aplicaciones, aplicaciones y ranuras de despliegue.

Esta plantilla ARM define el mismo plan, aplicación y slot de ensayo. La app depende del plan y la franja de su app principal.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    },
    "appServicePlanName": {
      "type": "string"
    },
    "appName": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2024-11-01",
      "name": "[parameters('appServicePlanName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "capacity": 10
      },
      "properties": {
        "perSiteScaling": true
      }
    },
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2024-11-01",
      "name": "[parameters('appName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', parameters('appServicePlanName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('appServicePlanName'))]",
        "siteConfig": {
          "numberOfWorkers": 5
        }
      }
    },
    {
      "type": "Microsoft.Web/sites/slots",
      "apiVersion": "2024-11-01",
      "name": "[format('{0}/{1}', parameters('appName'), 'staging')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', parameters('appName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('appServicePlanName'))]",
        "siteConfig": {
          "numberOfWorkers": 2
        }
      }
    }
  ]
}

Guarda la plantilla como azuredeploy.json, validala con az deployment group validate --resource-group <resource-group-name> --template-file azuredeploy.json, y luego desplázala con az deployment group create --resource-group <resource-group-name> --template-file azuredeploy.json. La validación y el despliegue requieren un contexto de Azure; El análisis JSON por sí solo no valida los recursos contra tu suscripción. Para detalles del esquema, consulta Planes de Servicio de Aplicaciones, aplicaciones y ranuras de despliegue.

Utiliza el endpoint de Azure Resource Manager para tu nube como {managementEndpoint}. Para Azure público, este valor es https://management.azure.com; otras nubes usan su propio punto final.

Un plan PUT es una solicitud completa de creación o actualización. Incluye la ubicación del plano, SKU, capacidad y propiedades; no envíes la siguiente solicitud como una actualización solo para propiedades.

PUT {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/serverfarms/{planName}?api-version=2024-11-01
Content-Type: application/json

{
  "location": "westus3",
  "sku": {
    "name": "P1v3",
    "tier": "PremiumV3",
    "capacity": 10
  },
  "properties": {
    "perSiteScaling": true
  }
}

Para un plano existente, se utiliza un parcial PATCH para cambiar solo la propiedad escalar mostrada:

PATCH {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/serverfarms/{planName}?api-version=2024-11-01
Content-Type: application/json

{
  "properties": {
    "perSiteScaling": true
  }
}

Para la aplicación de producción, actualiza y lee el recurso config/web:

PATCH {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/config/web?api-version=2024-11-01
Content-Type: application/json

{
  "properties": {
    "numberOfWorkers": 5
  }
}

GET {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/config/web?api-version=2024-11-01

Para la ranura de ensayo, incluye /slots/{slotName} en la ruta del recurso:

PATCH {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/slots/{slotName}/config/web?api-version=2024-11-01
Content-Type: application/json

{
  "properties": {
    "numberOfWorkers": 2
  }
}

GET {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/sites/{appName}/slots/{slotName}/config/web?api-version=2024-11-01

Lee el plan con GET {managementEndpoint}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Web/serverfarms/{planName}?api-version=2024-11-01. Las solicitudes escalares PATCH parciales son seguras para los campos mostrados porque se conservan los ajustes omitidos. Para detalles de operación, consulte la referencia de la API REST de App Service.

Comprobación de la configuración

Comprueba cada valor configurado tras un cambio o despliegue.

Value	Ejemplo esperado	Dónde comprobar
Función de plan	`true`	Respuesta del plan `properties.perSiteScaling`
Planeamiento de la capacidad	`10`	Respuesta del plan `sku.capacity`
Límite deseado de la aplicación de producción	`5`	Respuesta de producción `config/webproperties.numberOfWorkers`
Límite deseado del slot de preproducción	`2`	Respuesta de ranura `config/webproperties.numberOfWorkers`

Estos valores son configuración, no conteos de instancias activas observadas. La asignación en tiempo de ejecución se realiza en la medida de lo posible y está limitada por los recursos de trabajo disponibles del plan. Antes de combinar el escalado por aplicación con la redundancia de zona, consulta la capacidad del plan y el límite de cada aplicación o ranura en Configurar la redundancia de zona para un plan de App Service existente.

Configura alojamiento de alta densidad para tu escenario

La escalada por aplicación está disponible tanto en regiones globales de Azure como en entornos de servicios de aplicaciones. Elige límites de aplicaciones y espacios según la capacidad de carga y los requisitos de fiabilidad, en lugar de aplicar un límite a cada carga de trabajo.

Para un escenario de alojamiento de alta densidad:

Designe un plan de App Service como plan de alta densidad y escálelo horizontalmente a la capacidad deseada.
Establezca la marca PerSiteScaling en true en el plan de App Service.
Establece el límite de numberOfWorkers de cada aplicación y ranura de despliegue según sus necesidades.
- Un límite de 1 proporciona la mayor densidad, pero úselo solo para cargas de trabajo en las que sea aceptable la asignación a como máximo una instancia de trabajo del plan.
- Utilice un límite de 2 o más cuando la carga de trabajo debería ser elegible para ser asignada a varios trabajadores distintos del plan, sujeto a la capacidad disponible del plan.
Revisa los límites de forma independiente a medida que cambien los requisitos de carga de trabajo. Por ejemplo, una app de mayor uso puede usar un límite de 3 para mayor capacidad de procesamiento, mientras que otra app puede usarse 1 cuando es apropiado que se coloque a un solo trabajador.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-08-31