Confiabilidad en Azure Web PubSub Service

Azure Web PubSub Service es un servicio de mensajería totalmente administrado en tiempo real que permite la comunicación bidireccional entre servidores y clientes mediante el protocolo WebSocket. Un único recurso de Web PubSub puede escalar a un millón de conexiones WebSocket simultáneas. El servicio admite varios patrones de mensajería, como difusión de servidor a cliente, mensajería a grupos con nombre, pub/sub de cliente a cliente y streaming de tokens de IA.

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 el servicio Azure Web PubSub sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, errores de zona de disponibilidad y errores en toda la región. También describe cómo el servicio controla el mantenimiento y resalta la información clave sobre el contrato de nivel de servicio (SLA) de Azure Web PubSub servicio.

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

Para cargas de trabajo de producción, siga estas recomendaciones:

  • Use el nivel Premium. El nivel Premium es resistente a los errores de zona de disponibilidad en regiones admitidas y permite configurar la replicación geográfica.
  • Use el SDK de cliente de Azure Web PubSub al compilar aplicaciones cliente o siga las instrucciones de control de errores transitorios mediante la reconexión segura. Las conmutaciones por error de zona, las conmutaciones por error de región y los errores transitorios interrumpen las conexiones activas.
  • Habilite la replicación geográfica para protegerse frente a errores en toda la región. Dimensione cada réplica con suficientes unidades para manejar toda la carga de tráfico esperada durante un evento de failover.

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 de Web PubSub. 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 Performance guide for Azure Web PubSub Service.

Un recurso de Web PubSub tiene un punto de conexión único globalmente similar a contoso.webpubsub.azure.com. Los clientes establecen conexiones de WebSocket a este punto de conexión. Los servidores de aplicaciones se conectan al mismo punto de conexión para enviar mensajes y recibir eventos de los clientes.

Para obtener más información, consulte Azure Web PubSub service internals.

Arquitectura física

Azure Web PubSub Service administra el estado de conexión de WebSocket 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.

WebSocket es un protocolo de conexión de larga duración. Los eventos de red transitorios, los reinicios de la infraestructura de back-end y las operaciones de mantenimiento del servicio pueden quitar una conexión activa. Una reconexión básica restaura la conexión, pero sin lógica adicional, el cliente pierde los mensajes que estaban en curso o en cola durante la interrupción.

Azure Web PubSub Service soluciona este problema a través de subprotocolos fiables que operan sobre la conexión WebSocket sin procesar. Los subprotocolos realizan un seguimiento de la secuencia de mensajes y el estado de conexión para que, cuando una conexión cae, el cliente renegocia con el servicio y se reanuda desde donde se dejó.

Normalmente, no hay pérdida de mensajes después de que una conexión se corte y vuelva a establecerse. Sin embargo, hay algunas situaciones en las que puede producirse una pérdida de mensajes. Por ejemplo, si el cliente se desconecta durante más de un minuto y, a continuación, se vuelve a conectar con el mismo identificador de conexión, la operación de reconexión muestra un estado de error para indicar que puede producirse una pérdida de mensajes.

Para aprovechar los subprotocolos confiables, siga estas recomendaciones:

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 Web PubSub Service admite implementaciones con redundancia de zona cuando se usa el nivel Premium. Al crear o actualizar un recurso de Web PubSub de nivel Premium en una región que admita zonas de disponibilidad, la redundancia de zona se habilita automáticamente. El servicio distribuye su infraestructura en varias zonas de disponibilidad de la región. Si se produce un error en una zona, el servicio enruta el tráfico a la infraestructura en la zona en buen estado.

Diagrama que muestra un servicio de Azure Web PubSub con redundancia de zona, distribuido entre varias zonas de disponibilidad.

Requisitos

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

    • Servicio de Azure Web PubSub 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 Web PubSub.

  • 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 servicio Azure Web PubSub.

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 Web PubSub con redundancia de zona. Seleccione una SKU de nivel Premium al crear el recurso. Para obtener más información, consulte Crear un recurso de Azure Web PubSub.

  • 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 Escalar una instancia de servicio de Azure Web PubSub.

