En esta guía, se proporciona una comprensión y un panorama general de las funciones de confiabilidad de Pub/Sub. Los temas que se tratan en este documento incluyen los siguientes:
- ¿Por qué elegir Pub/Sub?
- Conmutación por error
- Optimiza a los editores
- Cómo ajustar los suscriptores
- Usa instantáneas y búsquedas para implementaciones seguras
¿Por qué elegir Pub/Sub?
Como paradigma de mensajería, la publicación y suscripción está diseñada para separar a los productores de mensajes de los consumidores de esos mensajes. En lugar de que los productores envíen solicitudes directas a los consumidores con los datos, los publican en un servicio de Pub/Sub, como Pub/Sub. El servicio entrega de forma asíncrona esos mensajes a consumidores interesados que se suscribieron.
El resultado es que el servicio absorbe todas las complejidades de encontrar consumidores interesados en los datos. El servicio también administra la velocidad a la que los consumidores reciben los datos, según su capacidad. La separación permite a los productores de datos escribir mensajes a gran escala con baja latencia, independientemente del comportamiento de los consumidores.
Pub/Sub ofrece una entrega de mensajes altamente escalable y confiable. Si bien el servicio maneja gran parte de esto automáticamente, tú controlas diferentes aspectos de tus publicadores y suscriptores que pueden afectar la disponibilidad y el rendimiento. En el resto de esta guía, se proporcionan algunos detalles sobre estos aspectos
Conmutación por error
Pub/Sub es un servicio global. Los temas y las suscripciones no están vinculados de forma inherente a regiones específicas, y los mensajes fluyen dentro del servicio de Pub/Sub entre regiones cuando es necesario. Cuando se usa el extremo global, pubsub.googleapis.com, los publicadores y suscriptores se conectan a la región más cercana de la red en la que se ejecuta Pub/Sub. Cuando se usan los extremos de ubicación, como us-central1-pubsub.googleapis.com, los publicadores y suscriptores se conectan a Pub/Sub en la región especificada. Cuando se ejecutan publicadores o suscriptores fuera de Google Cloud, es mejor usar extremos de ubicación para garantizar que los mensajes fluyan entre las regiones esperadas de manera coherente. En el resto de esta sección, se explica cómo crear temas y suscripciones. Además, se analiza cómo ubicar a los publicadores y suscriptores para admitir diferentes tipos de conmutación por error y redundancia de datos.
Semántica predeterminada de conmutación por error
Considera un caso en el que hay un solo tema y suscripción. Los publicadores se encuentran en regiones de Estados Unidos y Australia, y los suscriptores se encuentran en las regiones Google Cloud de Europa y Australia. Cuando todos los suscriptores tengan capacidad suficiente para recibir mensajes, el flujo de mensajes se verá de la siguiente manera:
Las P representan a los publicadores, mientras que las S representan a los suscriptores. El hexágono azul representa el servicio de Pub/Sub. Los cilindros representan los lugares en los que se almacenan los mensajes (los mensajes siempre se conservan en varias zonas de la región en la que se publican). Pub/Sub prefiere enviar mensajes dentro de la misma región en la que se publicaron cuando los suscriptores están disponibles. De lo contrario, envía los mensajes a la región más cercana de la red con suscriptores que tienen capacidad. Por lo tanto, como se muestra en la imagen anterior, los mensajes publicados en Estados Unidos se entregan a los suscriptores en Europa y los mensajes publicados en Australia permanecen en Australia.
En las siguientes secciones, se analiza lo que sucede en diferentes situaciones de falla.
Los suscriptores en Europa no están disponibles
Supongamos que los suscriptores en Europa se rechazaron o fallaron con frecuencia y que no pudieron mantener una conexión a Pub/Sub. Si esto ocurriera, el servicio comenzaría a enviar mensajes a los suscriptores de Australia:
Los suscriptores en Europa y Australia no están disponibles
En caso de que ninguno de los suscriptores esté disponible, Pub/Sub almacena los mensajes hasta el período de retención de mensajes configurado.
Una vez que los suscriptores se reconectan, los mensajes se entregan, a menos que la interrupción dure más que la duración de retención de mensajes configurada. De forma predeterminada, la retención de mensajes de suscripción se establece en 7 días. También puedes configurar la retención de mensajes de un tema por hasta 31 días. No elijas una duración de retención de mensajes menor que la interrupción máxima que esperas o estás dispuesto a tolerar.
Pub/Sub no está disponible en Europa
Aunque es poco común, es posible que también quieras abordar casos en los que Pub/Sub no está disponible. La falta de disponibilidad de Pub/Sub se manifiesta como períodos prolongados de errores inesperados en solicitudes de publicación o suscripción, o la imposibilidad de entregar mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub estuviera inactivo en la región de Europa, la situación sería muy parecida a la de los suscriptores.
Ten en cuenta que, en este caso, los suscriptores en Europa no conmutan por error a otra región, incluso si usan el extremo global. Pub/Sub no realiza una conmutación por error automáticamente. Imagina que son los suscriptores los que causan un problema inesperado en Pub/Sub que provoca la falta de disponibilidad. Este problema se trata como una interrupción importante. Sin embargo, el alcance del impacto de la interrupción puede contenerse en la región a la que se conectaron los suscriptores. Si el servicio les permitió conmutar por error a otra región, los suscriptores también podrían causar falta de disponibilidad allí, lo que provocaría una falla en cascada en todo el servicio.
Los editores en Australia no están disponibles
Si los publicadores de una región no están disponibles, los mensajes que ya están publicados aún se entregan a los suscriptores más cercanos:
Con el tiempo, los suscriptores consumen y reconocen todos los mensajes. Cuando envías mensajes, Pub/Sub intenta minimizar la distancia de red. Por lo tanto, los suscriptores de la región de Australia pueden dejar de recibir mensajes si los suscriptores de Europa tienen la capacidad suficiente para manejar todos los mensajes publicados en Estados Unidos.
Pub/Sub no está disponible en Estados Unidos
Pub/Sub escribe mensajes de forma síncrona en varias zonas dentro de una región. Por lo tanto, una interrupción zonal no es suficiente para impedir la entrega de mensajes; toda la región debe no estar disponible. Si Pub/Sub deja de estar disponible en una región en la que los publicadores envían mensajes, es posible que los mensajes de esa región no se entreguen hasta que el servicio se restablezca por completo:
El mensaje aún se entrega en última instancia (suponiendo que el período de retención de mensajes no pasó), retrasado por la duración de la interrupción. Ten en cuenta que, al igual que los suscriptores, los publicadores de Estados Unidos no conmutan por error a otra región cuando falla el servicio. Este comportamiento ayuda a prevenir la probabilidad de fallas en cascada en las regiones debido a un publicador o suscriptor con errores.
Aislamiento
La semántica de conmutación por error predeterminada que se detalla afecta el aislamiento de datos y cómo la falta de disponibilidad de los publicadores, suscriptores o Pub/Sub puede afectar el flujo de mensajes. Tu caso de uso podría requerir diferentes niveles de aislamiento. Por ejemplo, es posible que necesites la entrega de todos los mensajes dentro de la región.
Si no deseas ningún aislamiento, la semántica de conmutación por error predeterminada detallada es suficiente. Debes crear un solo tema, una sola suscripción y ubicar a los publicadores y suscriptores en todas las regiones seleccionadas. Si los suscriptores no están disponibles o Pub/Sub no funciona en la región a la que se conectan, la entrega se conmuta por error a los suscriptores de otra región.
Para el aislamiento regional, en el que se garantiza que los datos no saldrán de una región, crea un tema y una suscripción para manejar los mensajes en cada región. Ubica a los publicadores y suscriptores en cada una de esas regiones y haz que publiquen y se suscriban al tema regional y la suscripción correspondientes, respectivamente. También debes usar extremos regionales para garantizar que los datos solo se muevan dentro de la región. Si se producen fallas del publicador, del suscriptor o de Pub/Sub en una sola región, la entrega de mensajes se detiene en esa región. La entrega de mensajes sobre temas y suscripciones de otras regiones no se verá afectada.
Por último, el aislamiento zonal, en el que se garantiza que los datos permanecerán en una sola zona, no es posible en Pub/Sub. Si necesitas que las zonas individuales sean independientes, usa Pub/Sub Lite.
Conmutación por error y redundancia controladas por el cliente
Es posible que la semántica predeterminada de conmutación por error de Pub/Sub no garantice por completo que los mensajes siempre puedan fluir de los publicadores a los suscriptores si hay una interrupción en algún punto intermedio. Las interrupciones pueden ocurrir en varios lugares diferentes, incluidos tus clientes, en el servicio en el que se ejecutan tus publicadores o suscriptores, en la red o, incluso, rara vez en Pub/Sub. Si necesitas que tus servicios sean resilientes a estas interrupciones, debes implementar tus propias redundancias. Por lo general, estas redundancias incluyen el uso de varias instancias de clientes publicadores y suscriptores, y cada una usa un extremo de ubicación diferente.
Se recomienda tener resiliencia para dos alcances de impacto diferentes: zonal o regional. A continuación, se incluyen las opciones de configuración para cada uno.
Resiliencia zonal
Pub/Sub cuenta con replicación interzonal integrada. No tienes que realizar ningún paso especial para lidiar con las interrupciones de una sola zona que afectan al servicio en sí. Sin embargo, para que tus clientes o tu red sean resilientes a las interrupciones, es mejor ejecutar publicadores y suscriptores con capacidad suficiente en varias zonas dentro de la región. Si una sola zona está inactiva, los clientes de la otra zona pueden recoger el tráfico y procesar los mensajes. Se recomienda no publicar cambios en estos clientes de forma simultánea para que, si se produce un error, las otras zonas intactas puedan continuar con el procesamiento de mensajes.
Resiliencia regional
Para ser resiliente a las fallas regionales, configura redundancias adicionales en tus publicadores y suscriptores. Puedes ejecutar publicadores y suscriptores en varias regiones para lidiar con la posibilidad de interrupciones en esos clientes o en las herramientas de redes.
Si deseas ser resistente contra posibles fallas de Pub/Sub en una región, debes tener un mecanismo de conmutación por error listo para lidiar con esa interrupción. Los enfoques posibles son un equilibrio entre la latencia de entrega de mensajes de extremo a extremo y el costo.
Para minimizar la latencia en caso de que el costo no sea una preocupación, la mejor estrategia es siempre publicar y suscribirse simultáneamente en diferentes regiones. Primero, elige la cantidad de regiones en las que quieres redundancia. A continuación, aunque no es estrictamente necesario, puedes configurar un tema y una suscripción para cada una de esas regiones.
Cada publicador crea tantos clientes del publicador como existan regiones (una para cada región) y usa un extremo de ubicación diferente para garantizar que los mensajes se dirijan a distintas regiones. Si usas temas diferentes, cada cliente publicador debe publicar en el tema correspondiente por región. Para cada mensaje, el publicador llama a Publicar en cada cliente. Con las publicaciones redundantes, no es necesario reintentar las publicaciones si falla alguna de ellas.
De manera similar, cada suscriptor crea esa cantidad de clientes suscriptores, uno para cada región, y usa un extremo de ubicación para conectarse a una región diferente. Si se usan suscripciones diferentes para cada región, cada cliente suscriptor debe usar la suscripción correspondiente. Ten en cuenta que las regiones que se usan para los publicadores y los suscriptores no necesariamente tienen que ser las mismas. Los suscriptores reciben mensajes de las tres suscripciones y los procesan.
Esta configuración tiene varias funciones y requisitos clave:
- Cualquier interrupción en una sola región no afecta el procesamiento de mensajes que ya se publicaron ni aquellos publicados durante la interrupción. Dado que los mensajes se publicaron en varias regiones, aún están disponibles en otras regiones en caso de que una región falle. Durante la interrupción, las llamadas de publicación fallan en la región afectada, pero se ejecutan correctamente en las demás.
- La latencia de procesamiento de mensajes no se ve afectada, siempre y cuando alguna de las regiones que pasan los mensajes esté disponible.
- El procesamiento de mensajes debe ser idempotente. Como cada mensaje se entrega varias veces, el procesamiento de mensajes debe ser resistente a los duplicados. En el caso de una interrupción regional, algunos de esos duplicados pueden ser mucho más tarde que la primera vez que se entregó el mensaje. Es probable que esos duplicados provengan de una región diferente que no experimentó una interrupción.
Ejecutar con este tipo de redundancia proporciona la mayor resiliencia ante cualquier tipo de interrupciones. Para los servicios internos de Google que dependen de Pub/Sub y requieren la mayor disponibilidad, se prefiere esta configuración. Sin embargo, con esta configuración, se obtiene la compensación de multiplicar el costo de la entrega de mensajes por la cantidad de regiones que se usan. También existe el costo adicional del uso de redes interregionales para los mensajes que deben moverse entre regiones.
Otro enfoque para la redundancia es conmutar por error solo cuando las solicitudes fallan o los mensajes no fluyen de los publicadores a los suscriptores como se esperaba. En esta situación, tienes una región principal a la que diriges a tus publicadores y suscriptores a través de extremos de ubicación. Como antes, no es necesario que sean de la misma región. También tienes una región de resguardo para publicadores y suscriptores que se usa cuando la región principal no está disponible.
Los publicadores solo publican en la región principal (a través del extremo de ubicación) cuando sus solicitudes se envían de forma correcta. Cuando se determina que la región está inactiva, los publicadores comienzan a publicar en la región de resguardo. Determinar que la región está inactiva y la conmutación por error se puede hacer de dos maneras. Se puede hacer mediante un proceso manual, y la configuración se actualiza de forma dinámica en los publicadores. Los editores también pueden actualizar la configuración por su cuenta si la tasa de error en las solicitudes de publicación es lo suficientemente alta.
Los suscriptores siempre deben conectarse a la región principal a través del extremo de ubicación. Puedes decidir que el suscriptor pueda usar la región de resguardo con uno o más de los siguientes activadores:
- Suscríbete siempre a la región de resguardo. En este caso, el suscriptor mantiene una conexión con la región principal y la de resguardo en todo momento. Se pueden usar las mismas regiones para el principal y el resguardo para los publicadores y los suscriptores. Si este es el caso, el suscriptor solo debe recibir mensajes a través de la región de copia de seguridad si el publicador realizó una conmutación por error.
- Detecta y cambia manualmente los suscriptores a la región de resguardo a través de una configuración. Si detectas una interrupción, puedes conmutar por error a la región de resguardo y, luego, regresar a la región principal cuando la interrupción haya desaparecido.
- Conmutar por error los errores del suscriptor Si las solicitudes del suscriptor muestran errores, puedes usar esto como una indicación de que debes conmutar por error a la región de resguardo. Ten en cuenta que las bibliotecas cliente de Pub/Sub vuelven a intentar transmitir las solicitudes de extracción de forma interna en errores transitorios, por lo que es posible que no puedas detectar la existencia de largos períodos de errores inesperados. Además, se espera que la tasa de errores de extracción de transmisión sea del 100%, incluso durante el funcionamiento normal.
- La conmutación por error ocurre si el suscriptor pasa por un tiempo inesperadamente largo sin recibir mensajes. Si suponemos que hay una publicación coherente de mensajes, los suscriptores siempre pueden recibir mensajes. Si pasan por un período prolongado sin recibir ningún mensaje, es posible que haya un problema relacionado con la suscripción en Pub/Sub en la región principal. Esto se soluciona con una conmutación por error a la región de resguardo.
De las cuatro opciones, la primera es la ideal. Una conexión de suscriptor no tiene costo si no hay mensajes fluyendo en ella. El único costo se encuentra en la huella de la instancia adicional de la biblioteca cliente del suscriptor, que puede ser insignificante. También debes tener en cuenta la cantidad de conexiones de extracción de transmisión abierta por cuota de región.
La ventaja de este segundo modelo es que no hay un multiplicador en el costo de Pub/Sub, ya que los mensajes solo se publican una vez. Sin embargo, la desventaja es que, para ciertos tipos de interrupciones, es posible que los mensajes publicados antes de que comience la interrupción no estén disponibles hasta que se resuelva la interrupción. Es posible que los mensajes almacenados en una región que no está disponible no se puedan entregar a los suscriptores, independientemente del lugar en el que estén conectados. Los mensajes publicados durante la interrupción en la región de resguardo pueden estar disponibles. Además, puede haber un período de falta de disponibilidad con mayores tasas de error para los publicadores o suscriptores. Esto depende del método que se use para detectar una interrupción y del tiempo de la conmutación por error a la región de resguardo.
Sin importar qué opción elijas, ten en cuenta cómo esto puede interactuar con las características de Pub/Sub. Tanto la entrega pedida como la entrega “exactamente una vez” ofrecen sus garantías dentro de una región. Por ejemplo, si utilizas la técnica de redundancia de conmutación por error, solo se garantiza que la entrega de mensajes se realizará para los mensajes publicados en la misma región. El suscriptor podría recibir mensajes publicados en la región de resguardo antes de que los mensajes se publicaran en la región principal, incluso si los mensajes se publicaron primero en la región principal.
Optimiza a los editores
Sin importar cuál de las opciones de conmutación por error que elijas, hay algunos pasos de ajuste adicionales que debes seguir dentro de los propios publicadores. El ajuste del comportamiento del publicador garantiza un rendimiento óptimo con cargas altas. El agrupamiento en lotes de los mensajes es una forma de compensar la latencia por un costo reducido, pero no es una preocupación por la confiabilidad y, por lo tanto, no se trata aquí. En cambio, enfócate en algunos de los otros parámetros que son útiles para ajustar la confiabilidad, incluida la configuración de reintento y la configuración del control de flujo.
Las publicaciones pueden fallar por diferentes motivos, incluidas las transitorias, como la falta de disponibilidad de la red, o las que requieren la intervención del usuario, como los cambios de permisos. La biblioteca cliente de Pub/Sub reintenta errores transitorios con los parámetros especificados en la configuración de reintento. Esta configuración controla el comportamiento de la retirada exponencial en los reintentos de RPC de publicación que fallan por motivos transitorios. Si bien la configuración predeterminada suele funcionar bien en la mayoría de los casos, hay situaciones en las que es posible que desees ajustar estos valores.
Las dos propiedades que probablemente quieras ajustar son el tiempo de espera inicial de RPC y el tiempo de espera total. El tiempo de espera inicial de la RPC es el tiempo durante el que se le da a la primera RPC de publicación para completarse. Si cualquier RPC falla o se agota el tiempo de espera, se intenta otra con un tiempo de espera más largo hasta que se supere la cantidad total de solicitudes o el tiempo de espera total.
El tiempo de espera inicial se puede ajustar si tu publicador tiene restricciones de red o está lejos del centro de datos Google Cloud más cercano que ejecuta Pub/Sub. Las restricciones de red pueden ser limitaciones de la capacidad de procesamiento de la máquina en la que se ejecuta el publicador o el resultado de otros servicios que se ejecutan en la misma máquina y que consumen muchos recursos de la red. Si el tiempo de espera es demasiado corto, las RPC iniciales podrían fallar repetidamente, lo que generaría más intentos (con tiempos de espera más largos) para publicar de forma correcta. La necesidad repetida de reintentos aumenta la latencia de publicación. En esta situación, aumentar el tiempo de espera inicial podría acelerar las publicaciones.
Si la conexión de red no es confiable, aumentar el tiempo de espera total, así como el tiempo de espera inicial, podría ser de ayuda. Un tiempo de espera total aumentado le da a la RPC de publicación más tiempo para completarse de forma correcta. Si las RPC de publicación fallan constantemente con errores de plazo excedido, considera ajustar estos valores.
Los errores de plazo excedido continuo en la publicación también pueden indicar la necesidad de ajustar el control de flujo del publicador. Esta configuración te permite garantizar que tus publicadores sean resistentes a los aumentos repentinos de tráfico entrante que generan más mensajes que se enviarán a Pub/Sub. Un gran aumento en las solicitudes salientes podría sobrecargar la capacidad de CPU, memoria o red del publicador. Cuando la publicación se sobrecarga, no puede procesar solicitudes ni respuestas de publicación antes de que se agote el tiempo de espera. Como resultado, se generan aún más solicitudes de publicación y, en última instancia, se alcanza el tiempo de espera total. El control de flujo del publicador limita la cantidad de mensajes o bytes que pueden estar pendientes sin una respuesta de la solicitud de publicación. Limitar la cantidad de solicitudes de esta manera mantiene el uso de recursos en un nivel administrable, incluso durante los aumentos repentinos. Según cómo opere tu publicador, puedes permitir que las RPC de publicación posteriores esperen a que se complete la capacidad del publicador, ya que permite que Publication bloquee otras solicitudes. Como alternativa, puedes rechazar a los emisores de tu servicio si haces que el control de flujo muestre un error cuando se alcanza el límite de capacidad. Debes configurar cómo responde la biblioteca cliente del publicador con el comportamiento de límite excedido.
Cómo ajustar los suscriptores
También es posible que sea necesario ajustar los suscriptores para garantizar que funcionen de manera confiable. Al igual que con los publicadores, puedes ajustar la configuración de control de flujo de los suscriptores para asegurarte de que no se sobrecarguen. La biblioteca cliente del suscriptor usa la extracción de transmisión, en la que el cliente abre una transmisión persistente al servidor y el servidor envía mensajes a medida que están disponibles. Si hay un gran aumento en los mensajes publicados, es posible que el suscriptor reciba más mensajes de los que puede procesar. Con el control de flujo implementado, la cantidad de mensajes pendientes de confirmación para el cliente a la vez es limitada. Esto reduce la cantidad de mensajes que se administran de forma simultánea y se extiende su procesamiento durante un período más largo. Dispersar la carga permite que los suscriptores se mantengan debajo de cualquier limitación de recursos que afecte el procesamiento de mensajes, lo que puede generar un efecto en cascada que se desarrolle como la incapacidad para procesar cualquier mensaje.
El control de flujo por sí solo es suficiente si solo esperas que se procesen los aumentos repentinos en la cantidad de datos que, en última instancia, se reduzcan. Si el tráfico suele aumentar con el tiempo debido a un mayor uso, el control de flujo protege a los suscriptores. Sin embargo, es posible que siga acumulándose un trabajo pendiente y que los mensajes no se puedan entregar antes de que finalice el período de retención de mensajes. En esos casos, es posible que también desees configurar el ajuste de escala automático para que aumente la cantidad de suscriptores en respuesta al aumento de la cantidad de mensajes no confirmados. La forma de configurarlo depende de la plataforma que uses para tus suscriptores. Por ejemplo, el escalador automático de Compute Engine te permite escalar en función de métricas como la cantidad de mensajes sin entregar. El uso del ajuste de escala automático y el control de flujo te permite asegurarte de que tus suscriptores sean resistentes a otros aumentos repentinos a corto plazo en la capacidad de procesamiento de los mensajes y al crecimiento a largo plazo que requiere más potencia de procesamiento. Asegúrate de seguir las prácticas recomendadas para usar métricas de Pub/Sub como indicador de escalamiento.
Usa instantáneas y búsquedas para implementaciones seguras
La pérdida de mensajes suele ser un evento catastrófico. Pub/Sub ofrece al menos una entrega para todos los mensajes publicados. Sin embargo, el procesamiento correcto de estos mensajes depende del comportamiento del suscriptor. Si los mensajes se confirman de forma correcta, Pub/Sub no los vuelve a entregar. Por lo tanto, un error ingresado en el nuevo código de suscriptor que implementes y que confirme los mensajes sin haberlos procesado correctamente podría provocar la pérdida de mensajes inducida por el suscriptor. Pub/Sub ofrece la función de instantánea y búsqueda, que puede ayudarte a garantizar que proceses correctamente cada mensaje, incluso ante errores del suscriptor.
El patrón de cada implementación de suscriptor debe ser el siguiente:
La cantidad de tiempo que debes esperar antes de determinar si el suscriptor nuevo está funcionando puede variar según tu caso de uso. La única forma de salir del flujo de pasos es cuando se considera que un suscriptor está en funcionamiento. En ese momento, se puede borrar la instantánea.
El uso de instantáneas y búsquedas no pretende reemplazar las prácticas recomendadas relacionadas con el software que se ejecuta por primera vez en un entorno que no es de producción y la implementación gradual en producción. Proporcionan un nivel adicional de protección para garantizar el procesamiento confiable de los datos. La desventaja es que buscar la instantánea puede dar como resultado la entrega duplicada de mensajes que tu suscriptor procesó correctamente. Sin embargo, dado que Pub/Sub tiene una semántica de entrega al menos una vez de forma predeterminada, tus suscriptores ya son resistentes al reenvío de mensajes.