Confiabilidad en Azure SignalR Service

Azure SignalR Service es un servicio totalmente administrado que permite la comunicación bidireccional en tiempo real en aplicaciones web y móviles. Abstrae el mecanismo de transporte subyacente. Cuando WebSockets está disponible, el servicio los usa. Cuando no lo son, recurre a Server-Sent Events o sondeos largos. Esta abstracción significa que el código de cliente y servidor se puede comunicar en tiempo real sin estar vinculado a un protocolo de transporte específico.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure SignalR Service sean resistentes a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad, interrupciones de región y mantenimiento del servicio. También destaca información clave sobre el acuerdo de nivel de servicio (SLA) de Azure SignalR Service.

Recomendaciones de implementación de producción para la confiabilidad

En el caso de las cargas de trabajo de producción, se recomienda que usted:

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

El recurso que crea es un recurso SignalR Service. Configure un recurso con una serie de unidades, que representa la capacidad del recurso, incluido el número máximo de conexiones simultáneas. Para obtener más información, consulte Guía de rendimiento para Azure SignalR Service.

Azure SignalR Service admite dos modos service. En el modo predeterminado, los servidores de aplicaciones se conectan al recurso Azure SignalR Service y contienen la lógica del centro de operaciones. En modo sin servidor, el servicio se integra con Azure Functions y Functions actúa como controladores de mensajes controlados por eventos para que no administre directamente los servidores de aplicaciones. Para obtener más información, vea Modo de servicio en Azure SignalR Service.

Un recurso de SignalR Service tiene un punto de conexión único globalmente similar a contoso.service.signalr.net. Los clientes establecen conexiones con este punto final. Los servidores de aplicaciones se conectan al mismo punto de conexión para enviar mensajes y recibir eventos de los clientes.

Arquitectura física

Azure SignalR Service administra el estado de conexión y el enrutamiento de mensajes en un conjunto de recursos de proceso. Microsoft administra la infraestructura subyacente. No ve ni interactúa directamente con máquinas virtuales individuales que usa el servicio u otros componentes de infraestructura.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Azure SignalR Service usa conexiones de larga duración entre clientes, servidores de aplicaciones y el servicio. Estas conexiones se pueden quitar debido a errores transitorios, como inestabilidad de red, reconfiguraciones del equilibrador de carga o suspensiones de pestañas del explorador. Diseñe las aplicaciones cliente y los servidores de aplicaciones para controlar las caídas de conexión y volver a conectarse automáticamente.

Los SDK de Azure SignalR Service incluyen el control de reconexión integrado para las conexiones de servidor al servicio. La reconexión del lado cliente depende de la biblioteca cliente que use. Los clientes de ASP.NET Core SignalR admiten la reconexión con estado, lo que permite a un cliente reanudar su conexión anterior sin perder el estado si se vuelve a conectar rápidamente usando el mismo identificador de conexión. Si la reconexión da como resultado un nuevo identificador de conexión, por ejemplo, después de una interrupción más larga, el servicio trata al cliente como una nueva conexión. En este caso, el cliente debe volver a unir los grupos en los que se encontraba anteriormente y restaurar cualquier estado de sesión.

Para obtener instrucciones detalladas sobre cómo diseñar la aplicación para controlar las desconexiones de cliente y las reconexión, consulte Conexiones de cliente y reconexión en Azure SignalR Service.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Azure SignalR Service admite implementaciones con redundancia de zona en el nivel Premium. Al crear o actualizar a un recurso de nivel Premium en una región que admita zonas de disponibilidad, Azure SignalR Service distribuye automáticamente su capacidad de proceso en todas las zonas de disponibilidad de la región. Si se produce un error en una zona de disponibilidad, Azure SignalR Service enruta las nuevas conexiones a las instancias de las zonas correctas restantes.

Requisitos

• Compatibilidad con regiones: La redundancia de zona se admite en la mayoría de las regiones en las que se aplican ambas condiciones:

  • Azure SignalR Service está disponible. Para obtener una lista de las regiones en las que el servicio está disponible, consulte Disponibilidad del producto por región.
  • La región admite zonas de disponibilidad. Para obtener una lista de regiones con zonas de disponibilidad, consulte Azure lista de regiones.

  Sin embargo, El oeste de Japón no admite actualmente redundancia de zona para Azure SignalR Service.

• Nivel: La redundancia de zona está disponible en el nivel Premium.

Costo

La redundancia de zona no implica un costo adicional, y pagas la tarifa estándar del nivel Premium. Para obtener más información, consulte precios de Azure SignalR Service.

