En esta guía, se proporciona información y un panorama general de las funciones de confiabilidad de Pub/Sub. Los temas que se abordan en este documento incluyen los siguientes:
- ¿Por qué elegir Pub/Sub?
- Conmutación por error
- Publicadores de ajuste fino
- Cómo ajustar los suscriptores
- Usa instantáneas y busca implementaciones seguras
¿Por qué elegir Pub/Sub?
Como paradigma de mensajería, el modelo de publicación y suscripción está diseñado 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, publican esos datos en un servicio de Pub/Sub, como Pub/Sub. El servicio entrega esos mensajes de forma asíncrona a los consumidores interesados que se suscribieron.
Como resultado, el servicio absorbe todas las complejidades de encontrar consumidores que estén 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 confiable y altamente escalable. Si bien el servicio controla gran parte de esto automáticamente, 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 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 de red más cercana donde 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 ejecutas 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 forma coherente. En el resto de esta sección, se explica cómo crear temas y suscripciones. Además, se analiza cómo colocar 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 una sola 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 y 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 a la red con suscriptores que tengan capacidad. Por lo tanto, como se muestra en la imagen anterior, los mensajes publicados en Estados Unidos se entregan a los suscriptores de Europa, y los mensajes publicados en Australia permanecen en ese país.
En las siguientes secciones, se analiza lo que sucede en diferentes situaciones de fallas.
Los suscriptores de Europa no están disponibles
Supongamos que los suscriptores de Europa se rechazaron o fallaron con frecuencia y no pudieron mantener una conexión con Pub/Sub. Si esto ocurriera, el servicio comenzaría a enviar mensajes a los suscriptores de Australia:
Los suscriptores de Europa y Australia no están disponibles
En caso de que todos los suscriptores no estén disponibles, Pub/Sub almacenará los mensajes hasta la duración de retención de mensajes configurada.
Una vez que los suscriptores se vuelven a conectar, se entregan los mensajes, a menos que la interrupción dure más que el período de retención de mensajes configurado. 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 en un tema por hasta 31 días. No elijas una duración de retención de mensajes inferior a la interrupción máxima que esperas o que estás dispuesto a tolerar.
Pub/Sub no está disponible en Europa
Aunque es poco frecuente, es posible que también debas 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 las solicitudes de publicación o suscripción, o la imposibilidad de entregar mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub falla en la región de Europa, la situación se verá muy similar a cuando fallan los suscriptores:
Ten en cuenta que, en este caso, los suscriptores de Europa no se transfieren a otra región, incluso si usan el extremo global. Pub/Sub no realiza la conmutación por error de forma automática de forma intencional. Imagina que los suscriptores son los que están causando un problema inesperado en Pub/Sub que genera falta de disponibilidad. Este tipo de problema se considera una interrupción importante. Sin embargo, el alcance del impacto de la interrupción puede limitarse a la región a la que se conectaron los suscriptores. Si el servicio les permitiera realizar la conmutación por error a otra región, los suscriptores también podrían provocar que no esté disponible allí, lo que generaría una falla en cascada en todo el servicio.
Los publicadores de Australia no están disponibles
Si los publicadores de una región dejan de estar disponibles, los mensajes que ya se publicaron se seguirán entregando 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 la red. Por lo tanto, los suscriptores de la región de Australia pueden dejar de recibir mensajes si los suscriptores de Europa tienen suficiente capacidad para controlar 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 evitar la entrega de mensajes; toda la región debe estar indisponible. Si Cloud Pub/Sub deja de estar disponible en una región donde los publicadores envían mensajes, es posible que los mensajes de esa región no se entreguen hasta que se restablezca por completo el servicio:
El mensaje se entrega de todos modos (suponiendo que no haya transcurrido el período de retención del mensaje), con una demora de la duración de la interrupción. Ten en cuenta que, al igual que los suscriptores, los publicadores de Estados Unidos tampoco restablecen la conexión a otra región cuando falla el servicio. Este comportamiento ayuda a evitar la probabilidad de fallas en cascada en las regiones debido a un publicador o suscriptor defectuoso.
Aislamiento
La semántica de conmutación por error predeterminada detallada afecta el aislamiento de datos y cómo la falta de disponibilidad de los publicadores, los suscriptores o Pub/Sub puede afectar el flujo de mensajes. Es posible que tu caso de uso requiera diferentes niveles de aislamiento. Por ejemplo, es posible que requieras la entrega de todos los mensajes dentro de la región.
Si no quieres aislamiento, la semántica predeterminada de conmutación por error detallada es suficiente. Debes crear un solo tema, una sola suscripción y colocar publicadores y suscriptores en todas las regiones seleccionadas. Si los suscriptores dejan de estar disponibles o Pub/Sub no funciona en la región a la que se conectan, la entrega falla para 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. Busca publicadores y suscriptores en cada una de esas regiones y haz que publiquen y se suscriban al tema y la suscripción regionales correspondientes, respectivamente. También debes usar extremos regionales para garantizar que los datos solo se muevan dentro de la región. En caso de fallas del publicador, del suscriptor o de Pub/Sub en una sola región, se detendrá la entrega de mensajes en esa región. La entrega de mensajes en temas y suscripciones para otras regiones no se verá afectada.
Por último, el aislamiento zonal, en el que se garantiza que los datos permanezcan dentro de 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 de conmutación por error predeterminada 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, incluidos tus clientes, en el servicio en el que se ejecutan tus publicadores o suscriptores, en la red o, en raras ocasiones, en Pub/Sub. Si necesitas que tus servicios sean resilientes a esas interrupciones, debes implementar tus propias redundancias. Por lo general, estas redundancias incluyen el uso de varias instancias de clientes de publicador y suscriptor, en las que cada una usa un extremo de ubicación diferente.
Es posible que desees tener resiliencia para dos alcances de impacto diferentes: zonal o regional. Estas son las opciones de configuración de cada una.
Resiliencia zonal
Pub/Sub tiene replicación entre zonas integrada. No es necesario que realices ningún paso especial para controlar las interrupciones de una sola zona que afectan el servicio en sí. Sin embargo, para tener resiliencia ante las interrupciones de tus clientes o tu red, es mejor ejecutar publicadores y suscriptores con la capacidad suficiente en varias zonas de la región. Si una sola zona está inactiva, los clientes de la otra zona pueden detectar el tráfico y procesar los mensajes. Se recomienda no publicar cambios en estos clientes de forma simultánea para que, si se introduce un error, las otras zonas sin modificar puedan seguir procesando los mensajes.
Resiliencia regional
Para resistir ante fallas regionales, configura redundancias adicionales en tus publicadores y suscriptores. Puedes ejecutar publicadores y suscriptores en varias regiones para abordar la posibilidad de interrupciones en esos clientes o en las redes.
Si deseas tener resiliencia ante posibles fallas de Pub/Sub en una región, debes tener un mecanismo de conmutación por error listo para controlar una interrupción de este tipo. Los enfoques posibles son una compensación entre la latencia de entrega de mensajes de extremo a extremo y tu costo.
Para minimizar la latencia en caso de que el costo no sea una preocupación, la mejor estrategia es publicar y suscribirse de forma simultánea en diferentes regiones. Primero, elige la cantidad de regiones en las que deseas tener 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 de publicador como regiones (uno para cada región) y usa un extremo de ubicación diferente para garantizar que los mensajes se dirijan a regiones distintas. Si usas temas separados, cada cliente del publicador debe publicar en el tema correspondiente por región. Para cada mensaje, el publicador llama a la publicación en cada cliente. Con las publicaciones redundantes, no es necesario volver a intentar las publicaciones si falla una sola.
Del mismo modo, cada suscriptor crea esa cantidad de clientes de suscriptor, uno para cada región, y usa un extremo de ubicación 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 las regiones que se usan para los publicadores y los suscriptores no necesariamente tienen que ser las mismas. Los suscriptores reciben mensajes en las tres suscripciones y los procesan.
Esta configuración tiene varias funciones y requisitos clave:
- Las interrupciones en una sola región no afectan el procesamiento de los mensajes que ya se publicaron 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 esté inactiva. Durante la interrupción, las llamadas de publicación fallan en la región afectada, pero se realizan correctamente en las demás.
- La latencia del procesamiento de mensajes no se ve afectada, siempre que esté disponible cualquiera de las regiones a través de las cuales fluyen los mensajes.
- El procesamiento de mensajes debe ser idempotente. Dado que cada mensaje se entregará varias veces, el procesamiento de mensajes debe ser resistente a los duplicados. En caso de una interrupción regional, es posible que algunos de esos duplicados lleguen 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 estaba experimentando una interrupción.
Ejecutar con este tipo de redundancia proporciona la mayor resiliencia 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 desventaja de multiplicar el costo de entrega de mensajes por la cantidad de regiones que se usan. También existe el costo adicional del uso de la red interregional para los mensajes que deben moverse entre regiones.
Otro enfoque para la redundancia es solo realizar la conmutación por error cuando fallan las solicitudes 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 tus publicadores y suscriptores a través de extremos de ubicación. Al igual que antes, no es necesario que sean la misma región. También tienes una región de resguardo para los publicadores y suscriptores que se usa cuando la región principal no está disponible.
Los publicadores solo publican contenido en la región principal (a través del extremo de ubicación) cuando sus solicitudes se envían correctamente. Cada vez que se determina que la región está inactiva, los publicadores comienzan a publicar contenido en la región de resguardo. Puedes determinar si la región está inactiva y si se produce una conmutación por error de dos maneras. 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 el porcentaje de errores en las solicitudes de publicación es lo suficientemente alto.
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 región de resguardo en todo momento. Se pueden usar las mismas regiones para la configuración principal y de resguardo para publicadores y 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 tuvo una conmutación por error.
- Detecta y cambia manualmente a los suscriptores a la región de resguardo a través de una configuración. Si detectas una interrupción, puedes realizar la conmutación por error a la región de resguardo y, luego, volver a la región principal cuando la interrupción haya terminado.
- Conmutación por error en los errores del suscriptor Si las solicitudes de suscriptores muestran errores, puedes usar esto como un indicador de que debes realizar la conmutación por error a la región de resguardo. Ten en cuenta que las bibliotecas cliente de Pub/Sub vuelven a intentar transmitir solicitudes de extracción de forma interna en errores transitorios, por lo que es posible que no puedas detectar que hay períodos prolongados de errores inesperados. Además, se espera que la tasa de error de extracción de transmisión sea del 100%, incluso durante el funcionamiento normal.
- Realiza la conmutación por error si el suscriptor pasa un tiempo inesperado sin recibir mensajes. Si se supone que hay una publicación coherente de los mensajes, los suscriptores siempre pueden recibirlos. Si pasa un período prolongado sin recibir ningún mensaje, es posible que haya un problema del suscriptor en Pub/Sub en la región principal. Para corregir esto, se falla en la región de resguardo.
De las cuatro opciones, la primera es ideal. Una conexión de suscriptor no cuesta dinero si no hay mensajes en ella. El único costo es el espacio en disco de la instancia adicional de la biblioteca cliente del suscriptor, que puede ser despreciable. También debes tener en cuenta la cuota de cantidad de conexiones de StreamingPull abiertas por 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. Es posible que los mensajes almacenados en la región que no está disponible no se puedan entregar a los suscriptores, independientemente de dónde se conecten. 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 indisponibilidad 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 del tiempo de conmutación por error a la región de resguardo.
Independientemente de la opción que elijas, ten en cuenta cómo esta puede interactuar con las funciones de Pub/Sub. Tanto la entrega ordenada como la entrega exactamente una vez ofrecen sus garantías dentro de una región. Por ejemplo, si usas la técnica de redundancia de resguardo, solo se garantiza que la entrega de mensajes sea correcta 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.
Publicadores de ajuste fino
Independientemente de la opción de conmutación por error que elijas, hay algunos pasos de ajuste adicionales que debes realizar en los publicadores. El ajuste del comportamiento del publicador asegura un rendimiento óptimo con cargas altas. El procesamiento por lotes de mensajes es una forma de compensar la latencia por un costo reducido, pero no es una preocupación de confiabilidad y, por lo tanto, no se aborda aquí. En su lugar, enfócate en algunos de los otros parámetros que son útiles para ajustar la confiabilidad, como la configuración de reintentos y la configuración de control de flujo.
Las publicaciones pueden fallar por diferentes motivos, incluidos los transitorios, como la falta de disponibilidad de la red, o los que requieren la intervención del usuario, como los cambios de permisos. La biblioteca cliente de Pub/Sub vuelve a intentar los 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 es más probable que desees ajustar son el tiempo de espera de RPC inicial y el tiempo de espera total. El tiempo de espera de RPC inicial es el tiempo que se le da a la primera RPC de publicación para que se complete. Si alguna RPC falla o se agota el tiempo de espera, se prueba otra con un tiempo de espera más prolongado 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 limitaciones de red o está 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 publicador o pueden ser el resultado de otros servicios que se ejecutan en la misma máquina y que requieren mucho uso de red. Si el tiempo de espera es demasiado corto, las RPC iniciales pueden fallar de forma reiterada, lo que genera que se necesiten más intentos (con tiempos de espera más largos) para realizar la publicación correctamente. 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, podría ser útil aumentar el tiempo de espera total y el inicial. Un tiempo de espera total mayor le da a la RPC de publicación más tiempo para completarse correctamente. Cuando las RPCs de publicación fallan de forma coherente con errores de vencimiento superado, considera ajustar estos valores.
Los errores continuos de vencimiento excedido en la publicación también pueden indicar la necesidad de ajustar el control de flujo del publicador. Esta configuración te permite asegurarte de que tus publicadores sean resilientes a los picos 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 CPU, la memoria o la capacidad de red del publicador. Cuando la publicación está sobrecargada, no puede procesar solicitudes ni respuestas de publicación antes de los tiempos de espera. Esto genera 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 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 la capacidad permitiendo que la publicación bloquee más solicitudes. Como alternativa, puedes enviarles un mensaje a los llamadores de tu servicio haciendo que el control de flujo muestre un error cuando se alcance la capacidad. Tú configuras 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 se deba realizar la sintonización de suscriptores para garantizar que funcionen de forma confiable. Al igual que 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 del suscriptor usa la transmisión de extracció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. En caso de 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, se limita la cantidad de mensajes no confirmados pendientes para el cliente en un momento determinado. Esto reduce la cantidad de mensajes que se controlan de forma simultánea y distribuye su procesamiento en un período más largo. La distribución de la carga permite que los suscriptores no superen las limitaciones de recursos que afectan el procesamiento de mensajes, lo que puede generar un efecto en cascada que se convierte en la incapacidad de procesar ningún mensaje.
El control de flujo por sí solo es suficiente si solo esperas aumentos repentinos en la cantidad de datos que se procesarán y que, en última instancia, disminuirán. Si el tráfico aumenta en general con el tiempo debido a un mayor uso, el control de flujo protege a los suscriptores. Sin embargo, es posible que se genere un backlog que siga acumulándose y que los mensajes no se puedan entregar antes de que venza la duración de retención de mensajes. En esos casos, también te recomendamos que configures el ajuste de escala automático para que aumente la cantidad de suscriptores en respuesta a una cantidad creciente de mensajes no confirmados. La forma en que configures esto depende de la plataforma de procesamiento que uses para tus suscriptores. Por ejemplo, el escalador de Compute Engine te permite escalar según métricas como la cantidad de mensajes no entregados. El uso del escalamiento automático y el control de flujo te permite asegurarte de que tus suscriptores sean resilientes a otros aumentos repentinos a corto plazo en la capacidad de procesamiento de mensajes y el crecimiento a largo plazo que requiere más potencia de procesamiento.
Usa instantáneas y busca implementaciones seguras
La pérdida de mensajes suele ser un evento catastrófico. Pub/Sub ofrece una 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 correctamente, Pub/Sub no los vuelve a entregar. Por lo tanto, un error introducido en el nuevo código de suscriptor que implementes que confirme 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áneas y búsqueda, que puede ayudarte a garantizar que proceses todos los mensajes correctamente, incluso si hay errores de suscriptores.
El patrón de cada implementación de suscriptor debe ser el siguiente:
El 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á trabajando, momento en el que se puede borrar la instantánea.
El uso de instantáneas y saltos no está destinado a reemplazar las prácticas recomendadas sobre cómo ejecutar el software por primera vez en un entorno que no sea 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 generar la entrega duplicada de los mensajes que tu suscriptor procesó correctamente. Sin embargo, dado que Pub/Sub tiene semántica de entrega de al menos una vez de forma predeterminada, tus suscriptores ya son resilientes a la reimpresión de mensajes.