Compartir vía

Recomendaciones para la recuperación automática y la conservación automática

  • Artículo

Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:

RE:07 Refuerce la resistencia y la capacidad de recuperación de la carga de trabajo mediante la implementación de medidas de conservación y recuperación automáticas. Cree funcionalidades en la solución mediante patrones de confiabilidad basados en infraestructura y patrones de diseño basados en software para controlar errores de componentes y errores transitorios. Cree funcionalidades en el sistema para detectar errores de componentes de solución e iniciar automáticamente una acción correctiva mientras la carga de trabajo sigue funcionando con funcionalidad completa o reducida.

Guías relacionadas: Errores transitorios de trabajos | en segundo plano

En esta guía se describen las recomendaciones para crear funcionalidades de recuperación automática y autoconservación en la arquitectura de la aplicación para optimizar la confiabilidad.

Las funcionalidades de autoconservación agregan resistencia a la carga de trabajo. Reducen la probabilidad de una interrupción completa y permiten que la carga de trabajo funcione en un estado degradado mientras se recuperan los componentes con errores. Las funcionalidades de recuperación automática ayudan a evitar el tiempo de inactividad mediante la creación de la detección de errores y las acciones correctivas automáticas para responder a diferentes tipos de errores.

En esta guía se describen los patrones de diseño que se centran en la autoconservación y la recuperación automática. Incorpórelos a la carga de trabajo para reforzar su resistencia y capacidad de recuperación. Si no implementa patrones, las aplicaciones corren el riesgo de errores cuando surgen problemas inevitables.

Definiciones

Término Definición
Recuperación automática La capacidad de la carga de trabajo para resolver automáticamente los problemas mediante la recuperación de componentes afectados y, si es necesario, conmutar por error a la infraestructura redundante.
Autoconservación La capacidad de la carga de trabajo para ser resistente frente a posibles problemas.

Estrategias de diseño principales

Diseño para la autoconservación

Para diseñar la carga de trabajo para la autoconservación, siga los patrones de diseño de arquitectura de la infraestructura y de la aplicación para optimizar la resistencia de la carga de trabajo. Para minimizar la posibilidad de experimentar una interrupción completa de la aplicación, aumente la resistencia de la solución eliminando puntos únicos de error y minimizando el radio de explosión de errores. Los enfoques de diseño de este artículo proporcionan varias opciones para reforzar la resistencia de la carga de trabajo y cumplir los objetivos de confiabilidad definidos de la carga de trabajo.

Guía y patrones de diseño de infraestructura

En el nivel de infraestructura, un diseño de arquitectura redundante debe admitir los flujos críticos, con recursos implementados en zonas de disponibilidad o regiones. Implemente el escalado automático siempre que sea posible. El escalado automático ayuda a proteger la carga de trabajo frente a ráfagas imprevistas en la actividad, lo que refuerza aún más la infraestructura.

Use el patrón Stamps de implementación o el patrón Bulkhead para minimizar el radio de explosión cuando surjan problemas. Estos patrones ayudan a mantener la carga de trabajo disponible si un componente individual no está disponible. Use los siguientes patrones de diseño de aplicaciones en combinación con la estrategia de escalado automático.

  • Patrón de stamps de implementación: aprovisione, administre y supervise un grupo variado de recursos para hospedar y operar varias cargas de trabajo o inquilinos. Cada copia individual se denomina stamp. En ocasiones, también se conoce como unidad de servicio, unidad de escalado o celda.

  • Patrón bulkhead: cree particiones de instancias de servicio en grupos diferentes, conocidos como grupos, en función de los requisitos de disponibilidad y carga del consumidor. Este diseño ayuda a aislar los errores y permite mantener la funcionalidad del servicio para algunos consumidores, incluso durante un error.

Guía y patrones de diseño de aplicaciones