Configurar soporte de zonas de disponibilidad

La redundancia de zona no requiere ninguna configuración más allá de seleccionar el nivel Premium. Se habilita automáticamente en ambos casos:

• Cree un nuevo recurso de servicio de SignalR con redundancia de zona. Seleccione una SKU de nivel Premium al crear el recurso. Para obtener más información, consulte los inicios rápidos, como Quickstart: Creación de un salón de chat mediante SignalR Service.

• Actualice un recurso existente al nivel Premium. La redundancia de zona se habilita automáticamente al actualizar un recurso existente a una SKU de nivel Premium. La actualización de Estándar a Premium no provoca tiempo de inactividad del servicio. Para obtener más información, consulte Change your Azure SignalR Service tier.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar al configurar un recurso de Azure SignalR Service para la redundancia de zona y todas las zonas de disponibilidad están operativas.

• Operación entre zonas: Azure SignalR Service administra automáticamente cómo se distribuyen las conexiones y las operaciones a través de las zonas de disponibilidad. La infraestructura de varias zonas procesa el tráfico en un modelo activo-activo. No es necesario configurar nada para aprovechar este comportamiento. El servicio enruta los mensajes entre instancias entre zonas automáticamente, por lo que un mensaje enviado por un cliente de una zona se entrega a los clientes conectados en cualquier otra zona.

• Replicación de datos entre zonas: Azure SignalR Service no conserva los datos del cliente, por lo que no hay datos para replicar entre zonas. El estado de conexión es efímero y está asociado a cada conexión activa.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar al configurar un recurso de Azure SignalR Service para la redundancia de zona y se produce una interrupción en una de las zonas de disponibilidad.

• Detección y respuesta: La plataforma Azure SignalR Service es responsable de detectar un error en una zona de disponibilidad. No es necesario realizar ninguna acción para iniciar una conmutación por error de zona.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Durante un fallo de zona, se interrumpen las conexiones activas a los nodos de la zona afectada. Si los clientes controlan los errores transitorios correctamente, por ejemplo, volviendo a conectarse después de un breve período de tiempo, normalmente evitan un impacto significativo.

• Expected data loss: Azure SignalR Service no conserva los mensajes, por lo que no se espera que un error de zona cause pérdida de datos en el Azure SignalR service. Sin embargo, las conexiones activas se interrumpen durante un evento de caída de zona, por lo que es posible que se pierdan los datos que se están transmitiendo activamente.

• Tiempo de inactividad esperado: La reconexión de conexiones activas eliminadas suele tardar unos segundos. Los clientes que implementan la lógica de reconexión experimentan una interrupción mínima.

• Redistribution: Azure SignalR Service detecta la pérdida de la zona y redistribuye automáticamente el tráfico entre las zonas correctas. No tiene que realizar ninguna acción.

Recuperación de zona

Cuando se recupera una zona de disponibilidad, Azure SignalR Service vuelve a reinsertarla automáticamente en la topología de servicio activa. No es necesario realizar ninguna acción para la recuperación de zona.

Una vez recuperada una zona, es posible que se dirijan nuevas conexiones a la infraestructura de la zona recuperada. Las conexiones existentes no se moverán ni se reequilibrarán en la zona recuperada, pero se volverán a equilibrar gradualmente a medida que las conexiones existentes bajen y se vuelvan a conectar con el tiempo. El desequilibrio de conexiones entre zonas no tiene ningún impacto en la carga de trabajo.

Prueba de fallos de zona

Azure SignalR Service administra automáticamente el enrutamiento del tráfico, la conmutación por error y la recuperación de zona para los recursos de nivel Premium con redundancia de zona. No es necesario iniciar nada. Dado que la redundancia de zona está totalmente administrada, no es necesario validar los procesos de fallo de zona de disponibilidad.

Resistencia a errores en toda la región

Azure SignalR Service es un servicio de una sola región. Si la región deja de estar disponible, el recurso de SignalR Service tampoco está disponible.

Para proteger la aplicación frente a un error en toda la región, puede usar la replicación geográfica, que está disponible en el nivel Premium. Como alternativa, puede crear una solución de varias regiones personalizada mediante la implementación de varios recursos de SignalR Service en diferentes regiones.

Geo-replication

