Sitios web de Azure

Arquitecto de la nube mediante sitios web de Azure

Apurva Joshi
Sunitha Muthukrishna

 

Hay una cosa importante que tener en cuenta a la hora de diseñar una solución de nube: diseñar siempre para los errores. Sin embargo, la arquitectura de muchas aplicaciones no se diseña de esta manera. El principal motivo de esto es una falta de conocimientos sobre cómo diseñar una arquitectura mediante Sitios web de Microsoft Azure que sea suficientemente resistente. Entonces, ¿cómo puedes crear una solución de nube lo suficientemente sólida como para soportar errores? En este artículo, hablaremos sobre las técnicas que puedes emplear para diseñar este tipo de sistema.

Instancia única de sitio web

Sitios web de Azure ofrece planes de hospedaje en varios niveles: Gratuito, Compartido, Básico y Estándar. Los niveles Gratuito y Compartido proporcionan sitios con una infraestructura compartida, lo que significa que tus sitios comparten los recursos con otros sitios. En los niveles Básico y Estándar, tus sitios se ofrecen con una infraestructura dedicada, lo que significa que en esos recursos solo se ejecutarán los sitios que eliges asociar con tu plan.

En estos niveles, puedes configurar tu plan de hospedaje web para usar una o más instancias de máquina virtual (VM). Estos niveles admiten instancias pequeñas, medianas y grandes. El proveedor administrará las VM por ti, lo que significa que nunca tendrás que preocuparte por las actualizaciones del SO o las actualizaciones de seguridad y configuración.

Para ejecutar un sitio web de nivel de producción en Sitios web de Azure, se recomiendan los niveles Básico o Estándar en función del tamaño de la aplicación y la cantidad de tráfico de tu sitio web. Comprender los requisitos de la aplicación es un buen punto de partida:

1. ¿Qué componentes necesita la aplicación? Base de datos, proveedor de correo electrónico, caché, etc.
2. ¿Qué componentes corren el riesgo de errores y necesitan replicación?
3. ¿Qué características necesitas? SSL, zonas de ensayo, etc.
4. ¿Qué cantidad de tráfico debería poder administrar el sitio web?

Con las respuestas a estas preguntas, puedes crear un único sitio web y agregar componentes, tales como base de datos y caché, a la aplicación según sea necesario. En la figura 1, se puede ver cómo podrías diseñar la arquitectura de un único sitio web y sus componentes dependientes.

En el escenario de un único sitio web, la mayor advertencia se presenta en el caso de una interrupción relacionada con el servicio de cualquier componente (sitio web, base de datos o servicio de caché). El sitio no estará disponible durante la interrupción, por lo que tus clientes y tu empresa se verán afectados.

Figura 1 Arquitectura estándar para un único sitio web

Este diseño no tiene en cuenta los riesgos que pueden surgir en las soluciones de nube ni tampoco incluye una manera de mitigarlos. En un entorno de nube, el objetivo de diseño debería ser crear un sitio web altamente disponible que minimiza los tiempos de inactividad y aceleran la recuperación durante una interrupción. 

El objetivo es la alta disponibilidad

Una pila típica de aplicación web en Sitios web de Azure consta de una aplicación web, una base de datos, Almacenamiento de Azure y alguna forma de memoria caché. Todos estos componentes están estrechamente asociados para evitar que un solo componente o una sola entidad se convierta en un único punto de error (SPOF). Se trata de un criterio de diseño clave de la arquitectura de cualquier solución de nube. Los objetivos son los siguientes:

• Evitar SPOF en el diseño
• Crear redundancia entre todas las capas del diseño

Sitios web de Azure proporciona un contrato de nivel de servicio (SLA) del 99,9 %. Esto significa que puedes esperar un tiempo de inactividad de unos 10 minutos por semana debido a implementaciones o actualizaciones programadas que realiza el servicio Sitios web de Azure. Aún así, 10 minutos de tiempo de inactividad puede afectar significativamente a tu empresa. Tu objetivo debería ser diseñar la solución para mitigar este tiempo de inactividad y poder prestar servicio a tus clientes y así reducir el riesgo de impacto. Tu objetivo debería ser diseñar una arquitectura web altamente disponible, tal como se muestra en la figura 2.