Evite compilar aplicaciones monolíticas en el diseño de la aplicación. Use servicios o microservicios de acoplamiento flexible que se comuniquen entre sí a través de estándares bien definidos para reducir el riesgo de problemas extensos cuando se produzca un mal funcionamiento en un único componente. Por ejemplo, puede estandarizar el uso de un bus de servicio para controlar toda la comunicación asincrónica. La estandarización de protocolos de comunicación garantiza que el diseño de aplicaciones sea coherente y simplificado, lo que hace que la carga de trabajo sea más confiable y fácil de solucionar cuando se produzca un error de funcionamiento. Cuando sea práctico, prefiere la comunicación asincrónica entre los componentes a través de la comunicación sincrónica para minimizar los problemas de tiempo de espera, como los mensajes fallidos. Los siguientes patrones de diseño le ayudan a organizar la carga de trabajo y definir las comunicaciones entre los componentes de una manera que mejor se adapte a sus requisitos empresariales.

  • Patrón de embajador: separe la lógica de negocios del código de red y la lógica de resistencia. Crea servicios auxiliares que envían solicitudes de red en nombre de una aplicación o servicio de consumidor. Puede usar este patrón para implementar mecanismos de reintento o interrupción del circuito.

  • Patrón de solicitud-respuesta asincrónica: desacopla el procesamiento de back-end de un host front-end si el procesamiento de back-end debe ser asincrónico, pero el front-end necesita una respuesta clara.

  • Patrón Cache-Aside: cargue datos a petición de un almacén de datos en una memoria caché. Este patrón puede mejorar el rendimiento y ayudar a mantener la coherencia entre los datos que se mantienen en la memoria caché y los datos que están en el almacén de datos subyacente.

  • Patrón circuit Breaker: use disyuntores para determinar de forma proactiva si se debe permitir que una operación continúe o devolver una excepción en función del número de errores recientes.

  • Patrón de comprobación de notificaciones: divida un mensaje grande en una comprobación de notificaciones y una carga. Envíe la comprobación de notificaciones a la plataforma de mensajería y almacene la carga en un servicio externo. Este patrón permite que se procesen mensajes de gran tamaño al proteger el bus de mensajes y evitar que el cliente se sobrepase o ralentice.

  • Patrón de consumidores competidores: habilite varios consumidores simultáneos para procesar los mensajes que se reciben en el mismo canal de mensajería. Un sistema puede procesar varios mensajes simultáneamente, lo que optimiza el rendimiento, mejora la escalabilidad y la disponibilidad, y equilibra la carga de trabajo.

  • Configurar tiempos de espera de solicitud: configure tiempos de espera de solicitud para llamadas a servicios o bases de datos. Los tiempos de espera de conexión de base de datos normalmente se establecen en 30 segundos.

  • Patrón gatekeeper: proteja las aplicaciones y los servicios mediante una instancia de host dedicada para brokerar las solicitudes entre los clientes y la aplicación o el servicio. El agente valida y sanea las solicitudes y puede proporcionar una capa adicional de seguridad para limitar la superficie expuesta a ataques del sistema.

  • Patrón de nivelación de carga basado en cola: desacopla las tareas del servicio de la solución mediante una cola entre ellas para que cada una se pueda ejecutar de forma asincrónica. Use una cola como búfer entre una tarea y un servicio que invoca para ayudar a suavizar las cargas pesadas intermitentes que pueden hacer que el servicio produzca un error o que la tarea agote el tiempo de espera. Este patrón puede ayudar a minimizar el efecto de los picos de demanda en la disponibilidad y la capacidad de respuesta de la tarea y el servicio.

  • Patrón de limitación: controle el consumo de recursos que usa una instancia de una aplicación, un inquilino individual o un servicio completo. Este patrón permite que el sistema siga funcionando y cumpla los acuerdos de nivel de servicio (SLA), incluso cuando un aumento de la demanda coloca una carga extrema en los recursos.

  • Patrón transitorio de control de errores y patrón de reintento: implemente una estrategia para controlar los errores transitorios para proporcionar resistencia en la carga de trabajo. Los errores transitorios son repeticiones normales y esperadas en entornos en la nube. Las causas típicas de errores transitorios incluyen la pérdida momentánea de la conectividad de red, una conexión de base de datos eliminada o un tiempo de espera cuando un servicio está ocupado. Para obtener más información sobre el desarrollo de una estrategia de reintento, consulte la guía de control de errores transitorios de esta serie.

