Este documento es útil si consideras migrar de Apache Kafka autoadministrado a Pub/Sub, ya que te puede ayudar a revisar y considerar las funciones, los precios y los casos de uso. En cada sección, se identifica un caso de uso común de Kafka y se ofrece una orientación práctica para lograr las mismas capacidades en Pub/Sub.
Descripción general de Pub/Sub
Pub/Sub es un servicio de mensajería asíncrona. Pub/Sub separa los servicios que producen eventos de los servicios que procesan eventos. Puedes usar Pub/Sub como middleware orientado a la mensajería o transferencia y entrega de eventos para las canalizaciones de análisis de transmisiones. En ambos casos, una aplicación del publicador crea y envía mensajes a un tema. Las aplicaciones de suscriptor crean una suscripción a un tema para recibir mensajes de este. Una suscripción es una entidad con nombre que representa un interés en recibir mensajes sobre un tema en particular.
Pub/Sub se ejecuta en todas las regiones de Google Cloud. Pub/Sub dirige el tráfico del publicador al centro de datos de Google Cloud más cercano en el que se permita el almacenamiento de datos, como se define en la política de restricción de ubicación de recursos.
Pub/Sub puede integrarse en muchos servicios de Google Cloud, como Dataflow, Cloud Storage y Cloud Run. Puedes configurar estos servicios para que funcionen como fuentes de datos que pueden publicar mensajes en Pub/Sub o como receptores de datos que pueden recibir mensajes de Pub/Sub.
Descripción general de Kafka
Apache Kafka es una plataforma de transmisión de eventos distribuida y de código abierto, y permite que las aplicaciones publiquen, suscriban, almacenen y procesen transmisiones de eventos. El servidor de Kafka se ejecuta como un clúster de máquinas con las que las aplicaciones cliente interactúan con la lectura, la escritura y el procesamiento de eventos. Puedes usar Kafka para separar aplicaciones, enviar y recibir mensajes, hacer un seguimiento de las actividades, agregar datos de registro y procesar transmisiones.
Dentro del clúster de Kafka, algunos nodos en el clúster se designan como agentes. Los agentes reciben mensajes de los productores y los almacenan en el disco. Los mensajes almacenados se organizan por tema y se particionan en varios agentes diferentes en el clúster. Los nuevos eventos publicados en un tema se agregan al final de una de las particiones del tema. Luego, los consumidores pueden recuperar mensajes de agentes, que se leen desde el disco y se envían al consumidor.
Información sobre las diferencias entre Kafka y Pub/Sub
En el siguiente diagrama, se muestran las diferencias en la estrategia de escalamiento entre Kafka y Pub/Sub:
En el diagrama anterior, cada M representa un mensaje. Los agentes de Kafka administran varias particiones ordenadas de mensajes, representadas por las filas horizontales de los mensajes. Los consumidores leen mensajes de una partición particular que tiene una capacidad basada en la máquina que aloja esa partición. Pub/Sub no tiene particiones y los consumidores leen desde un tema que se escala automáticamente según la demanda. Configura cada tema de Kafka con la cantidad de particiones que necesitas para manejar la carga del consumidor esperada. Pub/Sub escala automáticamente según la demanda.
Compara las características
En la siguiente tabla, se comparan las características de Apache Kafka con las de Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Ordenamiento de mensajes | Sí, en particiones | Sí, en temas |
| Anulación de duplicación de mensajes | Sí | Sí, mediante Dataflow |
| Suscripciones de inserción | No | Sí |
| Cola de mensajes no entregados (cola de mensajes no procesables) |
A partir de la versión 2.0 | Sí |
| Transacciones | Sí | No |
| Almacenamiento de mensajes | Limitado solo por el almacenamiento de máquinas disponible | 31 días: Un tema puede retener los mensajes publicados, incluidos los confirmados, por un máximo de 31 días. Esto se puede configurar con la propiedad `message_retention_duration` del tema. |
| Repetición de mensajes | Sí | Sí |
| Localidad | El clúster local puede replicar mediante MirrorMaker. | Servicio distribuido global con ubicaciones de almacenamiento de mensajes configurables |
| Registro y supervisión | Administración automática | Automatizado con Cloud Logging y Cloud Monitoring |
| Procesamiento de transmisión | 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 no confirmados por hasta 7 días, pero puedes configurar las suscripciones a Pub/Sub para retener los mensajes confirmados por hasta 7 días, según la antigüedad del mensaje más antiguo (confirmado o no confirmado) en la suscripción. Si retienes los mensajes confirmados, puedes volver a reproducir algunos o todos esos mensajes en función de una marca de tiempo. Cuando vuelves a reproducir mensajes basados en una marca de tiempo, todos los mensajes que se recibieron después de esta se marcan como no confirmados. Los mensajes no confirmados se vuelven a entregar.
Puedes crear instantáneas de suscripciones individuales a pedido sin la necesidad de configurar la suscripción con anticipación. Por ejemplo, puedes crear una instantánea cuando implementes un código nuevo de suscriptor, ya que es posible que debas recuperarte de confirmaciones inesperadas o erróneas.
Seguridad contra fallas integrada con temas de mensajes no entregados
Pub/Sub proporciona funciones similares a las del manejo de errores de Kafka 2.0 y cómo Kafka Connect maneja los temas de mensajes no entregados. Para notificar a Pub/Sub que un mensaje se entregó con éxito, los suscriptores a los temas de Pub/Sub pueden confirmar mensajes que reciben y procesan. Si los suscriptores no pueden procesar mensajes durante un tiempo, Pub/Sub puede reenviar automáticamente estos mensajes a un tema de mensajes no entregados y almacenarlos para acceder a ellos más adelante. Puedes configurar la cantidad de intentos que Pub/Sub realiza para entregar los mensajes antes de enviar el mensaje al tema de mensajes no entregados.
Anula duplicados de mensajes en Pub/Sub mediante Dataflow
Pub/Sub entrega cada mensaje publicado al menos una vez por cada suscripción. En general, para realizar entregas más de una vez, es necesario que el suscriptor sea idempotente cuando procesa los mensajes. Si tus suscriptores existentes no pueden operar de forma idempotente, puedes incorporar Dataflow para anular mensajes duplicados. Si tus suscriptores ven una tasa alta de mensajes duplicados, esto puede indicar que no reconocen correctamente los mensajes o que el plazo de confirmación es demasiado corto.
Orden de mensajes en Pub/Sub
Si tus aplicaciones de suscriptor de Kafka dependen del orden de los mensajes, puedes admitir este requisito en Pub/Sub cuando usas claves de ordenamiento. Por el momento, el orden está garantizado para los mensajes publicados en una región determinada. Para aprovechar el orden de los mensajes, asegúrate de que tus publicadores y suscriptores usen extremos de ubicación para enrutar los mensajes a la región correcta.
Información sobre las responsabilidades de los servicios autoalojados y administrados
En la siguiente tabla, se compara la función que se aloja a sí misma con Kafka y qué función administra Google mediante Pub/Sub:
| Apache Kafka | Pub/Sub | |
|---|---|---|
| Disponibilidad | Implementa Kafka manualmente en ubicaciones adicionales | Implementado en todas las regiones de Google Cloud para alta disponibilidad y baja latencia |
| Recuperación ante desastres | Diseña y mantén tu propia copia de seguridad y replicación | Administradas por Google |
| Administración de la infraestructura | Implementa y opera máquinas virtuales (VM) o máquinas de forma manual Debes mantener el control de versiones y los parches coherentes. | Administradas por Google |
| Planificación de la capacidad | Planifica de forma manual las necesidades de almacenamiento y procesamiento por adelantado | Administradas por Google |
| Asistencia | Ninguna | Asistencia y personal de guardia disponibles las 24 horas |
Límites de tamaño de mensajes de Pub/Sub y soluciones alternativas
Kafka y Pub/Sub ofrecen un buen rendimiento cuando se manejan grandes volúmenes de mensajes pequeños. Kafka no establece un límite estricto en el tamaño del mensaje y te permite configurar el tamaño del mensaje permitido, mientras que Pub/Sub limita los mensajes a 10 MB. Puedes enviar, de forma indirecta, cargas útiles más grandes si primero almacenas el objeto en Cloud Storage, como se muestra en el siguiente diagrama:
En la imagen anterior, se muestra que, cuando el publicador almacena el objeto en Cloud Storage, publica un mensaje que contiene la URL en ese objeto almacenado. Cuando el suscriptor recibe el mensaje que contiene la URL, descarga el archivo de Cloud Storage y continúa el procesamiento como de costumbre.
Comparación de costos de Kafka y Pub/Sub
La forma en que estimas y administras los costos en Pub/Sub es diferente que en Kafka. Los costos de un clúster Kafka local o en la nube incluyen el costo de las máquinas, el disco, las herramientas de redes, los mensajes entrantes y salientes, y los costos generales de administrar y mantener estos sistemas y la infraestructura relacionada. Cuando se administra un clúster de Kafka, a menudo las máquinas se deben actualizar y aplicar parches de forma manual, la capacidad del clúster a menudo debe planificarse, y la implementación de la recuperación ante desastres implica una planificación y pruebas extensas. Debes inferir y agregar todos estos costos para determinar el costo total de propiedad (TCO) real.
Los precios de Pub/Sub incluyen la transferencia de datos de los publicadores, los suscriptores, y el costo de almacenamiento temporal de mensajes no confirmados. Pagas por los recursos que consumas y escalas automáticamente su capacidad según los requisitos de tu aplicación y presupuesto.
Arquitectura para confiabilidad
Pub/Sub es un servicio administrado global que se ejecuta en todas las regiones de Google Cloud. Los temas de Pub/Sub son globales, lo que significa que son visibles y accesibles desde cualquier ubicación de Google Cloud. Sin embargo, todos los mensajes se almacenan en una sola región de Google Cloud, la más cercana al publicador y la que permita la política de ubicación de recursos. Por lo tanto, un tema puede tener mensajes almacenados en diferentes regiones en Google Cloud. Pub/Sub es resistente a las interrupciones por zona. Durante una interrupción regional, los mensajes almacenados en esa región en particular pueden ser inaccesibles hasta que se restablezca el servicio. Según tus requisitos de disponibilidad, puedes usar extremos 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, nombre de usuario y contraseña. Para la autorización, Kafka admite usar las listas de control de acceso (LCA) a fin de determinar qué productores y consumidores tienen acceso a qué temas.
Pub/Sub admite la autenticación para las cuentas de servicio y las cuentas de usuario de Google Cloud. El control de acceso detallado a los temas y suscripciones de Pub/Sub se rige por la administración de identidades y accesos (IAM) en Google Cloud. Las operaciones de Pub/Sub tienen una tasa limitada cuando se usan cuentas de usuario. Si necesitas realizar transacciones de gran volumen, puedes usar cuentas de servicio para interactuar con Pub/Sub.
Planifica la migración a Pub/Sub
Cualquier migración a Google Cloud comienza con la evaluación de las cargas de trabajo y la compilación de la base.
Migración por fases con el conector de Pub/Sub Kafka
El conector de Pub/Sub Kafka te permite migrar la infraestructura de Kafka a Pub/Sub en etapas.
Puedes configurar el conector de Pub/Sub para reenviar todos los mensajes sobre temas específicos de Kafka a Pub/Sub. Luego, puedes actualizar las aplicaciones de suscriptor individuales para recibir mensajes sobre esos temas desde Pub/Sub, mientras que las aplicaciones de publicador continúan publicando mensajes en Kafka. Este enfoque por fases te permite actualizar, probar y supervisar las aplicaciones de suscriptor de forma iterativa que minimiza el riesgo de errores y el tiempo 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 continúan recibiendo mensajes de Kafka, y los actualizas uno por uno para recibir mensajes de Pub/Sub en su lugar.
Después de actualizar todos los suscriptores de un tema en particular para recibir mensajes de Pub/Sub, puedes actualizar las aplicaciones del publicador de ese tema a fin de publicar mensajes en Pub/Sub. Luego, puedes probar y supervisar 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 reciben mensajes de Pub/Sub:
Con el tiempo, todos tus publicadores se actualizan para publicar directamente en Pub/Sub y, luego, se completa la migración. Muchos equipos usan este enfoque para actualizar sus aplicaciones en paralelo. Kafka puede coexistir junto con Pub/Sub durante el tiempo que sea necesario para garantizar una migración exitosa.
Supervisa Pub/Sub
Durante y después de tu migración de Kafka a Pub/Sub, es importante supervisar tus aplicaciones. Pub/Sub exporta métricas mediante Cloud Monitoring, que puede ayudar a proporcionar visibilidad en el rendimiento, el tiempo de actividad y el estado general de las aplicaciones. Por ejemplo, puedes supervisar la cantidad de mensajes no entregados para asegurarte de que los suscriptores están al tanto del flujo de mensajes. Para supervisar los mensajes no entregados, crea alertas cuando la marca de tiempo del mensaje no confirmado más antiguo se extienda más allá de cierto límite. También puedes supervisar el estado del servicio de Pub/Sub. Para ello, supervisa la métrica de recuento de solicitudes de envío y examina los códigos de respuesta.
¿Qué sigue?
- Análisis de transmisiones con Pub/Sub.
- Referencia de la API de Pub/Sub.
- Documentación de Monitoring para Pub/Sub.
- Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.