La replicación geográfica permite agregar replicas del recurso de SignalR Service en otras regiones de Azure. Azure Traffic Manager usa el enrutamiento basado en DNS para dirigir cada cliente a la réplica regional correcta más cercana. Si se produce un error en una región, el Traffic Manager detecta el error a través de comprobaciones de estado y deja de dirigir a los clientes a esa réplica. Las nuevas conexiones de cliente se enrutan automáticamente a la réplica saludable más cercana.

La región en la que creó el recurso de Azure SignalR Service se denomina región principal y su réplica es la réplica principal. El plano control del recurso principal administra la configuración del recurso de Azure SignalR Service.

Requisitos

• Region support: Puede agregar réplicas en cualquier región en la que Azure SignalR Service esté disponible.
• Nivel: Debe usar el nivel Premium para habilitar la replicación geográfica.
• Replica limit: Cada recurso de SignalR Service principal admite hasta ocho réplicas.

Consideraciones

• Herencia de configuración: Las réplicas heredan la mayoría de las opciones de configuración del recurso principal. Algunas opciones deben configurarse por separado en cada réplica. Para obtener la lista completa de configuraciones que no se heredan, consulte Geo-replication en Azure SignalR Service.

• Cambios de configuración: El plano de control principal, en la región primaria, procesa cualquier cambio de configuración en el recurso SignalR Service. Si el plano de control principal no está disponible, no podrá actualizar la configuración del recurso, aunque las réplicas existentes seguirán procesando el tráfico de datos sin interrupción.

Costo

Cada réplica se factura por separado en función de su propio recuento de unidades y del volumen de mensajes salientes. Las tarifas de salida entre regiones se aplican cuando los mensajes se transfieren entre réplicas y se entregan a clientes o servidores de otra región. Para obtener más información, consulte los precios del Azure SignalR Service.

Configuración de la replicación geográfica

Para agregar o quitar una réplica a un recurso de SignalR Service, consulte Geo-replication en Azure SignalR Service.

Planeamiento y administración de capacidad

Cada réplica controla el tráfico de forma independiente. Durante una conmutación por error regional, los clientes de la región que ha fallado se reconectan a la réplica saludable más cercana. Para asegurarse de que las réplicas supervivientes tienen suficiente capacidad para absorber esta carga adicional, configure cada réplica con unidades que puedan controlar el tráfico total esperado de la carga de trabajo, no solo la parte que normalmente sirve.

Como alternativa, habilite el escalado automático en cada réplica para que las unidades se amplíen automáticamente en respuesta a una mayor carga. El escalado automático sigue funcionando cuando una réplica secundaria no está disponible, pero el escalado automático no funciona si el plano de control principal no está disponible. Para obtener más información sobre el escalado automático, consulte Autoscaling en Azure SignalR Service.

Para obtener instrucciones generales sobre el sobreaprovisionamiento como estrategia, consulte Administración de la capacidad mediante el sobreaprovisionamiento.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar al configurar Azure SignalR Service para la replicación geográfica y todas las réplicas están operativas.

• Operación entre regiones: Azure Traffic Manager enruta cada cliente a la réplica regional saludable más cercana. Los clientes de diferentes áreas geográficas pueden conectarse a diferentes réplicas. SignalR Service sincroniza los mensajes entre réplicas para que los clientes conectados a cualquier réplica puedan comunicarse entre sí.

• Replicación de datos entre regiones: Cuando se envía un mensaje a una réplica, el servicio transfiere sincrónicamente ese mensaje a otras réplicas para que los clientes conectados a otro lugar puedan recibirlo. La sobrecarga de sincronización es mínima para los patrones de mensajería más comunes, como la difusión a grupos grandes o la mensajería de una sola conexión. La mensajería a grupos pequeños (menos de 10 miembros) puede producir una sobrecarga de sincronización ligeramente mayor.

  Azure SignalR Service no conserva los mensajes; solo la entrega activa se sincroniza entre réplicas.

Comportamiento durante una falla de región

En esta sección se describe qué esperar al configurar Azure SignalR Service para la replicación geográfica y hay una interrupción en una de las regiones de réplica.

• Detección y respuesta: SignalR Service tiene la responsabilidad de detectar una falla en una región y redirigir automáticamente el tráfico entrante a una réplica en una de las demás regiones que configure.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Se quitan las conexiones activas a la réplica en la región con errores. Los clientes deben volver a conectarse después de que la réplica conmute por error.

• Pérdida de datos esperada: Azure SignalR Service no conserva los mensajes. Es posible que se pierdan los mensajes que estaban en tránsito a los clientes en la región que falló en el momento del fallo. No se espera ninguna pérdida de datos persistente porque el servicio no almacena los datos del cliente.