Trabajos en segundo plano

Los trabajos en segundo plano son una manera eficaz de mejorar la confiabilidad de un sistema desacoplando tareas de la interfaz de usuario (UI). Implemente una tarea como un trabajo en segundo plano si no requiere información o comentarios del usuario y si no afecta a la capacidad de respuesta de la interfaz de usuario.

Los ejemplos comunes de trabajos en segundo plano son:

  • Trabajos intensivos de CPU, como realizar cálculos complejos o analizar modelos estructurales.
  • Trabajos intensivos de E/S, como ejecutar varias operaciones de almacenamiento o indexar archivos grandes.
  • Trabajos por lotes, como actualizar datos periódicamente o procesar tareas en un momento específico.
  • Flujos de trabajo de larga duración, como completar un pedido o aprovisionar servicios y sistemas.

Para obtener más información, consulte Recomendaciones para trabajos en segundo plano.

Diseño para la recuperación automática

Para diseñar la carga de trabajo para la recuperación automática, implemente la detección de errores para que las respuestas automáticas se desencadenen y los flujos críticos se recuperen correctamente. Habilite el registro para proporcionar información operativa sobre la naturaleza del error y el éxito de la recuperación. Los enfoques que se toman para lograr la recuperación automática de un flujo crítico dependen de los objetivos de confiabilidad definidos para ese flujo y los componentes y dependencias del flujo.

Guía de diseño de infraestructura

En el nivel de infraestructura, los flujos críticos deben ser compatibles con un diseño de arquitectura redundante con conmutación por error automatizada habilitada para los componentes que lo admiten. Puede habilitar la conmutación por error automatizada para los siguientes tipos de servicios:

  • Recursos de proceso: los conjuntos de escalado de máquinas virtuales de Azure y la mayoría de los servicios de proceso de plataforma como servicio (PaaS) se pueden configurar para la conmutación automática por error.

  • Bases de datos: las bases de datos relacionales se pueden configurar para la conmutación automática por error con soluciones como clústeres de conmutación por error de Azure SQL, grupos de disponibilidad AlwaysOn o funcionalidades integradas con servicios PaaS. Las bases de datos NoSQL tienen funcionalidades de agrupación en clústeres similares y funcionalidades integradas para los servicios PaaS.

  • Almacenamiento: use opciones de almacenamiento redundantes con conmutación automática por error.