Figura 2 Ejemplo de una arquitectura web altamente disponible

Alta disponibilidad en la capa de aplicación web

Sitios web de Azure crea una solución de nube sin estado para la aplicación web. Tienes que tener en cuenta lo puntos siguientes a la hora de diseñar para alta disponibilidad en el nivel de aplicación:

1. Usa el modo Estándar para los sitios web y configúralo para que use al menos dos instancias del sitio web.
2. Según los patrones de tráfico, simula cargas para realizar pruebas a través de distintas herramientas, como Visual Studio y Apache JMeter (jmeter.apache.org) con el fin de identificar el tamaño de las instancias y el número de instancias que necesitarías para que el sitio web administre los niveles reales de tráfico.
3. Asegurarte de que los datos de usuario y sesión se almacenen en un sistema centralizado, tal como una base de datos a una capa de caché distribuida. En Servidor de archivos, el servidor de archivos se comparte entre todas las VM cuando se ejecuta en modo Estándar.
4. Replica la capa de aplicación web en al menos dos zonas compatibles con Sitios web de Azure.
5. El contenido de usuario, tales como archivos multimedia y documentos, que el sitio web carga o administra, debería almacenarse en una cuenta de Almacenamiento de Azure. Para reducir la latencia, asegúrate de que la cuenta de almacenamiento se encuentre en la misma región geográfica que el sitio web.
6. Sigue siempre prácticas de codificación segura para que la aplicación sea resistente contra ataques malintencionados.

Alta disponibilidad en la capa de base de datos

Los datos son lo que realmente generan valor para cualquier aplicación. Por tanto, tienes que administrarlos de manera eficaz. Para que la aplicación funcione correctamente, es sumamente importante evitar un único punto de error en la capa de base de datos. Sitio web de Azure admite los servicios Base de datos SQL de Azure y ClearDB MySQL. Ambos ofrecen opciones de soluciones desde nivel básico hasta soluciones Premium.

El servicio Premium de Base de datos SQL de Azure ofrece un rendimiento más previsible y una mayor capacidad de aplicaciones de nube mediante Sitios web de Azure. Dedica una cantidad fija de capacidad de reserva para una base de datos, incluidas sus características integradas de replicación de base de datos. La capacidad de reserva es ideal para lo siguiente:

• Carga máxima elevada: una aplicación que requiere una importante cantidad de CPU, memoria o procesamiento de E/S para completar sus operaciones es un buen candidatos para usar una base de datos Premium.
• Muchas solicitudes simultáneas: algunas aplicaciones de base de datos prestan servicio a varias solicitudes simultáneas. Las ediciones Web y Business normales de Base de datos SQL de Azure tienen un límite de 180 solicitudes simultáneas. Las aplicaciones que requieren más conexiones deben usar una base de datos Premium con un tamaño de reserva suficiente para controlar el número máximo de solicitudes.
• Latencia previsible: algunas aplicaciones necesitan garantizar una respuesta de la base de datos en un tiempo mínimo. Si se llama a un procedimiento almacenado determinado como parte de una operación de cliente más amplia, puede ser necesario volver de esa llamada en no más de 20 milisegundos el 99 % del tiempo. Este tipo de aplicación se beneficiará de una base de datos Premium para asegurarse de que haya capacidad de proceso disponible.

ClearDB ofrece enrutadores SQL (o CDBR) de alta disponibilidad de construcción inteligente que son administradores inteligentes de tráfico y que supervisan estos clústeres de base de datos. Cuando un nodo de base de datos no está en buen estado, CDBR se redirige automáticamente al maestro secundario. Esto ayuda a garantizar un tiempo de actividad para la base de datos y, a su vez, para la aplicación web. Al crear este diseño, ten en cuenta que existen emparejamientos de regiones recomendadas que ClearDB admite para este tipo de escenario. Por ejemplo:

1. Si eliges una base de datos en la zona este de Estados Unidos, la base de datos emparejada debería situarse en la zona oeste de Estados Unidos.
2. Si eliges una base de datos en el norte de Europa, la base de datos emparejada debería situarse en el sur de Europa.

