En esta guía, se proporciona una comprensión y un panorama general de las características de confiabilidad de Pub/Sub. Los temas que se abarcan en este documento son los siguientes:
- ¿Por qué elegir Pub/Sub?
- Conmutación por error
- Cómo optimizar a los editores
- Cómo optimizar los suscriptores
- Usa instantáneas y búsquedas para implementaciones seguras
¿Por qué elegir Pub/Sub?
Como paradigma de mensajería, la publicación-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 los consumidores interesados que se suscribieron.
El resultado es que el servicio absorbe todas las complejidades de buscar 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 controla gran parte de esto automáticamente, puedes controlar 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 usas el extremo global, pubsub.googleapis.com, los publicadores y los 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 forma coherente. En el resto de esta sección, se explica cómo crear temas y suscripciones. Además, se analiza cómo ubicar 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 editores se encuentran en regiones de Estados Unidos y Australia, y los suscriptores se encuentran en las regiones de Google Cloud de Europa y Australia. Si todos los suscriptores tienen la 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 donde 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 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 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 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 de Europa dejaron de estar disponibles o fallaban con frecuencia, y no pudieron mantener una conexión con Pub/Sub. Si esto ocurriera, el servicio empezaría a entregar mensajes a los suscriptores de Australia:
Los suscriptores en Europa y Australia no están disponibles
En el caso de que ningún suscriptor esté disponible, Pub/Sub almacena los mensajes hasta el período de retención de mensajes configurado.
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 de retención de mensajes. 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 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 frecuente, es posible que también quieras lidiar con 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 incapacidad de entregar mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub fuera de la región de Europa, la situación es muy similar a cuando los suscriptores están inactivos:
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 de forma intencional no realiza la conmutación por error automáticamente. Imagina que son los propios 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 incluirse 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 generaría una falla en cascada en todo el servicio.
Los editores en Australia no están disponibles
Si los publicadores de una región dejan de estar disponibles, los mensajes que ya se publicaron se entregarán a los suscriptores más cercanos de todos modos:
Finalmente, 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 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 para 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 no estar disponible. Si Cloud Pub/Sub no está disponible en una región donde los publicadores están enviando 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 (suponiendo que no pasó el período de retención de mensajes), que se retrasa por la duración de la interrupción. Ten en cuenta que, al igual que los suscriptores, los publicadores de Estados Unidos también no conmutan por error a otra región cuando falla el servicio. Este comportamiento ayuda a prevenir la probabilidad de fallas en cascada en todas las regiones debido a un publicador o un suscriptor con errores.
Aislamiento
La semántica predeterminada de conmutación por error que se detalla en el aislamiento de datos y en cómo la falta de disponibilidad de los publicadores, suscriptores o Pub/Sub puede afectar el flujo de mensajes. Tu caso de uso puede 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 aislamiento, la semántica detallada de conmutación por error predeterminada es suficiente. Debes crear un solo tema y una sola suscripción, y ubicar a los publicadores y suscriptores en todas las regiones seleccionadas. Si los suscriptores dejan de estar disponibles o Pub/Sub está inactivo en la región a la que se conectan, la entrega conmuta por error a los suscriptores en 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. Localiza a los 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 asegurarte de que los datos solo se transfieran dentro de la región. En caso de fallas del publicador, suscriptor 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 de otras regiones no se ve 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.
Redundancia y conmutación por error 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 intermedia. Las interrupciones pueden ocurrir en varios lugares diferentes, incluidos tus clientes, en el servicio en el que se ejecutan los publicadores o suscriptores, en la red o, incluso, rara vez 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 publicadores y suscriptores, en las que cada una usa un extremo de ubicación diferente.
Se recomienda contar con resiliencia para dos alcances de impacto diferentes: zonal o regional. A continuación, se indican las opciones de configuración para cada uno.
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 resistir las interrupciones de los clientes o de 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 recibir el tráfico y procesar los mensajes. Se recomienda no publicar los cambios en estos clientes de forma simultánea para que, si se introduce un error, las otras zonas intactas puedan continuar procesando mensajes.
Resiliencia regional
A fin de ser resiliente a las 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 herramientas de redes.
Si deseas ser resiliente a 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 representan un equilibrio entre la latencia de entrega de mensajes de extremo a extremo y tu costo.
Para minimizar la latencia en el caso de que el costo no sea una preocupación, la mejor estrategia es publicar y suscribirse siempre de forma simultánea en diferentes regiones. Primero, elige la cantidad de regiones en las que deseas 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 (una 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 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 volver a intentar las publicaciones si alguna falla.
De manera similar, cada suscriptor crea tantos 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 no es necesario que las regiones que se usan para publicadores y 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 publicados durante la interrupción. Debido a que los mensajes se publicaron en varias regiones, aún están disponibles en otras regiones en caso de que una región no esté disponible. Durante la interrupción, las llamadas de publicación fallan en la región afectada, pero tienen éxito en las otras.
- La latencia de procesamiento de mensajes no se ve afectada, siempre que alguna de las regiones por las que fluyen los mensajes esté disponible.
- El procesamiento de mensajes debe ser idempotente. Dado que cada mensaje se entregará varias veces, el procesamiento del mensaje debe ser resistente a los duplicados. En el caso de una interrupción regional, algunos de esos duplicados pueden aparecer 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 experimentaba una interrupción.
Ejecutar con este tipo de redundancia proporciona la mayor resiliencia a cualquier tipo de interrupción. Se prefiere esta configuración para los servicios internos de Google que dependen de Pub/Sub y requieren la mayor disponibilidad. Sin embargo, con esta configuración se multiplica el costo de la entrega de mensajes por la cantidad de regiones usadas. También existe el costo adicional del uso de la red interregional para los mensajes que tienen que trasladarse 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 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 tienen que ser 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 correctamente. Cuando se determina que la región está inactiva, los publicadores comienzan a publicar en la región de resguardo. Determinar si 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 publicadores también pueden actualizar la configuración 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 región de resguardo en todo momento. Se pueden usar las mismas regiones para la 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 la copia de seguridad si el publicador realizó una conmutación por error.
- Detectar y cambiar de forma manual los suscriptores a la región de resguardo a través de una configuración Si detectas una interrupción, puedes realizar una conmutación por error a la región de resguardo y, luego, regresar a la región principal cuando la interrupción haya desaparecido.
- Conmutación por error por errores del suscriptor. Si las solicitudes de los suscriptores 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 reintentan las solicitudes de extracción de transmisió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 inesperadamente prolongado 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 la conmutación 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 en ella. El único costo se encuentra en el 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 abiertas 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 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 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 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 conmutación por error a la región de resguardo.
No importa qué opción elijas, ten en cuenta cómo esto puede interactuar con las características de Pub/Sub. Tanto la entrega por pedido como la entrega exacta 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 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 de que los mensajes se publicaran en la región principal, incluso si los mensajes se publicaron primero en la región principal.
Cómo optimizar a los editores
Sin importar cuál de las opciones de conmutación por error elijas, debes seguir algunos pasos de ajuste adicionales con los mismos publicadores. Ajustar el comportamiento del publicador garantiza un rendimiento óptimo bajo cargas altas. El agrupamiento de mensajes en lotes es una forma de compensar la latencia para reducir el costo, pero no es tanto una preocupación de confiabilidad y, por lo tanto, no se aborda 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 diferentes motivos, incluidos los transitorios, como la falta de disponibilidad de la red, o los que requieren la intervención del usuario, como cambios en los permisos. La biblioteca cliente de Pub/Sub reintenta los errores transitorios mediante los parámetros especificados en la configuración de reintentos. 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 las situaciones, hay situaciones en las que es posible que desees ajustar estos valores.
Las dos propiedades que probablemente desees 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 que se tiene para completar la primera RPC de publicación. Si una RPC falla o se agota el tiempo de espera, otra se intenta 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á lejos del centro de datos de Google Cloud más cercano que ejecuta Pub/Sub. Las restricciones de red podrían ser limitaciones en la capacidad de procesamiento de la máquina en la que se ejecuta el publicador o podrían ser el resultado de otros servicios que se ejecutan en la misma máquina y que consumen mucha red. Si el tiempo de espera configurado es demasiado corto, las RPC iniciales podrían fallar varias veces, lo que provoca que se necesiten más intentos (con tiempos de espera más largos) para publicar correctamente. La necesidad repetida de reintentos aumenta la latencia de publicación. En este caso, 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 y el inicial podría ayudar. Un mayor tiempo de espera total le da a la RPC de publicación más tiempo para completarse de forma correcta. Cuando las RPC de publicación fallan de manera constante con errores en el plazo excedido, considera ajustar estos valores.
Los errores relacionados con el plazo continuo 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 resistentes a los aumentos repentinos de tráfico entrante que generan más mensajes que se enviarán a Pub/Sub. Un gran aumento de las solicitudes salientes podría sobrecargar la CPU, la memoria o la capacidad de 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 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, ya que permite que la publicación bloquee más solicitudes. Como alternativa, puedes enviar un mensaje de error a los emisores de tu servicio si el control de flujo muestra un error cuando se alcanza la capacidad. Configuras cómo responde la biblioteca cliente del publicador con el comportamiento de límite excedido.
Cómo optimizar los suscriptores
Es posible que también sea necesario ajustar el recuento de suscriptores para garantizar que funcionen de forma confiable. Al igual que con los publicadores, puedes ajustar la configuración del control de flujo de los suscriptores para asegurarte de que no se abrumen. 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 este 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 no confirmados pendientes para el cliente en un momento determinado es limitada. Esto reduce la cantidad de mensajes que se manejan de forma simultánea y se extiende su procesamiento durante un período más largo. La distribución de la carga permite que los suscriptores se mantengan bajo las limitaciones de recursos que afectan el procesamiento de mensajes, lo que puede generar un efecto de cascada que se desarrolla 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 retroceden. Si el tráfico suele aumentar con el tiempo debido al mayor uso, el control de flujo protege a los suscriptores. Sin embargo, es posible que se sigan acumulando tareas pendientes y que los mensajes no se puedan entregar antes de que pase 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 aumentar la cantidad de 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 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 el control de flujo te permite asegurarte de que los suscriptores sean resistentes a otros aumentos a corto plazo en la capacidad de procesamiento de mensajes y al crecimiento a largo plazo que requiere más capacidad de procesamiento.
Usa instantáneas y búsquedas para implementaciones seguras
Por lo general, la pérdida de mensajes es 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 correctamente, Pub/Sub no los vuelve a entregar. Por lo tanto, un error ingresado en el nuevo código de suscriptor que implementas y que confirma los mensajes sin haberlos procesado correctamente podría provocar la pérdida de mensajes inducido 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 si detectas errores de suscriptores.
El patrón para cada implementación de suscriptor debe ser el siguiente:
La cantidad de tiempo que hay que esperar antes de determinar si el suscriptor nuevo funciona puede variar según el caso de uso. La única forma de salir del flujo de pasos es cuando se considera que un suscriptor está trabajando y, en ese momento, se puede borrar la instantánea.
El uso de instantáneas y búsquedas no pretende reemplazar las prácticas recomendadas en torno a la primera ejecución de software en un entorno que no es de producción y la implementación gradual en la producción. Proporcionan un nivel adicional de protección para garantizar un procesamiento confiable de los datos. La compensación es que buscar esa instantánea puede dar como resultado la entrega duplicada de los mensajes que el suscriptor procesó correctamente. Sin embargo, dado que Pub/Sub tiene al menos una semántica de entrega de forma predeterminada, tus suscriptores ya son resilientes a la entrega de mensajes nuevamente.