• Tiempo de inactividad esperado: Azure Traffic Manager realiza verificaciones de salud en cada réplica. Cuando una interrupción en una región provoca que una réplica falle en su verificación de estado, Traffic Manager elimina el endpoint de esa réplica de los resultados de la resolución DNS. Después de quitar el punto de conexión, deben transcurrir 90 segundos del TTL DNS antes de que los clientes vean los registros DNS actualizados. En total, la transición suele tardar unos minutos. Los clientes bien diseñados que implementan la lógica de reconexión pueden reanudar el funcionamiento normal después de volver a conectarse a la réplica sana.

  Si el plano de control principal no está disponible, no puede realizar ningún cambio en la configuración del recurso de SignalR Service o sus réplicas. Sin embargo, las conexiones siguen funcionando en réplicas saludables.

• Redistribution: Azure Traffic Manager dirige la solicitud entrante a las réplicas saludables. Sin embargo, si un cliente intenta volver a conectarse antes de que Azure Traffic Manager haya detectado el fallo de conmutación de réplica y se hayan propagado las entradas DNS actualizadas al cliente, el intento de reconexión de un cliente podría continuar apuntando a la región no disponible, lo que provocaría un fallo.

  Una vez que la actualización de DNS se propaga, los clientes que se reconectan se enrutan automáticamente a la réplica saludable más cercana.

Recuperación de regiones

Cuando se recupera la región fallida, la verificación de salud del Traffic Manager detecta la réplica restaurada y vuelve a incluir su punto de conexión en la resolución DNS. Los clientes conectados actualmente a otras réplicas no se ven afectados y permanecen conectados hasta que se desconectan. Las nuevas conexiones se enrutan a la réplica de la región recuperada cuando es la réplica más cercana y en funcionamiento.

Prueba de fallos de región

Para simular un fallo de región y con el fin de probar el comportamiento de reconexión de su aplicación cliente, puede deshabilitar el punto de conexión de una réplica. Esta acción hace que Traffic Manager deje de enrutar el tráfico a esa réplica, lo que le permite observar cómo se comportan los clientes cuando la réplica a la que se conectan deja de estar disponible. Para obtener pasos detallados, consulte Deshabilitar o habilitar el punto de conexión de réplica.

Soluciones personalizadas de varias regiones para la resistencia

Si necesita resistencia entre regiones, pero no usa la replicación geográfica, puede implementar y administrar recursos de SignalR Service independientes en varias regiones e implementar su propia lógica de conmutación por error en el servidor de aplicaciones. Este enfoque es más complejo que la replicación geográfica y no admite la tolerancia a fallos sin tiempo de inactividad para la conexión de cliente a cliente. Para obtener información general detallada sobre la arquitectura, los patrones de conmutación por error y las instrucciones de prueba, consulte Resiliency y recuperación ante desastres en Azure SignalR Service.

Copias de seguridad y restauración

Azure SignalR Service es un servicio de mensajería sin estado. No conserva los mensajes del cliente y no tiene capacidad de copia de seguridad ni restauración.

Para proteger la configuración de recursos, defina los recursos de SignalR Service mediante la infraestructura como código (como Bicep o plantillas de ARM) y almacene esas definiciones en el control de código fuente. Si necesita volver a crear un recurso, vuelva a implementarlo desde la configuración almacenada.

Resistencia al mantenimiento del servicio

Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se espera ningún tiempo de inactividad durante los eventos de mantenimiento a menos que se le haya informado a través del mantenimiento planeado de Azure Service Health.

Durante el mantenimiento planeado, Azure SignalR Service usa una estrategia de apagado correcta para reducir el impacto en los clientes conectados. Las conexiones se desconectan gradualmente en un período de tiempo establecido, lo que permite a los clientes volver a conectarse progresivamente en lugar de hacerlo todo a la vez. Para obtener más información, consulte Desconexiones durante el mantenimiento del servicio.

Los eventos de mantenimiento se presentan a los clientes como caídas de conexión. Asegúrese de que las aplicaciones cliente implementen la lógica de reconexión para que puedan recuperarse de desconexiones relacionadas con el mantenimiento sin interrupciones visibles para el usuario.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Contenido relacionado

• Confiabilidad en Azure
• Información general sobre Azure SignalR Service
• Geo-replication en Azure SignalR Service
• Resiliencia y recuperación ante desastres en Azure SignalR Service
• Comprensión de las desconexiones y reconexiones del cliente en Azure SignalR Service