Alta disponibilidad entre todas las regiones

Actualmente, Sitios web de Azure admite varias regiones. Además, se está trabajando en la ampliación de su infraestructura. Las arquitecturas que usan varias regiones se pueden clasificar en sitios web activos-activos y sitios web activos-pasivos.

Sitios web activos-activos: en una arquitectura web activa-activa, habrá varios sitios web entre distintas regiones que prestan servicio a la misma aplicación. En este caso, el tráfico se asigna entre todos los sitios web, por lo que todos se consideran activos.

Sitios web activos-pasivos: en una arquitectura activa-pasiva, habrá un único sitio web que funcionará como sitio web principal. Este proporcionará el contenido para todo el tráfico de cliente. Durante un error en este sitio, los clientes se redirigirán a otro sitio configurado y sincronizado con el sitio web principal en un centro de datos diferente. De este modo, se mitiga el error. 

A la hora de diseñar la arquitectura para el funcionamiento entre varias regiones, debes tener en cuenta algunos desafíos:

• Sincronización de datos: esto implica la capacidad de realizar una copia en tiempo real de la base de datos entre todas las regiones. Los sistemas complejos tendrán una base de datos, un servidor de archivos, almacenamiento externo y memoria caché, entre otros componentes. Al diseñar la arquitectura, debes asegurarte de que los datos que se repliquen entre varias regiones estén sincronizados para evitar la interrupción de la aplicación web. Esto puede requerir algunos cambios en el código de aplicación para admitir este tipo de escenario. Sincronización de datos admite la ejecución de un proceso de segundo plano llamado trabajos web, que te permite crear herramientas personalizadas para administrar la sincronización de datos.
• Flujo de red: esto implica la capacidad de administrar el tráfico de red entre varias regiones. Traffic Manager de Azure permite hacer el equilibrio de carga del tráfico entrante entre varios sitios web hospedados, ya sea que se ejecuten en el mismo centro de datos o entre centro de datos diferentes. Al administrar el tráfico de forma eficaz, puedes asegurar un alto rendimiento, disponibilidad y resistencia para las aplicaciones.

Puedes usar Traffic Manager para garantizar la alta disponibilidad y la capacidad de respuesta de tus aplicaciones. Traffic Manager ofrece tres métodos de equilibrio de carga:

1. Conmutación por error: usa este método cuando quieras usar un extremo principal para todo el tráfico, pero proporcionar una o más copias de seguridad en caso de que los extremos principales o de respaldo pierden disponibilidad.
2. Round Robin: con este método, puedes distribuir el tráfico de forma homogénea entre un conjunto de extremos en el mismo centro de datos o entre diferentes centros de datos.
3. Rendimiento: este método permite a los clientes o usuarios solicitantes usar el extremo más cercano para reducir la latencia al proporcionar extremos en ubicaciones geográficas distintas.

Alta disponibilidad para la capa de caché

Para mejorar el rendimiento de los sitios web, la capa de almacenamiento en caché es sumamente importante. Al gestionar los datos con la aplicación, debes comprender cómo el almacenar en caché puede afectar a los datos y a la aplicación. A la hora de elegir la capa de caché, ten en cuenta la necesidad de conservar la coherencia de los datos que se almacenan entre las distintas instancias de caché. Para evitar datos incoherentes, deberías usar un mecanismo de almacenamiento en caché distribuida. Una memoria caché distribuida puede usar varios servidores, por lo que es escalable y almacena los datos de aplicación que residen en la base de datos al reducir el número de llamadas que se hacen a la base de datos.

Hay varias soluciones de almacenamiento en caché basadas en la nube que puedes integrar con Sitios web de Azure, tales como Azure Cache y Memcached Cloud. Estas soluciones están disponibles a través de la Tienda Azure en el Portal de administración de Azure.

Supervisión del rendimiento

Ahora que conoces las estrategias de alta disponibilidad para tus sitios web, tendrás que evaluar las opciones de supervisión. Sitios web de Azure ofrece dos tipos de supervisión en el Portal de administración de Azure:

