Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los escenarios de aplicación que requieren una escala muy alta pueden superar la capacidad de recursos de proceso disponible para una sola implementación de una aplicación. Las aplicaciones de votación, los eventos deportivos y los eventos de entretenimiento televisados son ejemplos de escenarios que requieren una escala extremadamente alta. Los requisitos de escalado alto se pueden cumplir mediante el escalado horizontal de aplicaciones. Para controlar los requisitos de carga extremos, se pueden realizar muchas implementaciones de aplicaciones dentro de una sola región y entre regiones.
Información general
App Service Environments es una plataforma ideal para el escalado horizontal. Después de seleccionar una configuración de App Service Environment que pueda admitir una tasa de solicitudes conocida, los desarrolladores pueden implementar entornos de App Service adicionales de forma "cortador de cookies" para lograr una capacidad de carga máxima deseada.
Nota:
Si quiere empezar a trabajar con Azure App Service antes de registrarse en una cuenta de Azure, vaya a Probar App Service, donde puede crear inmediatamente una aplicación web de inicio de corta duración en App Service. No se requieren tarjetas de crédito; sin compromisos.
Por ejemplo, supongamos que se ha probado una aplicación que se ejecuta en una configuración de App Service Environment para controlar 20 000 solicitudes por segundo (RPS). Si la capacidad de carga máxima deseada es 100 K RPS, se pueden crear y configurar cinco (5) Entornos de App Service para asegurarse de que la aplicación pueda controlar la carga máxima proyectada.
Dado que los clientes suelen acceder a las aplicaciones mediante un dominio personalizado (o vanidad), los desarrolladores necesitan una manera de distribuir las solicitudes de aplicación en todas las instancias de App Service Environment. Una excelente manera de lograr este objetivo es resolver el dominio personalizado mediante un perfil de Azure Traffic Manager. El perfil de Traffic Manager se puede configurar para que apunte a todos los entornos individuales de App Service. Traffic Manager controlará automáticamente la distribución de clientes en todos los entornos de App Service, en función de la configuración de equilibrio de carga en el perfil de Traffic Manager. Este enfoque funciona independientemente de si todos los entornos de App Service se implementan en una sola región de Azure o se implementan en todo el mundo en varias regiones de Azure.
Además, dado que los clientes acceden a las aplicaciones a través del dominio de vanidad, los clientes no conocen el número de entornos de App Service que ejecutan una aplicación. Como resultado, los desarrolladores pueden agregar y quitar de forma rápida y sencilla entornos de App Service en función de la carga de tráfico observada.
En el diagrama conceptual siguiente se muestra una aplicación escalada horizontalmente en tres entornos de App Service dentro de una sola región.
El resto de este artículo le guía por los pasos necesarios para configurar una topología distribuida para la aplicación de ejemplo mediante varios entornos de App Service.
Planificación de la topología
Antes de crear una superficie de aplicación distribuida, ayuda a tener unas pocas partes de información con antelación.
-
Dominio personalizado para la aplicación: ¿Cuál es el nombre de dominio personalizado que los clientes usarán para acceder a la aplicación? Para la aplicación de ejemplo, el nombre de dominio personalizado es
www.asabuludemo.com. - Dominio de Traffic Manager: Elija un nombre de dominio al crear un perfil de Azure Traffic Manager. Este nombre se combinará con el sufijo trafficmanager.net para registrar una entrada de dominio administrada por Traffic Manager. Para la aplicación de ejemplo, el nombre elegido es scalable-ase-demo. Como resultado, el nombre de dominio completo administrado por Traffic Manager es scalable-ase-demo.trafficmanager.net.
- Estrategia para escalar la superficie de la aplicación: ¿Se distribuirá la superficie de la aplicación entre varios entornos de App Service en una sola región? ¿Varias regiones? ¿Una combinación y coincidencia de ambos enfoques? Base la decisión sobre las expectativas de dónde se originará el tráfico del cliente y el resto de la infraestructura de back-end que admite una aplicación. Por ejemplo, con una aplicación sin estado de 100%, una aplicación se puede escalar masivamente mediante una combinación de muchos entornos de App Service en cada región de Azure, multiplicados por entornos de App Service implementados en muchas regiones de Azure. Con más de 15 regiones globales de Azure disponibles para elegir, los clientes pueden crear realmente una superficie de aplicación a gran escala en todo el mundo. Para la aplicación de ejemplo que se usa para este artículo, se crearon tres entornos de App Service en una sola región de Azure (Centro-sur de EE. UU.).
- Convención de nomenclatura para los entornos de App Service: Cada instancia de App Service Environment requiere un nombre único. Más allá de uno o dos entornos de App Service, resulta útil tener una convención de nomenclatura para ayudar a identificar cada instancia de App Service Environment. Para la aplicación de ejemplo, se usó una convención de nomenclatura simple. Los nombres de las tres instancias de App Service Environment son fe1ase, fe2ase y fe3ase.
- Convención de nomenclatura para las aplicaciones: Dado que se implementarán varias instancias de la aplicación, se necesita un nombre para cada instancia de la aplicación implementada. Una característica poco conocida pero cómoda de App Service Environments es que se puede usar el mismo nombre de aplicación en varios entornos de App Service. Dado que cada instancia de App Service Environment tiene un sufijo de dominio único, los desarrolladores pueden optar por reutilizar exactamente el mismo nombre de aplicación en cada entorno. Por ejemplo, un desarrollador podría tener aplicaciones denominadas de la siguiente manera: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net, etc. Sin embargo, para la aplicación de ejemplo, cada instancia de aplicación también tiene un nombre único. Los nombres de instancia de la aplicación usados son webfrontend1, webfrontend2 y webfrontend3.
Configuración del perfil de Traffic Manager
Una vez implementadas varias instancias de una aplicación en varios entornos de App Service, las instancias de aplicación individuales se pueden registrar con Traffic Manager. Para la aplicación de ejemplo, se necesita un perfil de Traffic Manager para scalable-ase-demo.trafficmanager.net que pueda enrutar a los clientes a cualquiera de las siguientes instancias de aplicación implementadas:
- webfrontend1.fe1ase.p.azurewebsites.net: Instancia de la aplicación de ejemplo implementada en la primera instancia de App Service Environment.
- webfrontend2.fe2ase.p.azurewebsites.net: Instancia de la aplicación de ejemplo implementada en la segunda instancia de App Service Environment.
- webfrontend3.fe3ase.p.azurewebsites.net: Instancia de la aplicación de ejemplo implementada en la tercera instancia de App Service Environment.
La manera más fácil de registrar varios puntos de conexión de Azure App Service, todos los que se ejecutan en la misma región de Azure, es con la compatibilidad con Traffic Manager de Azure Resource Manager de PowerShell.
El primer paso es crear un perfil de Azure Traffic Manager. El código siguiente muestra cómo se creó el perfil para la aplicación de ejemplo:
$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName yourRGNameHere -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"
Observe cómo se estableció el parámetro RelativeDnsName en scalable-ase-demo. Este parámetro hace que se cree el nombre de dominio scalable-ase-demo.trafficmanager.net y se asocie a un perfil de Traffic Manager.
El parámetro TrafficRoutingMethod define la directiva de equilibrio de carga que usará Traffic Manager para determinar cómo distribuir la carga del cliente en todos los puntos de conexión disponibles. En este ejemplo, se eligió el método Weighted . Debido a esta elección, las solicitudes de cliente se distribuirán entre todos los puntos de conexión de aplicación registrados en función de los pesos relativos asociados a cada punto de conexión.
Con el perfil creado, cada instancia de aplicación se agrega al perfil como punto de conexión nativo de Azure. El código siguiente captura una referencia a cada aplicación web de front-end. A continuación, agrega cada aplicación como punto de conexión de Traffic Manager a través del parámetro 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
Observe cómo hay una llamada a Add-AzureTrafficManagerEndpointConfig para cada instancia de aplicación individual. El parámetro TargetResourceId de cada comando de PowerShell hace referencia a una de las tres instancias de aplicación implementadas. El perfil de Traffic Manager se distribuirá entre los tres puntos de conexión registrados en el perfil.
Los tres puntos de conexión usan el mismo valor (10) para el parámetro Weight . Esta situación da lugar a que Traffic Manager extienda las solicitudes de los clientes entre las tres instancias de la aplicación relativamente uniformemente.
Apuntar al dominio personalizado de la aplicación en el dominio de Traffic Manager
El último paso necesario es apuntar al dominio personalizado de la aplicación en el dominio de Traffic Manager. Para la aplicación de ejemplo, apunte www.asabuludemo.com a scalable-ase-demo.trafficmanager.net. Complete este paso con el registrador de dominios que administra el dominio personalizado.
Mediante las herramientas de administración de dominios del registrador, cree un registro CNAME que apunte al dominio personalizado en el dominio de Traffic Manager. En la imagen siguiente se muestra un ejemplo del aspecto de esta configuración de CNAME:
Aunque no se trata en este tema, recuerde que cada instancia de aplicación individual debe tener también el dominio personalizado registrado con él. De lo contrario, si una solicitud la realiza a una instancia de aplicación y la aplicación no ha registrado el dominio personalizado con la aplicación, se producirá un error en la solicitud.
En este ejemplo, el dominio personalizado es www.asabuludemo.comy cada instancia de aplicación tiene asociado el dominio personalizado.
Para obtener un resumen del registro de un dominio personalizado con aplicaciones de Azure App Service, consulte Registro de dominios personalizados.
Probar la topología distribuida
El resultado final de la configuración de Traffic Manager y DNS es que las solicitudes de www.asabuludemo.com fluirán a través de la siguiente secuencia:
- Un explorador o dispositivo realizará una búsqueda dns para
www.asabuludemo.com - La entrada CNAME en el registrador de dominios hace que la búsqueda DNS se redirija a Azure Traffic Manager.
- Se realiza una búsqueda DNS para scalable-ase-demo.trafficmanager.net en uno de los servidores DNS de Azure Traffic Manager.
- En función de la directiva de equilibrio de carga especificada anteriormente en el parámetro TrafficRoutingMethod , Traffic Manager selecciona uno de los puntos de conexión configurados. A continuación, devuelve el FQDN de ese punto de conexión al explorador o dispositivo.
- Dado que el FQDN del punto de conexión es la dirección URL de una instancia de aplicación que se ejecuta en un entorno de App Service, el explorador o el dispositivo pedirán a un servidor DNS de Microsoft Azure que resuelva el FQDN en una dirección IP.
- El explorador o dispositivo enviará la solicitud HTTP/S a la dirección IP.
- La solicitud llegará a una de las instancias de la aplicación que se ejecutan en uno de los entornos de App Service.
En la imagen de consola siguiente se muestra una búsqueda DNS para el dominio personalizado de la aplicación de ejemplo. Se resuelve correctamente en una instancia de aplicación que se ejecuta en uno de los tres entornos de App Service de ejemplo (en este caso, el segundo de los tres entornos de App Service):
