En esta guía, se proporciona una descripción general de las características de confiabilidad de Pub/Sub. Los temas que se abordan en este documento incluyen lo siguiente:
- ¿Por qué Pub/Sub?
- Conmutación por error
- Perfeccionamiento de los publicadores
- Ajuste de suscriptores
- Usa instantáneas y busca implementaciones seguras
¿Por qué 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 productores que envían solicitudes directas a los consumidores con los datos, publican esos datos en un servicio de Pub/Sub, como Pub/Sub. El servicio entrega de manera asíncrona esos mensajes a los 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 que los productores de datos escriban 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 de forma automática, tienes control sobre 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 inherentemente 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 regionales, p.ej.,
us-central1-pubsub.googleapis.com, los publicadores y suscriptores se conectan a Pub/Sub en la región especificada. Cuando ejecutas publicadores o suscriptores fuera de Google Cloud, es mejor usar extremos regionales 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. También se analiza cómo colocar los publicadores y suscriptores para admitir diferentes tipos de conmutación por error y redundancia de datos.
Semántica de conmutación por error predeterminada
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 de Google Cloud de Europa y Australia. En el caso de que todos los suscriptores tengan suficiente capacidad para recibir mensajes, el flujo de mensajes se ve 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 que se almacenan los mensajes (los mensajes siempre persisten en varias zonas de la región en la que se publican). Pub/Sub prefiere enviar mensajes dentro de la misma región donde se publicaron cuando están disponibles los suscriptores. 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 arriba, los mensajes publicados en Estados Unidos se entregan a los suscriptores en Europa y los mensajes publicados en Australia permanecen en Australia.
Examinemos lo que sucede en diferentes situaciones de falla.
Los suscriptores en Europa no están disponibles
Supongamos que los suscriptores de Europa fallaron o fallaron con frecuencia, y no pueden mantener una conexión con Pub/Sub. Si esto sucediera, el servicio comenzaría a entregar mensajes a los suscriptores en Australia:
Los suscriptores en Europa y Australia no están disponibles
Si todos los suscriptores no están disponibles, Pub/Sub almacena los mensajes hasta la duración de retención de mensajes configurada.
Una vez que los suscriptores se vuelven a conectar, los mensajes se entregan, a menos que la interrupción dure más que la duración configurada para la retención de mensajes. De forma predeterminada, la retención de mensajes de suscripción se configura en 7 días. También puedes configurar la retención de mensajes sobre un tema por hasta 31 días. No elijas una duración de retención de mensajes más corta que la interrupción máxima que esperas o que estés dispuesto a tolerar.
Pub/Sub no está disponible en Europa
Aunque es poco común, también puedes tratar los 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 las solicitudes de suscripción o publicación, o la incapacidad de entregar mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub estuviese inactivo en la región de Europa, la situación sería muy similar 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 se usa el extremo global. Pub/Sub no realiza una conmutación por error automática. Imagina que son los suscriptores los que causan un problema inesperado en Pub/Sub, que tiene como resultado la falta de disponibilidad. Este tipo de problema se considera una interrupción grave. Sin embargo, el alcance del impacto de la interrupción se puede limitar a 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 la falta de disponibilidad allí, lo que provocaría una falla en cascada en el servicio.
Los publicadores en Australia no están disponibles
Si los editores de una región dejan de estar disponibles, los mensajes que ya se publicaron se entregarán a los suscriptores más cercanos:
Con el tiempo, los suscriptores consumen y confirman todos los mensajes. Cuando se envían mensajes, Pub/Sub intenta minimizar la distancia de red. Por lo tanto, los suscriptores en la región de Australia pueden dejar de recibir mensajes si tienen la capacidad suficiente para manejar todos los mensajes publicados en Estados Unidos.
Pub/Sub no está disponible en Estados Unidos
Pub/Sub escribe de forma síncrona los mensajes en varias zonas dentro de una región. Por lo tanto, una interrupción zonal no es suficiente para evitar la entrega de mensajes; toda la región no debe estar disponible. Si Cloud 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:
En última instancia, el mensaje se entrega (siempre que no haya pasado el período de retención de mensajes) y se retrase por la interrupción. Ten en cuenta que, de manera similar a los suscriptores, los publicadores en Estados Unidos no conmutan por error a otra región cuando falla el servicio. Este comportamiento ayuda a evitar la probabilidad de fallas en cascada en todas las regiones debido a un publicador o suscriptor defectuoso.
Aislamiento
La semántica de conmutación por error predeterminada que se detalla afecta el aislamiento de datos y la forma en que la falta de disponibilidad de los publicadores, suscriptores o Pub/Sub en sí pueden afectar el flujo de mensajes. Tu caso práctico puede requerir diferentes niveles de aislamiento, p.ej., recomendamos garantizar la entrega dentro de la región de todos los mensajes.
Si no quieres aislamiento, la semántica predeterminada de conmutación por error detallada es suficiente. Debes crear un solo tema y una sola suscripción, y ubicar a los publicadores y suscriptores en todas las regiones deseadas. Si los suscriptores no están disponibles o Pub/Sub está inactivo 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 salgan de una región, crea un tema y una suscripción para controlar los mensajes en cada región. Ubicar a los publicadores y suscriptores en cada una de esas regiones, y hacer que publiquen y se suscriban al tema regional y la suscripción correspondientes, respectivamente También debes usar extremos regionales para asegurarte de que los datos solo se muevan dentro de la región. En caso de fallas de los publicadores, suscriptores o 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 para otras regiones no se ve afectada.
Por último, el aislamiento zonal, en el que se garantiza que los datos permanecerán dentro de una sola zona, no es posible en Pub/Sub. Si necesitas que las zonas individuales sean independientes, usa Pub/Sub Lite.
Redundancia y redundancia controladas por el cliente
Es posible que la semántica de conmutación por error predeterminada de Pub/Sub no garantice por completo que los mensajes siempre puedan fluir desde los publicadores a los suscriptores si hay una interrupción en el medio. Las interrupciones pueden producirse 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 tales interrupciones, debes implementar tus propias redundancias. Por lo general, estas redundancias incluyen el uso de varias instancias de clientes publicadores y suscriptores en los que cada uno usa un extremo regional diferente.
Es posible que desees resiliencia en dos alcances de impacto diferentes: zonales o regionales. Estas son las opciones de configuración para cada una.
Resiliencia zonal
Pub/Sub tiene una replicación interzonal integrada. No es necesario realizar ningún paso especial para lidiar con las interrupciones de una sola zona que afectan al servicio en sí. Sin embargo, a fin de tener resiliencia ante las interrupciones para los clientes o la red, 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 captar el tráfico y procesar los mensajes. La práctica recomendada es no implementar cambios en estos clientes de forma simultánea, de modo que si se presenta un error, las demás zonas sin tocar puedan seguir procesando mensajes.
Resiliencia regional
A fin de ser resiliente ante 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 resistir las 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 una compensación 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 publicar siempre y de forma simultánea en diferentes regiones. Primero, elige la cantidad de regiones en las que deseas generar 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 publicadores como regiones (uno para cada región) y usa un extremo regional diferente a fin de garantizar que los mensajes se dirijan a regiones distintas. Si usas temas separados, cada cliente publicador debe publicar en el tema correspondiente por región. Para cada mensaje, las llamadas del publicador se publican en cada cliente. Con las publicaciones redundantes, no es necesario reintentar las publicaciones si alguna falla.
De manera similar, cada suscriptor crea que muchos clientes suscriptores (uno para cada región) y usa un extremo regional para conectarse a una región diferente. Si usas suscripciones diferentes para cada región, cada cliente suscriptor debe usar la suscripción correspondiente. Ten en cuenta que no es necesario que las regiones que usan los publicadores y los suscriptores sean las mismas. Los suscriptores reciben mensajes en 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 los mensajes ya publicados ni los que se publicaron 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 haya estado inactiva. Durante la interrupción, las llamadas de publicación fallan en la región afectada, pero se ejecutan de forma correcta en las otras.
- La latencia del procesamiento de mensajes no se ve afectada, siempre y cuando ninguna de las regiones a las que fluyen los mensajes esté disponible.
- El procesamiento de mensajes debe ser idempotente. Debido a que cada mensaje se entregará varias veces, el procesamiento de mensaje debe ser resiliente a los duplicados. En el caso de una interrupción regional, algunos de esos duplicados pueden llegar mucho más tarde que la primera vez que se entrega 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 resistencia a cualquier tipo de interrupción. Para los servicios internos de Google que dependen de Pub/Sub y requieren la mayor disponibilidad, se prefiere esta configuración. Sin embargo, esta configuración tiene 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 red interregional por 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 espera. En este caso, tienes una región principal a la que diriges a los publicadores y suscriptores a través de extremos regionales. Como antes, no es necesario que sean 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 regional) cuando sus solicitudes se envían correctamente. Cuando se determina que la región está inactiva, los publicadores comienzan a publicar en la región de resguardo. Hay dos formas de determinar si la región está inactiva y realizar una conmutación por error. Esto se puede hacer mediante un proceso manual, y la configuración se actualiza de forma dinámica en los publicadores. Los publicadores también pueden actualizar la configuración por su cuenta si la tasa de error en las solicitudes de publicación es suficientemente alta.
Los suscriptores siempre deben conectarse a la región principal a través del extremo regional. 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 región de resguardo en todo momento. Se pueden usar las mismas regiones en la instancia principal y en la de resguardo para publicadores y suscriptores. Si este es el caso, el suscriptor solo debe recibir mensajes mediante la región de la copia de seguridad si el publicador realizó una conmutación por error.
- Detecta y cambia de forma manual 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, volver a la región principal cuando haya disminuido.
- Falla en los errores de suscriptor Si las solicitudes de suscriptor muestran errores, puedes usar esto como un indicador de que debes realizar una conmutación por error a la región de resguardo. Ten en cuenta que las bibliotecas cliente de Pub/Sub reintentan la transmisión de solicitudes de extracción de forma interna en errores transitorios, por lo que es posible que no puedas detectar si hay períodos largos 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.
- Realiza una conmutación por error si el suscriptor pasa por un tiempo inesperado sin recibir mensajes. Si suponemos que se publican mensajes de manera constante, los suscriptores siempre pueden recibirlos. Si pasan un período prolongado sin recibir ningún mensaje, puede haber un problema de suscripción en Pub/Sub en la región principal. Esto se soluciona si se conmuta por error a la región de resguardo.
De las cuatro opciones, la primera es ideal. Una conexión de suscriptor no tiene costo si no hay mensajes que fluyen en ella. El único costo está en la huella de la instancia adicional de la biblioteca cliente suscriptor, que puede ser insignificante. También debes tener en cuenta la cantidad de conexiones de extracción de transmisión abierta por cuota regional.
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 compensación 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 después de que se resuelva la interrupción. Es posible que los mensajes almacenados en la región que no está disponible no puedan entregarse a los suscriptores, sin importar dónde estén conectados. Los mensajes publicados durante la interrupción en la región de resguardo pueden estar disponibles. Además, es posible que haya un período de falta de disponibilidad con mayores tasas de error para los publicadores o los suscriptores. Esto depende del método que se use para detectar una interrupción y el tiempo de conmutación por error a la región de resguardo.
Sin importar la opción que elijas, ten en cuenta cómo esto puede interactuar con las características de Pub/Sub. Tanto la entrega pedida como la exactamente una entrega ofrecen sus garantías dentro de una región. Por ejemplo, si usas la técnica de redundancia de conmutación por error, solo se garantiza que la entrega de mensajes esté en orden para los mensajes publicados en la misma región. El suscriptor podría recibir mensajes publicados en la región de resguardo antes que los mensajes publicados en la región principal, incluso si los mensajes se publicaron primero en la región principal.
Perfeccionamiento de los publicadores
Sin importar la opción de conmutación por error que elijas, hay algunos pasos de ajuste adicionales que quieres realizar dentro de los mismos publicadores. El ajuste del comportamiento del editor garantiza un rendimiento óptimo bajo cargas altas. Agrupar los mensajes en lotes es una forma de sacrificar 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 reintentos y la configuración del control de flujo.
Las publicaciones pueden fallar por diversos motivos, incluidos aquellos transitorios, como la falta de disponibilidad de la red, o aquellos que requieren intervención del usuario, como cambios en los permisos. La biblioteca cliente de Pub/Sub vuelve a intentar errores temporales con los parámetros especificados en la configuración de reintentos. Esta configuración controla el comportamiento de la retirada exponencial en los reintentos de las RPC de publicación que fallan por motivos transitorios. Si bien la configuración predeterminada suele funcionar bien en la mayoría de las situaciones, hay situaciones en las que es posible que desees ajustar estos valores.
Es probable que las dos propiedades que desees ajustar sean el tiempo de espera inicial de la RPC y el tiempo de espera total. El tiempo de espera inicial de la RPC es el tiempo durante el que se le da la primera RPC de publicación para completar. Si alguna RPC falla o se agota el tiempo de espera, se prueba otra con un tiempo de espera más largo hasta que se supera 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á muy lejos del centro de datos de Google Cloud más cercano que ejecuta Pub/Sub. Las restricciones de red pueden ser limitaciones en la capacidad de procesamiento de la máquina en la que se ejecuta el editor, o podrían ser el resultado de otros servicios que se ejecutan en la misma máquina y que requieren mucha red. Con el tiempo de espera configurado demasiado corto, las RPC iniciales podrían fallar varias veces, lo que generaría más intentos (con tiempos de espera más largos) para publicarse con éxito. La necesidad repetida de reintentos aumenta la latencia de publicación. En esta situación, aumentar el tiempo de espera inicial podría generar publicaciones más rápidas.
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 útil. Un tiempo de espera total mayor otorga a la RPC de publicación más tiempo para completarse de forma correcta. Cuando las RPC de publicación fallan de manera constante y tienen errores de plazo de entrega, considera ajustar estos valores.
Los errores de exceso de fecha límite continua en la publicación también pueden indicar la necesidad de ajustar el control de flujo del editor. Esta configuración te permite asegurarte de que tus publicadores sean resilientes a los aumentos repentinos de tráfico entrante que generan más mensajes para enviar a Pub/Sub. Un gran aumento en las solicitudes salientes podría sobrecargar la capacidad de la CPU, la memoria o la red del publicador. Cuando la publicación está sobrecargada, no puede procesar solicitudes ni respuestas de publicación antes de que se agote el tiempo de espera. Esto genera aún más solicitudes de publicación y, en última instancia, 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 que se puede administrar, incluso durante los aumentos repentinos. Según cómo funcione tu publicador, puedes permitir que las RPC de publicación posteriores esperen a la capacidad. Para ello, permite que la publicación bloquee más solicitudes. Como alternativa, para enviar a los emisores de tu servicio, el control de flujo mostrará un error cuando se alcance la capacidad. Configura la forma en que la biblioteca cliente del publicador responde con el comportamiento de límite excedido.
Ajuste de suscriptores
Es posible que también se necesite un ajuste de los suscriptores para garantizar que funcionen correctamente. Al igual que con los publicadores, puedes ajustar la configuración del control de flujo de los suscriptores para asegurarte de que no se sientan abrumados. La biblioteca cliente de suscriptor usa la extracción de transmisión, en la que el cliente abre una transmisión continua al servidor y este envía mensajes a medida que están disponibles. En el caso de que haya un gran aumento en los mensajes publicados, el suscriptor puede recibir más mensajes de los que puede procesar. Con el control de flujo implementado, la cantidad de mensajes no confirmados pendientes para el cliente a la vez es limitada. Esto reduce la cantidad de mensajes que se manejan de forma simultánea y aumenta su procesamiento durante un período más largo. La distribución de la carga permite que los suscriptores se mantengan por debajo de cualquier limitación de recursos que afecte el procesamiento de mensajes, lo que puede generar un efecto de cascada que se convierte en la incapacidad de procesar cualquier mensaje.
El control de flujo por sí solo es suficiente si solo esperas aumentos repentinos en la cantidad de datos para procesar que, en última instancia, se apartan. 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 se acumule trabajo acumulado y que se generen mensajes que no se puedan entregar antes de que finalice el período de retención de mensajes. En esos casos, también puedes configurar el ajuste de escala automático para que aumenten los suscriptores en respuesta a una cantidad creciente de mensajes no confirmados. La configuración depende de la plataforma de procesamiento que uses para tus suscriptores. Por ejemplo, el escalador automático de Google Compute Engine te permite escalar en función de métricas como la cantidad de mensajes no entregados. El uso del ajuste de escala automático y del control de flujo te permite asegurarte de que tus suscriptores sean resistentes a otros picos a corto plazo en la capacidad de procesamiento de mensajes y el crecimiento a largo plazo que requiere más potencia de procesamiento.
Usar instantáneas y buscar implementaciones seguras
La pérdida de mensajes suele ser un evento catastrófico. Pub/Sub garantiza la entrega al menos una vez para todos los mensajes publicados. Sin embargo, el procesamiento correcto de estos mensajes depende del comportamiento de los suscriptores. Si los mensajes se confirman de forma correcta, Pub/Sub no los vuelve a entregar. Por lo tanto, un error que se ingresa en un nuevo código de suscriptor que implementas y que reconoce los mensajes sin procesarlos correctamente podría provocar la pérdida de mensajes inducidos por el suscriptor. Pub/Sub ofrece la función de instantánea y búsqueda, que puede ayudarte a garantizar que proceses todos los mensajes de forma correcta, incluso frente a errores en los suscriptores.
El patrón para cada implementación del suscriptor debe ser el siguiente:
El tiempo de espera antes de determinar si el nuevo suscriptor funciona puede variar según tu caso práctico. La única forma de salir del flujo de pasos es cuando se considera que un suscriptor está en funcionamiento, momento en el que se puede borrar la instantánea.
El uso de la instantánea y la búsqueda no reemplazan las prácticas recomendadas para el primer software en ejecución en un entorno que no es de producción y la implementación gradual en la producción. Solo proporcionan un nivel adicional de protección para garantizar el procesamiento confiable de tus datos. La compensación es que, si intentas obtener la instantánea, es posible que se dupliquen los 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 resilientes a la entrega de mensajes de nuevo.