1. Supervisión con métricas de sitio web: cada panel del sitio web dispone de una página de supervisión. Esto proporciona estadísticas de rendimiento para cada sitio, tales como el uso de la CPU, el número de solicitudes, los datos que envía el sitio web, etc.
2. Supervisión del extremo: permite configurar pruebas web desde ubicaciones distribuidas geográficamente que prueban el tiempo de respuesta y el tiempo de actividad de las direcciones URL. Todas las ubicaciones configuradas ejecutan una prueba cada cinco minutos. El tiempo de actividad se supervisa mediante códigos de respuesta HTTP. El tiempo de respuesta se mide en milisegundos. El tiempo de respuesta se considera como 100 % cuando es menos de 30 segundos y el código de estado HTTP es menos de 400. El tiempo de respuesta es del 0 % cuando es mayor que 30 segundos o el código de estado HTTP es mayor que 400. Después de configurar la supervisión de extremos, puede obtener detalles sobre los extremos individuales para ver los detalles del tiempo de respuesta y el estado de tiempo de actividad sobre el intervalo de supervisión desde cada una de las ubicaciones de prueba.

Puedes hacer una supervisión más detallada y flexible mediante el Portal de Azure en vista previa. Aquí, puedes crear un panel de DevOps completo. En la figura 3 se muestra el aspecto de un panel de DevOps cuando se ejecuta en Sitios web de Azure.

Figura 3 Un panel de DevOps típico

Al desarrollar soluciones para la nube, la planificación de la aplicación, el desarrollo y las pruebas suelen realizarse en otro lugar, tal como Visual Studio Online. La supervisión de la condición de dichas aplicaciones y la solución de problemas podrían hacerse en otro portal, tal como Application Insights. La facturación se muestra en una página independiente. ¿Observas un patrón aquí?

Este nuevo portal reúne todos los recursos de nube, miembros de equipo de trabajo y etapas del ciclo de vida de la aplicación. Te ofrece un lugar centralizado para planificar, desarrollar, probar, aprovisionar, implementar, escalar y supervisar esas aplicaciones. Este método puede ayudar a los equipos de trabajo a adoptar una cultura de DevOps al unir las capacidades y perspectivas de desarrollo y operaciones de manera significativa. Puedes obtener más información al respecto en el artículo de blog sobre cómo crear el panel de DevOps de tus sueños con el nuevo Portal de Azure en vista previa en bit.ly/1sYNRtK.

Opciones de recuperación

A veces, cosas malas suceden a aplicaciones buenas. Sitios web de Azure puede ayudarte a recuperar automáticamente de los errores de aplicación. Típicamente, cuando el sistema de supervisión detecta un problema, avisa al técnico de operaciones de alguna forma. El técnico de operaciones luego reinicia el sitio web y hace que las cosas vuelvan a la normalidad.

Puedes configurar el archivo web.config de la aplicación para detectar situaciones y reaccionar según corresponda. Por ejemplo, si X número de solicitudes tardan Y cantidad de tiempo para su ejecución en Z cantidad de tiempo, toma la medida ABC (que podría implicar el reinicio del sitio web, el registro de un evento o la ejecución de una acción personalizada). Otro ejemplo podría ser si un proceso que consume X cantidad de memoria, se debe tomar la medida ABC. Puedes obtener más información sobre los procedimientos de recuperación en el blog de Microsoft Azure en bit.ly/LOSEvS.

Si bien las arquitecturas con redundancia geográfica ofrecen protección contra errores relacionados con la infraestructura, las características como, por ejemplo, la recuperación automática, ayudan a crear resistencia en la capa de la aplicación. En el mundo de la informática en nube, los clientes siempre desean recuperar primero en lugar de hacer diagnósticos completos mientras el sitio web esté fuera de servicio. Por otro lado, existen otras situaciones y otros escenarios en los que los diagnósticos son fundamentales.

Herramientas de diagnóstico

Los diagnósticos son similares a pelar las capas de una cebolla semipodrida. Nunca se sabe cuántas capas tendrás que eliminar. Sitios web de Azure es una plataforma como servicio (PaaS) de varios inquilinos y administración completa y, por tanto, no admite diagnósticos remotos en la VM. Esto implica un nuevo conjunto de desafíos. Aquí ofrecemos una lista de herramientas disponibles y los escenarios de diagnósticos para los que sirven.

