Migración de Kafka a Pub/Sub

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 la misma funcionalidad 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 estadísticas de transmisión. 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 GoogleCloud 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 código abierto, y permite que las aplicaciones publiquen, almacenen y procesen transmisiones de eventos. El servidor Kafka se ejecuta como un clúster de máquinas con las que las aplicaciones cliente interactúan para leer, escribir y procesar 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:

Estrategia de escalamiento con particiones para Kafka y sin particiones para 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 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 realiza el ajuste de escala automático 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 a pedido.

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í, mediante Dataflow
Suscripciones de inserción No
Cola de mensajes no procesados A partir de la versión 2.0
Transacciones No
Almacenamiento de mensajes Limitado solo por el almacenamiento de máquinas disponible 7 días
Reproducción de mensajes
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. . 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 la marca de tiempo 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 procesados

Pub/Sub proporciona una funcionalidad similar a la de administración de errores de Kafka 2.0 y cómo Kafka Connect maneja los temas de mensajes no procesados. 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 tus suscriptores no pueden procesar mensajes por un tiempo, Pub/Sub puede reenviar automáticamente estos mensajes a un tema de mensajes no procesados y almacenarlos para acceder a ellos más tarde. Puedes configurar la cantidad de intentos que Pub/Sub realiza para entregar los mensajes antes de enviar el mensaje al tema de mensaje no procesado.

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 regionales a fin de 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 funcionalidad que se aloja a sí misma con Kafka y qué funcionalidad 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:

El publicador almacena el objeto en Cloud Storage.

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, la entrada y salida de datos, 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 regional para implementar una política de conmutación por error si se produce una interrupción regional.

Seguridad y autenticación

Apache Kafka es compatible con varios mecanismos de autenticación que incluyen 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 las suscripciones y los temas 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:

Etapa uno de la 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:

Etapa dos de migración

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 la migración de Kafka a Pub/Sub, es importante supervisar las aplicaciones. Pub/Sub exporta métricas mediante Cloud Monitoring, que puede ayudar a proporcionar visibilidad del rendimiento, el tiempo de actividad y el estado general de las aplicaciones. Por ejemplo, puedes asegurarte de que tus suscriptores se mantengan al día con el flujo de mensajes si supervisas la cantidad de mensajes no entregados. 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?