Comportamiento cuando todas las zonas están en buen estado

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

  • Operación entre zonas: Azure Web PubSub Service gestiona automáticamente cómo se distribuyen las conexiones y las operaciones entre 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 Web PubSub Service no conserva datos de clientes. El servicio mantiene los metadatos de sesión, como el estado de conexión y la información de secuencia de mensajes para las conexiones activas. Estos metadatos se replican sincrónicamente entre zonas de disponibilidad.

Comportamiento durante un fallo de zona

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

  • Detección y respuesta: La plataforma del servicio Azure Web PubSub 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, las conexiones activas de WebSocket a la infraestructura de la zona afectada se interrumpen. 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 Web PubSub Service no conserva los mensajes, por lo que no se espera que un error de zona cause pérdida de datos en el servicio Azure Web PubSub. 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.

    Si los publicadores usan un SDK de cliente de Azure Web PubSub o implementan los subprotocolos confiables, el servicio los reconoce después de que el servicio los reciba. Cuando se confirma un mensaje, se replica en todas las zonas de disponibilidad, por lo que el error de zona del publicador no hace que se pierda el mensaje. Sin embargo, si un suscriptor no recibe el mensaje antes de quitarlo, es posible que no reciba el mensaje.

  • 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 Web PubSub 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 Web PubSub Service lo vuelve a reinsertar 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 Web PubSub 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 Web PubSub Service es un servicio de una sola región. Si la región deja de estar disponible, el recurso de Web PubSub 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 Web PubSub en diferentes regiones.

Replicación geográfica

La replicación geográfica permite agregar replicas del recurso de Web PubSub en otras regiones de Azure. Todas las réplicas comparten un único punto de conexión (contoso.webpubsub.azure.com). Detrás de este punto de conexión, Azure Traffic Manager utiliza el enrutamiento basado en DNS para dirigir a cada cliente a la réplica regional más cercana que esté en buen estado. 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.

Diagrama que muestra Azure Web PubSub configurado para la replicación geográfica en dos regiones.

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

Requisitos

  • Region support: Puede agregar réplicas en cualquier región en la que Azure Web PubSub Service esté disponible.
  • Nivel: Debe usar el nivel Premium para habilitar la replicación geográfica.
  • Límite de réplica: Cada recurso principal de Web PubSub 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 opciones de configuración que no se heredan, consulte Geo-replication en Azure Web PubSub.

  • Cambios de configuración: El plano de control principal, en la región primaria, procesa los cambios de configuración en el recurso de Web PubSub. 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. Si un mensaje se transfiere entre réplicas y, a continuación, se entrega a un cliente o servidor de otra región, se factura como mensaje saliente. Para obtener más información, consulte precios de servicio Azure Web PubSub.

Configuración de la replicación geográfica

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

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 Unidades de escalado automático de un servicio de Azure Web PubSub.

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 Web PubSub Service para la replicación geográfica y todas las regiones 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. El servicio Web PubSub 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 Web PubSub Servicio 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 Web PubSub Service para la replicación geográfica y se produce una interrupción en una de las regiones de réplica.

  • Detección y respuesta: El servicio Web PubSub es responsable de detectar un error 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:

  • Solicitudes activas: Se quitan las conexiones WebSocket activas a la réplica de 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 Web PubSub Service no almacena 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 Web PubSub ni en sus réplicas. Sin embargo, las conexiones de WebSocket 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 de varias regiones personalizadas para la resistencia

Si necesita resistencia entre regiones, pero no usa la replicación geográfica, puede implementar y administrar recursos independientes de Web PubSub 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 una visión general detallada de la arquitectura, patrones de conmutación por error y guías para la realización de pruebas, consulte Resiliencia y recuperación ante desastres en Azure Web PubSub Service.

Copias de seguridad y restauración

Azure Web PubSub 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 sus recursos, defina sus recursos de Web PubSub mediante la infraestructura como código (como Bicep o plantillas de ARM) y almacene esas definiciones en el control de versiones. 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.

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

  • Last updated on