De manera predeterminada, este servicio proporciona distintos tipos de registros que ayudan en la solución de problemas. Algunos de los registros incluyen registros de servidor web, registros de errores detallados, seguimiento de solicitudes con error, etc. Puedes obtener más información sobre los servicios de registro en bit.ly/1i0MSou.

La consola Kudu es otro tipo de herramienta de diagnóstico. Se trata del extremo de administración de configuración de software multipropósito que los clientes usarán con frecuencia para realizar diagnósticos. Tras iniciar sesión en el extremo Kudu, verás distintas opciones de diagnóstico en la cinta superior (consulta la figura 4).

Figura 4 La consola Kudu ofrece herramientas de diagnóstico

En la pestaña Entorno se ofrece una vista de solo lectura de elementos como, por ejemplo, información del sistema, configuración de aplicaciones, cadenas de conexión, variables de entorno, rutas de acceso del sistema, encabezados HTTP y variables de servidor, específicos a tu sitio web y máquinas virtuales. Esto siempre funciona bien como ayuda para la investigación continua con puntos de datos diferentes.  

La pestaña Consola de depuración proporciona acceso a los sitios a través de una consola de ejecución remota o explorador de archivos basados en CMD o Windows PowerShell. Puedes usar la consola para realizar la mayoría de las operaciones de consola estándares los comandos externos arbitrarios, por ejemplo, comandos Git, así como navegar por la IU de la carpeta, descargar archivos y carpetas, cargar archivos y carpetas mediante arrastrar y soltar, ver y editar archivos, etc. Puedes obtener más información al respecto al visualizar el vídeo de YouTube sobre la consola de diagnóstico de Sitios web de Azure en bit.ly/1h0ZZoR.

La pestaña Explorador de procesos te ofrece una lista de procesos activos que la aplicación puede ver y con la que se puede comunicar en el espacio aislado de Sitios web de Azure. Esta vista proporciona información sobre el uso de la memoria y la CPU del proceso. También puedes consultar información detallada sobre un proceso dado, generar y descargar volcados de memoria completos para realizar diagnósticos sin conexión, etc.

La pestaña Volcado de diagnóstico te ofrece un volcado de memoria en un archivo .zip que puedes descargar. Luego, puedes usar un analizador de volcados, como DebugDiag, para analizar rápidamente el volcado de memoria y obtener ayuda sobre la perspectiva.

La pestaña Flujo de registro permite hacer streaming de registros HTTP o de aplicación directamente en la consola. Esto es de utilidad para la solución de problemas de un tema activo. Puedes obtener más información al respecto si consultas el artículo de blog de Scott Hanselman sobre el streaming de registros de seguimiento de diagnósticos desde la línea de comandos de (más un vistazo) en bit.ly/1jXwy7q.

Esto es lejos de ser es una lista exhaustiva de herramientas de diagnóstico. Microsoft tiene previsto crear diagnósticos más sofisticados en los que algunos de los escenarios que se usan con más frecuencia necesitarán tan solo un clic. Hasta entonces, disfruta de la creación de buenas aplicaciones resistentes a los errores.

Apurva Joshi es gerente de programación sénior en Microsoft y trabaja en el equipo de trabajo de Sitios web de Azure. Se unió a Microsoft en 2002 y ha trabajado en distintas tecnologías web como, por ejemplo, IIS y ASP.NET.

Sunitha Muthukrishna es gerente de programación en Microsoft que trabaja en el equipo de trabajo de Sunitha Muthukrishna. Se unió a Microsoft en 2011 y ha estado trabajando en la Galería de aplicaciones web de Windows y en Sitios web de Azure. Anteriormente, contribuyó a proyectos de TI para algunas de organizaciones sin fines de lucro, tales como la red Community Empowerment y el Instituto de Biología de Sistemas, ambos situados en Seattle, Wash.

Gracias a los siguientes expertos técnicos por revisar este artículo: Equipo de administración de producción de Microsoft Azure