En esta guía, se proporciona información y una descripción general de las funciones de confiabilidad de Pub/Sub.
¿Por qué elegir Pub/Sub?
Como paradigma de mensajería, la publicación y suscripción se diseñó para desacoplar 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.
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 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.
Aislamiento
De forma predeterminada, 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 endpoint global, pubsub.googleapis.com, los publicadores y los suscriptores se conectan a la región más cercana a la red en la que se ejecuta Pub/Sub. Cuando se usan los extremos regionales, como us-central1-pubsub.googleapis.com, o los extremos de ubicación, como pubsub.us-central1.rep.googleapis.com, los publicadores y suscriptores se conectan a Pub/Sub en la región especificada. Cuando ejecutes publicadores o suscriptores fuera de Google Cloud, lo mejor es usar extremos regionales o de ubicación para garantizar que los mensajes fluyan entre las regiones esperadas de manera coherente.
Aislamiento regional
Para minimizar la infraestructura de la que dependen las operaciones de publicación y suscripción fuera de una sola región, y para garantizar que todos los datos permanezcan aislados en esa región, sigue estos pasos:
Crea un tema por región.
Si bien el espacio de nombres de Pub/Sub es global y no puedes vincular temas y suscripciones a una región específica, los metadatos de todos los recursos se replican en los almacenes de datos locales dentro de la región. Por lo tanto, una vez que creas un recurso, su configuración está disponible incluso en caso de que se produzca un problema en otra región. Ten en cuenta que las actualizaciones de la configuración del tema o de la suscripción pueden no propagarse de inmediato en caso de interrupción.
Evita usar extremos globales.
En su lugar, usa extremos regionales cuando estén disponibles y extremos de ubicación cuando no estén disponibles los extremos regionales. Los extremos regionales ofrecen más aislamiento regional, pero aún no están disponibles en todas las regiones.
Usa una política de almacenamiento de mensajes y establece
enforceInTransitenTrue.Con la opción Aplicar en tránsito habilitada, los datos nunca salen de la región y todos los clientes que se conectan al tema en una región específica establecen la política de almacenamiento de mensajes en esa región.
Con los temas configurados de esta manera, puedes tener la certeza de que todas las operaciones de publicación y suscripción escriben y leen datos exclusivamente dentro de la región. En caso de fallas del publicador, del suscriptor o de Pub/Sub en una sola región, se detiene la entrega de mensajes en esa región. La entrega de mensajes en temas y suscripciones de otras regiones no se ve afectada.
Si también necesitas que las operaciones administrativas y el espacio de nombres de tus temas y suscripciones estén aislados de forma regional, considera usar Managed Service para Apache Kafka.
Conmutación por error
Si no necesitas aislamiento regional, te recomendamos que aproveches la capacidad de Pub/Sub para entregar mensajes de manera eficiente en varias regiones y, así, lograr capacidades de conmutación por error multirregional. En el resto de esta sección, se explica cómo crear temas y suscripciones, y cómo ubicar 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 editores se encuentran en regiones de Australia y Estados Unidos, y los suscriptores, en las Google Cloud regiones de Australia y Europa. En el caso en que 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 y las S, 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 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 hay suscriptores disponibles. De lo contrario, envía los mensajes a la región más cercana a 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 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 de Europa no están disponibles
Supongamos que se rechazaron los suscriptores de Europa o que se bloquean con frecuencia y no pueden 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 el 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 un período de retención de mensajes más corto 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 frecuente, también es posible que 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 incapacidad de entregar mensajes publicados a los suscriptores. Por ejemplo, si Pub/Sub no estuviera disponible en la región de Europa, la situación sería muy similar a la que se produce cuando los suscriptores no están disponibles:
Ten en cuenta que, en este caso, los suscriptores de 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ática de forma intencional. Imagina que son los suscriptores los que causan un problema inesperado en Pub/Sub que genera una 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 permitiera conmutar por error a otra región, los suscriptores también podrían causar indisponibilidad allí, lo que provocarí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 red. Por lo tanto, los suscriptores de la región de Australia pueden dejar de recibir mensajes si los suscriptores de Europa tienen capacidad suficiente 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 no 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 se restablezca por completo el servicio:
En última instancia, el mensaje se entrega (siempre y cuando no haya pasado el período de retención de mensajes), pero se retrasa 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 evitar la probabilidad de fallas en cascada en las regiones debido a un publicador o suscriptor defectuoso.
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 diferentes, incluidos tus clientes, el servicio en el que se ejecutan tus publicadores o suscriptores, la red o incluso, en raras ocasiones, en Pub/Sub. Si necesitas que tus servicios sean resistentes a este tipo de 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.
Es posible que desees tener capacidad de recuperación ante dos tipos diferentes de alcance del impacto: zonal o regional. Estas son las opciones de configuración para cada uno.
Resiliencia zonal
Pub/Sub tiene replicación entre zonas integrada. No es necesario que realices ningún paso especial para solucionar las interrupciones de una sola zona que afecten al servicio en sí. Sin embargo, para tener resiliencia ante las interrupciones de tus clientes o de la red, lo mejor es 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. 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 seguir procesando 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 hacer frente a 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 hacer frente a una interrupción de este tipo. Los enfoques posibles representan 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 un problema, 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 haya (uno para cada región) y usa un extremo de ubicación diferente para garantizar que los mensajes se dirijan a regiones distintas. Si se usan temas separados, cada cliente publicador debe publicar en el tema correspondiente para cada región. Para cada mensaje, el publicador llama a publish en cada cliente. Con las publicaciones redundantes, no es necesario volver a intentarlo si falla alguna de ellas.
Del mismo modo, 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 en las tres suscripciones y los procesan.
Esta configuración tiene varios requisitos y funciones clave:
- Las interrupciones en una sola región no afectan el procesamiento de los mensajes ya publicados ni los que se publican durante la interrupción. Como los mensajes se publicaron en varias regiones, siguen estando 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 realizan correctamente en las demás.
- La latencia del procesamiento de mensajes no se ve afectada siempre que esté disponible cualquiera de las regiones por las que 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 después de 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 capacidad de recuperación ante cualquier tipo de interrupción. Esta configuración es la preferida para los servicios internos de Google que dependen de Pub/Sub y requieren la mayor disponibilidad. Sin embargo, esta configuración tiene la desventaja de multiplicar el costo de la entrega de mensajes por la cantidad de regiones utilizadas. También se suma el costo adicional del uso de la red interregional para los mensajes que deben trasladarse entre regiones.
Otro enfoque para la redundancia es conmutar por error solo cuando fallan las solicitudes o los mensajes no fluyen de los publicadores a los suscriptores según lo esperado. 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 sea la misma región. También tendrás una región de respaldo para los publicadores y suscriptores que se usará 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. Cada vez que se determina que la región está inactiva, los publicadores comienzan a publicar en la región de respaldo. Se puede determinar que la región está inactiva y realizar la conmutación por error de dos maneras. Se puede hacer con un proceso manual, y la configuración se actualiza de forma dinámica en los editores. 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 use la región de respaldo con uno o más de los siguientes activadores:
- Siempre se debe suscribir 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 instancia principal y la alternativa, tanto para los publicadores como para 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 conmutó por error.
- Detectar y cambiar manualmente los suscriptores a la región de respaldo a través de una configuración Si detectas una interrupción, puedes conmutar por error a la región de respaldo y, luego, volver a la región principal cuando la interrupción haya disminuido.
- Conmutación por error en caso de errores del suscriptor Si las solicitudes de los suscriptores devuelven errores, puedes usar esto como indicación de que debes conmutar por error a la región de respaldo. Ten en cuenta que las bibliotecas cliente de Pub/Sub reintentan las solicitudes de extracción de transmisión de forma interna en caso de errores transitorios, por lo que es posible que no puedas detectar que hay largos períodos de errores inesperados. Además, se espera que la tasa de error de StreamingPull sea del 100%, incluso durante el funcionamiento normal.
- Realiza una conmutación por error si el suscriptor pasa un tiempo inesperadamente largo sin recibir mensajes. Si se publican mensajes de forma constante, los suscriptores siempre podrán recibirlos. Si pasan por un período prolongado sin recibir mensajes, es posible que haya un problema del lado de la suscripción en Pub/Sub en la región principal. Esto se corrige con la conmutación por error a la región de respaldo.
De las cuatro opciones, la primera es la ideal. Una conexión de suscriptor no cuesta dinero si no fluyen mensajes 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 cuota de cantidad de conexiones de extracción de transmisión 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 comenzara 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 estén conectados. Es posible que estén disponibles los mensajes publicados durante la interrupción en la región de respaldo. Además, es posible que haya un período de no 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 del tiempo que se tarde en conmutar por error a la región de respaldo.
Sin importar la opción que elijas, ten en cuenta cómo 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 conmutación por error, se garantiza que la entrega de mensajes se realizará en orden solo para los mensajes publicados en la misma región. El suscriptor podría recibir mensajes publicados en la región de respaldo antes que los mensajes publicados en la región principal, incluso si los mensajes se publicaron primero en la región principal.
Ajuste de publicadores
Independientemente de la opción de conmutación por error que elijas, hay algunos pasos de ajuste adicionales que debes realizar en los publicadores. Ajustar el comportamiento del publicador garantiza un rendimiento óptimo con una carga alta. El procesamiento por lotes de mensajes es una forma de intercambiar 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, incluidos los parámetros de configuración de reintentos y los parámetros de 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 reintenta los errores transitorios con los parámetros especificados en la configuración de reintentos. Estos parámetros de configuración controlan 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 tal vez quieras ajustar estos valores.
Las dos propiedades que probablemente 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 otorga a la primera RPC de publicación para que se complete. Si alguna RPC falla o se agota su tiempo de espera, se intenta 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 limitaciones 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 en el rendimiento 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 mucha red. Si el tiempo de espera es demasiado corto, las RPCs iniciales podrían fallar repetidamente, lo que requeriría 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 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 y el tiempo de espera inicial podría ayudar. Un aumento en el tiempo de espera total le da más tiempo a la RPC de publicación para completarse correctamente. Cuando las RPC de publicación fallan de forma constante con errores de tiempo de espera excedido, considera ajustar estos valores.
Los errores continuos de superación del plazo en la publicación también pueden indicar la necesidad de ajustar el control de flujo del publicador. Estos parámetros de configuración te permiten garantizar que tus publicadores sean resistentes 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 las solicitudes o 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, 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 picos. Según cómo opere tu publicador, puedes permitir que las RPC de publicación posteriores esperen capacidad permitiendo que la publicación bloquee más solicitudes. Como alternativa, puedes rechazar las llamadas a tu servicio haciendo que el control de flujo devuelva un error cuando se alcance la capacidad. Configuras cómo responde la biblioteca cliente del publicador con el comportamiento de límite excedido.
Suscriptores de ajuste
También es posible que se requiera un ajuste del suscriptor para garantizar que funcione 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 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. En caso de 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, se limita la cantidad de mensajes pendientes no confirmados que se envían al cliente en un momento determinado. Esto reduce la cantidad de mensajes que se controlan de forma simultánea y distribuye su procesamiento durante un período más largo. Distribuir la carga permite que los suscriptores se mantengan dentro de las limitaciones de recursos que afectan el procesamiento de mensajes, lo que puede generar un efecto en cascada que se convierta en la incapacidad de procesar cualquier mensaje.
El control de flujo por sí solo es suficiente si solo esperas picos en la cantidad de datos que se deben procesar y que, en última instancia, disminuyen. Si el tráfico aumenta de forma general con el tiempo debido a un mayor uso, el control de flujo protege a los suscriptores. Sin embargo, puede generar un backlog que siga acumulándose y que impida que se entreguen los mensajes antes de que pase la duración de retención de mensajes. En estos casos, también puedes configurar el ajuste de escala automático para aumentar la cantidad de suscriptores en respuesta a una creciente cantidad de mensajes no confirmados. La forma en que configures esto dependerá de la plataforma de procesamiento que uses para tus suscriptores. Por ejemplo, el autoescalador de Compute Engine te permite escalar en función de métricas como la cantidad de mensajes no entregados. Si usas el ajuste de escala automático y el control de flujo, puedes asegurarte de que tus suscriptores sean resistentes a otros aumentos repentinos a corto plazo en la capacidad de procesamiento de mensajes y al crecimiento a largo plazo que requiere más potencia de procesamiento. Asegúrate de seguir las prácticas recomendadas para usar las métricas de Pub/Sub como un indicador de escalamiento.
Usa la función de instantáneas y búsqueda para implementaciones seguras
La pérdida de mensajes suele ser un evento catastrófico. Pub/Sub ofrece la entrega al menos una vez 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 introducido en el nuevo código de suscriptor que implementes y 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ánea y búsqueda, que puede ayudarte a garantizar que proceses cada mensaje correctamente, incluso en caso de errores del suscriptor.
El patrón para cada implementación de suscriptor debe ser el siguiente:
El tiempo que debes esperar antes de determinar si el nuevo suscriptor funciona puede variar según tu caso de uso. La única forma de salir del flujo de pasos es cuando se considera que un suscriptor funciona, momento en el que se puede borrar la instantánea.
El uso de la función de instantáneas y búsqueda no reemplaza las prácticas recomendadas en torno a la primera ejecución del 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 el procesamiento confiable de los datos. La desventaja es que buscar la instantánea puede generar 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 a la reentrega de mensajes.