Este documento es útil si estás pensando en migrar de Apache Kafka autogestionado a Pub/Sub, ya que te ayudará a revisar y tener en cuenta las funciones, los precios y los casos prácticos. En cada sección se identifica un caso práctico habitual de Kafka y se ofrecen directrices prácticas para conseguir las mismas funciones en Pub/Sub.
Descripción general de Pub/Sub
Pub/Sub es un servicio de mensajería asíncrono. Pub/Sub desacopla los servicios que producen eventos de los servicios que los procesan. Puede usar Pub/Sub como middleware orientado a la mensajería, o para la ingestión y la entrega de eventos en flujos de procesamiento de analíticas en tiempo real. En ambos casos, una aplicación de publicación crea y envía mensajes a un tema. Las aplicaciones de suscriptor crean una suscripción a un tema para recibir mensajes de él. Una suscripción es una entidad con nombre que representa el interés en recibir mensajes sobre un tema concreto.
Pub/Sub se ejecuta en todas las Google Cloud regiones. Pub/Sub dirige el tráfico de los editores al centro de datos más cercano Google Cloud donde se permite el almacenamiento de datos, tal como se define en la política de restricción de ubicación de recursos.
Pub/Sub se puede integrar con muchos Google Cloud servicios, como Dataflow, Cloud Storage y Cloud Run. Puede configurar estos servicios para que actúen como fuentes de datos que puedan publicar mensajes en Pub/Sub o como receptores de datos que puedan recibir mensajes de Pub/Sub.
Información general sobre Kafka
Apache Kafka es una plataforma de streaming de eventos distribuida y de código abierto que permite a las aplicaciones publicar, suscribirse, almacenar y procesar flujos de eventos. El servidor de Kafka se ejecuta como un clúster de máquinas con el que interactúan las aplicaciones cliente para leer, escribir y procesar eventos. Puedes usar Kafka para desacoplar aplicaciones, enviar y recibir mensajes, monitorizar actividades, agregar datos de registro y procesar flujos.
En el clúster de Kafka, algunos nodos se designan como brokers. Los brokers reciben mensajes de los productores y los almacenan en el disco. Los mensajes almacenados se organizan por temas y se particionan en varios brokers diferentes del clúster. Los eventos nuevos que se publican en un tema se añaden al final de una de las particiones del tema. Los consumidores pueden obtener mensajes de los brokers, que se leen del disco y se envían al consumidor.
Diferencias entre Kafka y Pub/Sub
En el siguiente diagrama se muestran las diferencias en la estrategia de escalado entre Kafka y Pub/Sub:
En el diagrama anterior, cada M representa un mensaje. Los brokers de Kafka gestionan varias particiones ordenadas de mensajes, representadas por las filas horizontales de mensajes. Los consumidores leen mensajes de una partición concreta que tiene una capacidad basada en la máquina que aloja esa partición. Pub/Sub no tiene particiones y, en su lugar, los consumidores leen de un tema que se ajusta automáticamente según la demanda. Configura cada tema de Kafka con el número de particiones que necesites para gestionar la carga de consumidores prevista. Pub/Sub se escala automáticamente según la demanda.
Comparación de funciones
En la siguiente tabla se comparan las funciones de Apache Kafka con las de Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Ordenación de mensajes | Sí, en las particiones | Sí en temas |
| Deduplicación de mensajes | Sí | Sí, con Dataflow |
| Suscripciones push | No | Sí |
| Cola de mensajes no entregados (cola de mensajes no procesables) |
A partir de la versión 2.0 | Sí |
| Transacciones | Sí | No |
| Espacio de almacenamiento de mensajes | Solo limitado por el almacenamiento disponible en el dispositivo | 31 días: un tema puede conservar los mensajes publicados, incluidos los confirmados, durante un máximo de 31 días. Se puede configurar mediante la propiedad `message_retention_duration` del tema. |
| Volver a reproducir mensajes | Sí | Sí |
| Localidad | El clúster local se puede replicar mediante MirrorMaker | Servicio distribuido globalmente con ubicaciones de almacenamiento de mensajes configurables |
| Almacenamiento de registros y monitorización | Autogestionado | Automatizado con Cloud Logging y Cloud Monitoring |
| Procesamiento de streaming | Sí, con KSQL | Sí, con Dataflow |
Información sobre el almacenamiento y la reproducción de mensajes de Pub/Sub
De forma predeterminada, Pub/Sub retiene los mensajes sin confirmar durante un máximo de 7 días, pero puedes configurar las suscripciones de Pub/Sub para que retengan los mensajes confirmados durante un máximo de 7 días también, en función de la antigüedad del mensaje más antiguo (confirmado o sin confirmar) de la suscripción. Si conservas los mensajes confirmados, puedes volver a reproducir algunos o todos esos mensajes en función de una marca de tiempo. Cuando reproduces mensajes según una marca de tiempo, todos los mensajes que se hayan recibido después de la marca de tiempo se marcan como no confirmados. A continuación, se vuelven a enviar los mensajes sin confirmar.
Puedes crear capturas de suscripciones individuales bajo demanda sin necesidad de configurar tu suscripción con antelación. Por ejemplo, puedes crear una captura al implementar un nuevo código de suscriptor, ya que es posible que tengas que recuperarte de confirmaciones inesperadas o erróneas.
Mecanismo de seguridad integrado con temas de mensajes fallidos
Pub/Sub ofrece funciones similares a la gestión de errores de Kafka 2.0 y a la forma en que Kafka Connect gestiona los temas de mensajes fallidos. Para notificar a Pub/Sub que un mensaje se ha entregado correctamente, los suscriptores de los temas de Pub/Sub pueden confirmar los mensajes que reciben y procesan. Si tus suscriptores no pueden procesar mensajes durante un tiempo, Pub/Sub puede reenviar automáticamente estos mensajes a un tema de mensajes fallidos y almacenarlos para acceder a ellos más adelante. Puedes configurar el número de intentos que Pub/Sub hace para entregar los mensajes antes de enviar el mensaje al tema de mensajes fallidos.
Eliminar duplicados de mensajes en Pub/Sub con Dataflow
Pub/Sub entrega cada mensaje publicado al menos una vez por cada suscripción. Por lo general, para admitir la entrega más de una vez, el suscriptor debe ser idempotente al procesar los mensajes. Si tus suscriptores no pueden operar de forma idempotente, puedes incorporar Dataflow para eliminar los mensajes duplicados. Si tus suscriptores ven una tasa alta de mensajes duplicados, puede indicar que no están confirmando los mensajes correctamente o que el plazo de confirmación es demasiado corto.
Orden de los mensajes en Pub/Sub
Si tus aplicaciones de suscriptor de Kafka dependen del orden de los mensajes, puedes cumplir este requisito en Pub/Sub cuando uses claves de ordenación. Actualmente, el orden de los mensajes publicados en una región determinada está garantizado. Para aprovechar las ventajas del orden de los mensajes, asegúrese de que sus editores y suscriptores usen endpoints de ubicación para enrutar sus mensajes a la región correcta.
Diferencias entre las responsabilidades de los servicios autogestionados y los gestionados
En la siguiente tabla se compara qué función se autohospeda con Kafka y qué función gestiona Google mediante Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Disponibilidad | Implementar Kafka manualmente en ubicaciones adicionales | Desplegado en todas las regiones de Google Cloud para ofrecer alta disponibilidad y baja latencia |
| Recuperación tras fallos | Diseñar y mantener tu propia copia de seguridad y replicación | Gestionado por Google |
| Gestión de infraestructuras | Despliega y opera manualmente máquinas virtuales (VMs) o máquinas. Debes mantener versiones y parches coherentes. | Gestionado por Google |
| Planificación de la capacidad | Planificar manualmente las necesidades de almacenamiento y computación con antelación | Gestionado por Google |
| Asistencia | Ninguno | Personal de asistencia y apoyo disponible las 24 horas |
Límites de tamaño de los mensajes de Pub/Sub y soluciones alternativas
Tanto Kafka como Pub/Sub funcionan bien cuando gestionan grandes volúmenes de mensajes pequeños. Kafka no impone un límite estricto al tamaño de los mensajes y te permite configurar el tamaño de mensaje permitido, mientras que Pub/Sub limita los mensajes a 10 MB. Puedes enviar cargas útiles más grandes de forma indirecta almacenando primero el objeto en Cloud Storage, como se muestra en el siguiente diagrama:
En la imagen anterior se muestra que, cuando el editor almacena el objeto en Cloud Storage, publica un mensaje que contiene la URL de ese objeto almacenado. Cuando el suscriptor recibe el mensaje que contiene la URL, descarga el archivo de Cloud Storage y continúa procesándolo como de costumbre.
Comparación de costes de Kafka y Pub/Sub
La forma de estimar y gestionar los costes en Pub/Sub es diferente a la de Kafka. Los costes de un clúster de Kafka local o en la nube incluyen el coste de las máquinas, los discos, las redes, los mensajes entrantes y salientes, así como los costes indirectos de gestionar y mantener estos sistemas y su infraestructura relacionada. Al gestionar un clúster de Kafka, a menudo es necesario actualizar y parchear las máquinas manualmente, planificar la capacidad del clúster y llevar a cabo una planificación y pruebas exhaustivas para implementar la recuperación tras fallos. Debes inferir y agregar todos estos costes para determinar el coste total de propiedad (TCO) real.
Los precios de Pub/Sub incluyen la transferencia de datos de los editores a los suscriptores y el coste de almacenar temporalmente los mensajes no confirmados. Pagas exactamente por los recursos que consumes, y su capacidad se escala automáticamente según los requisitos de tu aplicación y tu presupuesto.
Diseñar arquitecturas para la fiabilidad
Pub/Sub es un servicio gestionado global que se ejecuta en todas las Google Cloud regiones. Los temas de Pub/Sub son globales, lo que significa que se pueden ver y acceder desde cualquier Google Cloud ubicación. Sin embargo, cada mensaje se almacena en una sola región, la más cercana al editor, y se permite en la política de ubicaciones de recursos. Google Cloud Por lo tanto, un tema puede tener mensajes almacenados en diferentes regiones de Google Cloud. Pub/Sub es resistente a las interrupciones zonales. Durante una interrupción regional, es posible que no se pueda acceder a los mensajes almacenados en esa región hasta que se restaure el servicio. En función de tus requisitos de disponibilidad, puedes usar endpoints de servicio de ubicación para implementar una política de conmutación por error si se produce una interrupción regional.
Seguridad y autenticación
Apache Kafka admite varios mecanismos de autenticación, como la autenticación basada en certificados de cliente, Kerberos, LDAP y nombre de usuario y contraseña. Para la autorización, Kafka admite el uso de listas de control de acceso (LCAs) para determinar qué productores y consumidores tienen acceso a qué temas.
Pub/Sub admite la autenticación de cuentas de usuario y cuentas de servicio. Google Cloud El control de acceso granular a temas y suscripciones de Pub/Sub se rige por Gestión de Identidades y Accesos (IAM) en Google Cloud. Las operaciones de Pub/Sub tienen un límite de frecuencia cuando se usan cuentas de usuario. Si necesitas hacer transacciones de gran volumen, puedes usar cuentas de servicio para interactuar con Pub/Sub.
Planificar la migración a Pub/Sub
Cualquier migración a Google Cloud empieza con la evaluación de tus cargas de trabajo y la creación de tu base.
Migración gradual con el conector de Pub/Sub Kafka
El conector de Kafka para Pub/Sub te permite migrar tu infraestructura de Kafka a Pub/Sub por fases.
Puedes configurar el conector Pub/Sub para que reenvíe todos los mensajes de temas específicos de Kafka a Pub/Sub. Después, puedes actualizar las aplicaciones de suscriptor individuales para que reciban mensajes sobre esos temas de Pub/Sub, mientras que tus aplicaciones de editor siguen publicando mensajes en Kafka. Este enfoque por fases te permite actualizar, probar y monitorizar las aplicaciones de suscriptores de forma iterativa, lo que minimiza el riesgo de errores y tiempos de inactividad.
En esta sección se incluyen dos diagramas que pueden ayudarte a visualizar este proceso en dos fases distintas. En el siguiente diagrama se muestra la configuración durante la fase de migración:
En el diagrama anterior, los suscriptores actuales siguen recibiendo mensajes de Kafka y actualizas los suscriptores uno a uno para que reciban mensajes de Pub/Sub.
Una vez que se hayan actualizado todos los suscriptores de un tema concreto para recibir mensajes de Pub/Sub, puedes actualizar las aplicaciones de editor de ese tema para que publiquen mensajes en Pub/Sub. Después, puedes probar y monitorizar los flujos de mensajes de extremo a extremo para verificar la configuración.
En el siguiente diagrama se muestra la configuración después de que todos los suscriptores reciban mensajes de Pub/Sub:
Con el tiempo, todos tus editores se actualizarán para publicar directamente en Pub/Sub y, entonces, la migración se completará. Muchos equipos utilizan este enfoque para actualizar sus aplicaciones en paralelo. Kafka puede coexistir con Pub/Sub durante el tiempo que sea necesario para asegurar que la migración se realice correctamente.
Monitorizar Pub/Sub
Durante y después de la migración de Kafka a Pub/Sub, es importante que monitorices tus aplicaciones. Pub/Sub exporta métricas mediante Cloud Monitoring, que puede ayudarte a ver el rendimiento, el tiempo de actividad y el estado general de tus aplicaciones. Por ejemplo, puedes asegurarte de que tus suscriptores están al día de los mensajes monitorizando el número de mensajes no entregados. Para monitorizar los mensajes no entregados, crea alertas cuando la marca de tiempo del mensaje no confirmado más antiguo supere un determinado umbral. También puedes monitorizar el estado del propio servicio Pub/Sub monitorizando la métrica de recuento de solicitudes de envío y examinando los códigos de respuesta.
Siguientes pasos
- Analíticas de streaming con Pub/Sub.
- Referencia de la API Pub/Sub
- Documentación de monitorización de Pub/Sub
- Diseñar una arquitectura de recuperación tras fallos para las interrupciones de la infraestructura en la nube.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.