Guía y patrones de diseño de aplicaciones

  • Bloquear actores incorrectos: si limita un cliente, no significa que el cliente actúe de forma malintencionada. Puede significar que el cliente superó su cuota de servicio. Pero si un cliente supera de forma coherente su cuota o se comporta mal, puede bloquearla. Defina un proceso fuera de banda para que un cliente solicite que se desbloquee.

  • Patrón de interruptor: si un error persiste después de iniciar el mecanismo de reintento, corre el riesgo de errores en cascada resultantes de un trabajo pendiente creciente de llamadas. Un disyuntor diseñado para trabajar con el mecanismo de reintento limita el riesgo de errores en cascada evitando que la aplicación intente ejecutar repetidamente una operación que probablemente produzca un error.

  • Patrón de compensación de transacciones: si usa una operación finalmente coherente que consta de una serie de pasos, implemente el patrón de transacción de compensación. Si se produce un error en uno o varios de los pasos, puede usar este patrón para deshacer el trabajo que han realizado los pasos.

  • Degradarse correctamente: a veces no puede solucionar un problema, pero puede proporcionar una funcionalidad reducida. Piense en una aplicación que muestre un catálogo de libros. Si la aplicación no puede recuperar la imagen en miniatura de la portada, puede que muestre una imagen de marcador de posición. Es posible que para la aplicación no sea esencial contar con subsistemas completos. Por ejemplo, para un sitio web de comercio electrónico, mostrar recomendaciones de productos probablemente es menos crítica que procesar pedidos. La degradación correcta también puede incluir operaciones de conmutación automática por error. Cuando una base de datos conmuta por error automáticamente a una réplica debido a un problema con la instancia principal, el rendimiento se degrada durante un breve tiempo.

  • Patrón de elección de líder: cuando necesite coordinar una tarea, use la elección del líder para seleccionar un coordinador para que un coordinador no sea un único punto de error. Si se produce un error en el coordinador, se selecciona uno nuevo. En lugar de implementar un algoritmo de elección líder desde cero, considere una solución fuera de la plataforma, como ZooKeeper.

  • Patrones de prueba: incluya pruebas de los patrones que implemente como parte de los procedimientos de prueba estándar.

  • Usar puntos de control para transacciones de larga duración: los puntos de control pueden proporcionar resistencia si se produce un error en una operación de ejecución prolongada. Cuando se reinicia la operación, por ejemplo, si otra máquina virtual la recoge, puede reanudarse desde el último punto de control. Considere la posibilidad de implementar un mecanismo que registre información de estado sobre la tarea a intervalos regulares. Guarde este estado en un almacenamiento duradero al que pueda acceder cualquier instancia del proceso que ejecute la tarea. Si se cierra el proceso, el trabajo que estaba realizando se puede reanudar desde el último punto de control mediante otra instancia. Hay bibliotecas que proporcionan esta funcionalidad, como NServiceBus y MassTransit. Conservan de forma transparente el estado, donde los intervalos se alinean con el procesamiento de mensajes de colas en Azure Service Bus.

Acciones automatizadas de recuperación automática

Otro enfoque para la recuperación automática es el uso de acciones automatizadas desencadenadas por la solución de supervisión cuando se detectan cambios de estado de mantenimiento predefinidos. Por ejemplo, si la supervisión detecta que una aplicación web no responde a las solicitudes, puede compilar la automatización a través de un script de PowerShell para reiniciar el servicio de aplicaciones. Según el conjunto de aptitudes del equipo y las tecnologías de desarrollo preferidas, use un webhook o una función para crear acciones de automatización más complejas. Consulte la arquitectura de referencia de automatización en la nube basada en eventos para ver un ejemplo del uso de una función para responder a la limitación de la base de datos. El uso de acciones automatizadas puede ayudarle a recuperarse rápidamente y minimizar la necesidad de intervención humana.

Facilitación de Azure

La mayoría de SDK de cliente y de servicios de Azure incluye un mecanismo de reintento. Pero difieren porque cada servicio tiene características y requisitos diferentes, por lo que cada mecanismo de reintento se ajusta a un servicio específico. Para obtener más información, consulte Recomendaciones para el control de errores transitorios.

Use grupos de acciones de Azure Monitor para notificaciones, como correo electrónico, voz o SMS, y para desencadenar acciones automatizadas. Cuando se le notifique un error, desencadene un runbook de Azure Automation, Azure Event Hubs, una función de Azure, una aplicación lógica o un webhook para realizar una acción de recuperación automatizada.

Consideraciones

Familiarícese con las consideraciones de cada patrón. Asegúrese de que el patrón es adecuado para las cargas de trabajo y los requisitos empresariales antes de la implementación.

Ejemplo

Para ver ejemplos de casos de uso de algunos patrones, consulte el patrón de aplicación web confiable para .NET. Siga estos pasos para implementar una implementación de referencia.

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad