Sondas de estado y degradación controlada

Los sondeos de estado son el mecanismo mediante el cual los equilibradores de carga y los administradores de tráfico detectan si una instancia de backend puede atender solicitudes. Sin sondeos de estado, un equilibrador de carga podría seguir enviando tráfico a un servidor que ha fallado o no responde, lo que provocaría errores visibles para los usuarios. Unos sondeos de estado configurados correctamente permiten el redireccionamiento automático del tráfico lejos de las instancias en mal estado en cuestión de segundos tras un fallo.

Azure Load Balancer admite dos tipos de sondeos de estado:

• Sondeo TCP: comprueba si el backend puede aceptar una conexión TCP en un puerto especificado. Es sencillo, pero no verifica la lógica de la aplicación.
• Sondeo HTTP/HTTPS: envía una solicitud GET a una ruta especificada y espera una respuesta 200 OK. Es más preciso porque prueba directamente el punto de conexión de la aplicación.

Un backend se marca como no saludable si el sondeo falla durante un número configurable de intentos consecutivos.

Un punto de conexión de estado bien diseñado (/health) hace más que devolver 200 OK: verifica que se pueda acceder a las dependencias críticas de la aplicación. Una comprobación de estado completa podría probar la conectividad con la base de datos, la caché y cualquier API posterior. Si alguna dependencia no está disponible, el punto de conexión devuelve un código de estado 5xx, lo que indica al equilibrador de carga que debe retirar esta instancia de la rotación.

Azure Traffic Manager también usa sondeos de estado, pero en el nivel regional. Envía periódicamente solicitudes GET HTTP o HTTPS a la URL del punto de conexión configurado en cada región. Si un punto de conexión no responde dentro del intervalo de tiempo de espera durante un número determinado de intervalos consecutivos, Traffic Manager lo marca como degradado y deja de dirigirle consultas DNS, redirigiendo a los usuarios a una región saludable.

Azure Application Gateway ofrece funciones de sondeo de estado más avanzadas que el Load Balancer estándar. Admite sondeos personalizados que especifican el encabezado de host, el intervalo de códigos de estado esperado (por ejemplo, 200-399) y una cadena que debe coincidir con el cuerpo. Application Gateway también admite el enrutamiento por ruta, por lo que distintos grupos de backends pueden tener configuraciones de sondeo de estado diferentes para distintas rutas URL.

La degradación gradual es la capacidad de una aplicación para seguir proporcionando una funcionalidad parcial cuando una o varias de sus dependencias fallan. En lugar de bloquearse por completo, la aplicación detecta que un servicio no crítico no está disponible y recurre a un estado degradado, pero aún útil. Por ejemplo, si falla un servicio de recomendaciones, un sitio de comercio electrónico podría mostrar sugerencias genéricas en lugar de bloquear toda la página del producto.

El patrón de disyuntor evita que una aplicación llame repetidamente a un servicio descendente que está fallando. Cuando un servicio empieza a fallar, el disyuntor se abre y devuelve inmediatamente un error o una respuesta alternativa sin realizar la llamada de red. Después de un periodo de enfriamiento, pasa al estado semiabierto y permite realizar una solicitud de prueba. Si esta tiene éxito, el circuito se cierra y se reanuda el funcionamiento normal.

Para los errores transitorios (interrupciones breves de red o sobrecarga temporal del servicio), es adecuada una estrategia de reintentos con retroceso exponencial. La aplicación vuelve a intentar la llamada fallida después de una espera, duplicando el tiempo de espera con cada reintento hasta alcanzar un máximo. Añadir un jitter (una variación aleatoria) al tiempo de espera evita que todos los intentos de reintento se sincronicen y saturen un servicio que se está recuperando.

El patrón de mamparo aísla distintas partes de una aplicación en grupos de recursos, de modo que un fallo en un área no consuma todos los recursos ni derribe el sistema completo. El nombre procede de los mamparos de los barcos, que evitan que un compartimento inundado hunda toda la embarcación. En Azure, esto podría implicar usar grupos de subprocesos independientes o planes de App Service independientes para distintos servicios con el fin de contener los fallos.

Una técnica habitual de degradación gradual consiste en proporcionar datos almacenados en caché u obsoletos cuando un origen de datos activo no está disponible. Por ejemplo, una página de catálogo de productos podría mostrar los precios del día anterior almacenados en la caché de Azure Cache for Redis en lugar de mostrar un error si no se puede acceder temporalmente a la base de datos. Los usuarios experimentan una molestia menor (precios ligeramente desactualizados) en lugar de un fallo completo.

La degradación gradual debe ser visible y medible. Use Application Insights para realizar un seguimiento de la frecuencia de aperturas del disyuntor, respuestas alternativas e intentos de reintento como métricas personalizadas. Configure alertas cuando estas métricas superen determinados umbrales, de modo que se notifique al equipo de guardia que la aplicación se está ejecutando en un estado degradado, aunque la experiencia visible para el usuario parezca aceptable.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que las sondas de estado permiten que los equilibradores de carga detecten backends con errores y redirijan el tráfico automáticamente; la degradación gradual mantiene las aplicaciones parcialmente operativas cuando fallan las dependencias; y patrones como el disyuntor, el reintento con retroceso y el mamparo implementan resiliencia en el nivel de la aplicación. A continuación, exploraremos los conceptos de recuperación ante desastres: la definición de RTO, RPO y niveles de recuperación.