Hoy en día, muchas empresas están creando aplicaciones en tiempo real para mejorar la experiencia de sus clientes y obtener información inmediata de sus datos antes de que pierdan su valor. Como resultado, las empresas se han enfrentado a una creciente demanda de servicios de transmisión de datos como Apache Kafka para desarrolladores. Para satisfacer esta demanda, las empresas suelen comenzar con un clúster Apache Kafka centralizado de tamaño pequeño o mediano para crear un servicio de transmisión global. Con el tiempo, escalan la capacidad del clúster para que coincida con la demanda de transmisión. Eligen mantener un grupo monolítico para simplificar la dotación de personal y la capacitación al reunir toda la experiencia técnica en un solo lugar. Este enfoque también tiene beneficios de costos porque reduce la deuda técnica, los costos operativos generales y la complejidad. En un clúster monolítico, la capacidad adicional se comparte entre todas las aplicaciones, por lo que generalmente reduce el costo general de la infraestructura de transmisión.

En esta publicación, explico algunos desafíos con un enfoque centralizado y presento dos estrategias para implementar un enfoque descentralizado, utilizando Amazon MSK sin servidor. Una estrategia descentralizada le permite aprovisionar varios clústeres de Apache Kafka en lugar de uno monolítico. Analizo cómo esta estrategia lo ayuda a optimizar los clústeres según las necesidades de seguridad, almacenamiento y rendimiento de su aplicación. También analizo los beneficios de un modelo descentralizado y cómo migrar de un clúster monolítico a un modelo de implementación de múltiples clústeres.

MSK Serverless puede reducir la sobrecarga y el costo de administrar clústeres de Apache Kafka. Aprovisiona y escala automáticamente los recursos informáticos y de almacenamiento para los clústeres de Apache Kafka y administra automáticamente la capacidad del clúster. Supervisa cómo se distribuyen las particiones en los nodos backend y reasigna las particiones automáticamente cuando es necesario. Se integra con otros servicios de AWS como Reloj en la nube de Amazon, donde puede supervisar el estado del clúster. La elección de MSK Serverless en esta publicación es deliberada, aunque los conceptos también se pueden aplicar a la oferta aprovisionada de Amazon MSK.

Resumen de la solución

Apache Kafka es una plataforma de código abierto, de alto rendimiento, tolerante a fallas y escalable para crear canalizaciones y aplicaciones de transmisión de datos en tiempo real. Apache Kafka simplifica la producción y el consumo de datos de transmisión al desvincular a los productores de los consumidores. Los productores simplemente interactúan con un único almacén de datos (Apache Kafka) para enviar sus datos. Los consumidores leen los datos que fluyen continuamente, independientemente de la arquitectura o el lenguaje de programación de los productores.

Apache Kafka es una opción popular para muchos casos de uso, como:

• Análisis web y de registros en tiempo real
• Abastecimiento de transacciones y eventos
• Mensajes
• Desacoplamiento de microservicios
• Streaming ETL (extraer, transformar y cargar)
• Métricas y agregación de registros

Desafíos con un clúster monolítico de Apache Kafka

Apache Kafka monolítico evita que las empresas tengan que instalar y mantener varios clústeres en sus centros de datos. Sin embargo, este enfoque tiene desventajas comunes:

• Toda la capacidad de transmisión se consolida en un solo lugar, lo que dificulta y complica la planificación de la capacidad. Por lo general, necesita más tiempo para planificar y reconfigurar el clúster. Por ejemplo, cuando se prepara para ventas o grandes eventos de campaña, es difícil predecir y calcular una agregación de la capacidad necesaria en todas las aplicaciones. Esto también puede inhibir el crecimiento de su empresa porque la reconfiguración de un clúster grande para una nueva carga de trabajo suele llevar más tiempo que la de un clúster pequeño.
• Pueden producirse conflictos organizativos con respecto a la propiedad y el mantenimiento del clúster de Apache Kafka, ya que un clúster monolítico es un recurso compartido.
• El clúster de Apache Kafka se convierte en un único punto de error. Cualquier tiempo de inactividad significa la interrupción de todas las aplicaciones relacionadas.
• Si decide aumente la resiliencia de Apache Kafka con una implementación de varios centros de datos, normalmente debe tener un clúster del mismo tamaño (tan grande) en el otro centro de datos, lo cual es costoso.
• Actividades de mantenimiento y operación, tales como actualizaciones de versión o instalar parches del sistema operativo, toma mucho más tiempo para clústeres más grandes debido a la naturaleza distribuida de la arquitectura Apache Kafka.
• Una aplicación defectuosa puede afectar la confiabilidad de todo el clúster y otras aplicaciones.
• Las actualizaciones de versión tienen que esperar hasta que todas las aplicaciones se prueben con la nueva versión de Apache Kafka. Esto impide que cualquier aplicación experimente rápidamente con las características de Apache Kafka.
• Este modelo hace que sea difícil atribuir el costo de ejecutar el clúster a las aplicaciones con fines de contracargo.

El siguiente diagrama muestra una arquitectura Apache Kafka monolítica.

modelo descentralizado

Un modelo de implementación descentralizado de Apache Kafka implica el aprovisionamiento, la configuración y el mantenimiento de varios clústeres. Por lo general, esta estrategia no es la preferida porque la administración de múltiples clústeres requiere grandes inversiones en excelencia operativa, monitoreo avanzado, infraestructura como código, seguridad y adquisición de hardware en entornos locales.

Sin embargo, el aprovisionamiento de clústeres Apache Kafka descentralizados mediante MSK Serverless no requiere esas inversiones. Puede escalar la capacidad y el almacenamiento hacia arriba y hacia abajo instantáneamente según los requisitos de la aplicación, agregando nuevas cargas de trabajo o escalando operaciones sin la necesidad de una planificación de capacidad compleja. También proporciona un modelo de precios basado en el rendimiento, y usted paga por el almacenamiento y el rendimiento que utilizan sus aplicaciones. Además, con MSK Serverless, ya no necesita realizar tareas de mantenimiento estándar, como la actualización de la versión de Apache Kafka, la reasignación de particiones o la aplicación de parches al sistema operativo.

Con MSK Serverless, se beneficia de una implementación descentralizada sin la carga operativa que normalmente conlleva una implementación autogestionada de Apache Kafka. En esta estrategia, los administradores de DevOps no tienen que dedicar tiempo al aprovisionamiento, configuración, monitoreo y operación de múltiples clústeres. En cambio, invierten más en crear más herramientas operativas para incorporar más aplicaciones en tiempo real.

En el resto de esta publicación, analizo diferentes estrategias para implementar un modelo descentralizado. Además, destaco los beneficios y desafíos de cada estrategia para que puedas decidir qué funciona mejor para tu organización.

Escribir clústeres y leer clústeres

En esta estrategia, los clústeres de escritura son responsables de ingerir datos de los productores. Puede agregar nuevas cargas de trabajo creando nuevos temas o creando nuevos clústeres sin servidor de MSK. Si necesita escalar el tamaño de las cargas de trabajo actuales, simplemente aumente la cantidad de particiones de sus temas si el orden no es importante. MSK Serverless gestiona la capacidad al instante según la nueva configuración.

Cada clúster sin servidor de MSK proporciona hasta 200 MBps de rendimiento de escritura y 400 MBps de rendimiento de lectura. También asigna hasta 5 MBps de rendimiento de escritura y 10 MBps de rendimiento de lectura por partición.

Los consumidores de datos dentro de cualquier organización generalmente se pueden dividir en dos categorías principales:

• Cargas de trabajo sensibles al tiempo, que necesitan datos con latencia muy baja (como milisegundos o subsegundos) y solo pueden tolerar un objetivo de tiempo de recuperación (RTO) muy corto
• Cargas de trabajo insensibles al tiempo, que pueden tolerar una latencia más alta (latencia inferior a 10 segundos a nivel de minutos) y un RTO más largo

Cada una de estas categorías también se puede dividir en subcategorías según ciertas condiciones, como la clasificación de datos, el cumplimiento normativo o los acuerdos de nivel de servicio (SLA). Los clústeres de lectura se pueden configurar de acuerdo con los requisitos técnicos o de su negocio, o incluso con los límites de la organización, que pueden ser utilizados por el grupo específico de consumidores. Finalmente, los consumidores están configurados para ejecutarse en el clúster de lectura asociado.

Para conectar los clústeres de escritura a los clústeres de lectura, se necesita una canalización de replicación de datos. Puede crear una canalización de replicación de datos de muchas maneras. Debido a que MSK Serverless es compatible con las API estándar de Apache Kafka, puede usar las herramientas estándar de Apache Kafka, como fabricante de espejos 2 a configurar replicaciones entre clústeres de Apache Kafka.

El siguiente diagrama muestra la arquitectura de esta estrategia.

Este enfoque tiene los siguientes beneficios:

• Los productores están aislados de los consumidores; por lo tanto, su rendimiento de escritura puede escalar independientemente de su rendimiento de lectura. Por ejemplo, si alcanzó su rendimiento de lectura máximo con los clústeres existentes y necesita agregar un nuevo grupo de consumidores, simplemente puede aprovisionar un nuevo clúster sin servidor de MSK y configurar la replicación entre el clúster de escritura y el nuevo clúster de lectura.
• Ayuda a reforzar la seguridad y el cumplimiento normativo. Puede crear trabajos de transmisión que pueden enmascarar o eliminar los campos confidenciales de los eventos de datos, como la información de identificación personal (PII), mientras se replican los datos.
• Los diferentes clústeres se pueden configurar de manera diferente en términos de retención. Por ejemplo, los clústeres de lectura se pueden configurar con diferentes períodos máximos de retención para ahorrar costos de almacenamiento según sus requisitos.
• Puede priorizar su tiempo de respuesta para interrupciones para ciertos clústeres sobre los demás.
• Para implementar una mayor resiliencia, puede tener menos clústeres en la región de copia de seguridad replicando solo los datos de los clústeres de escritura. Se pueden aprovisionar otros clústeres, como los clústeres de lectura, cuando se invoca la conmutación por error de la carga de trabajo. En este modelo, con el modelo de precios sin servidor de MSK, paga adicionalmente por lo que usa (réplica más ligera) en la región de respaldo.

Hay algunas notas importantes a tener en cuenta al elegir esta estrategia:

• Requiere configurar múltiples replicaciones entre clústeres, lo que conlleva una complejidad operativa y de mantenimiento adicional.
• Las herramientas de replicación como MirrorMaker 2 solo admiten la semántica de procesamiento al menos una vez. Esto significa que durante fallas y reinicios, los eventos de datos pueden duplicarse. Si tiene consumidores que no pueden tolerar la duplicación de datos, sugiero crear canalizaciones de datos que admitan la semántica de procesamiento exactamente una vez para replicar los datos, como Apache Flink, en lugar de utilizar MirrorMaker 2.
• Debido a que los consumidores no consumen datos directamente de los clústeres de escritura, la latencia aumenta entre los escritores y los lectores.
• En esta estrategia, aunque hay varios clústeres de Apache Kafka, la propiedad y el control aún residen en un equipo y los recursos están en una sola cuenta de AWS.

Segregación de clústeres

Para algunas empresas, proporcionar acceso a Apache Kafka a través de una plataforma de datos central puede crear desafíos de escalabilidad, propiedad y responsabilidad. Es posible que los equipos de infraestructura no entiendan las necesidades comerciales específicas de una aplicación, como la actualización de los datos o los requisitos de latencia, la seguridad, los esquemas de datos o un método específico necesario para la ingesta de datos.

A menudo, puede reducir estos desafíos otorgando propiedad y autonomía al equipo propietario de la aplicación. Les permite crear y administrar su aplicación y la infraestructura necesaria, en lugar de solo poder usar una plataforma central común. Por ejemplo, los equipos de desarrollo son responsables de aprovisionar, configurar, mantener y operar sus propios clústeres de Apache Kafka. Son los expertos en el dominio de los requisitos de su aplicación y pueden administrar su clúster de acuerdo con las necesidades de su aplicación. Esto reduce la fricción general y hace que los equipos de aplicaciones sean responsables de sus SLA anunciados.

Como se mencionó anteriormente, MSK Serverless minimiza el trabajo de operación y mantenimiento asociado con los clústeres de Apache Kafka. Esto permite que los equipos de aplicaciones autónomos administren sus clústeres de acuerdo con las mejores prácticas de la industria, sin necesidad de ser un experto en la ejecución de clústeres de Apache Kafka de alta disponibilidad en AWS. Si el clúster sin servidor de MSK se aprovisiona dentro de su cuenta de AWS, también son responsables de todos los costos asociados con la operación de sus aplicaciones y los servicios de transmisión de datos.

El siguiente diagrama muestra la arquitectura de esta estrategia.

Este enfoque tiene los siguientes beneficios:

• Los clústeres sin servidor de MSK son administrados por diferentes equipos; por lo tanto, el trabajo de gestión general se minimiza.
• Las aplicaciones están aisladas unas de otras. Una aplicación defectuosa o el tiempo de inactividad de un clúster no afecta a otras aplicaciones.
• Los consumidores leen los datos directamente con baja latencia desde el mismo clúster donde se escriben los datos.
• Cada clúster sin servidor de MSK se escala de manera diferente según su rendimiento de escritura y lectura.
• La atribución de costos simple significa que los equipos de aplicaciones son dueños de su infraestructura y su costo.
• La propiedad total de la infraestructura de transmisión permite a los desarrolladores adoptar la transmisión más rápido y ofrecer más funcionalidades. También puede ayudar a acortar su tiempo de respuesta a fallas e interrupciones.

En comparación con la estrategia anterior, este enfoque tiene las siguientes desventajas:

• Es difícil hacer cumplir una seguridad unificada o el cumplimiento normativo en muchos equipos.
• Se pueden ingerir copias duplicadas de los mismos datos en varios clústeres. Esto aumenta el costo total.
• Para aumentar la resiliencia, cada equipo necesita individualmente configurar replicaciones entre clústeres sin servidor de MSK.

Pasar de una estrategia centralizada a una descentralizada

MSK Serverless proporciona Interfaz de línea de comandos de AWS (AWS CLI) herramientas y soporte para Formación en la nube de AWS plantillas para aprovisionar clústeres en minutos. Puede implementar cualquiera de las estrategias que mencioné anteriormente a través de los métodos que proporciona AWS y migrar a sus productores y consumidores cuando los nuevos clústeres estén listos.

Los siguientes pasos proporcionan más orientación sobre la implementación de estas estrategias:

1. Comience centrándose en los problemas actuales con Apache Kafka monolítico. A continuación, compare los desafíos con los beneficios y las desventajas, tal como se enumeran en cada estrategia. Esto le ayuda a decidir qué estrategia sirve mejor a su empresa.
2. Identifique y documente los requisitos de rendimiento, resiliencia, SLA y propiedad de cada aplicación por separado.
3. Intente agrupar aplicaciones que tengan requisitos similares. Por ejemplo, puede encontrar algunas aplicaciones que ejecutan análisis por lotes; por lo tanto, no son sensibles a la actualización de los datos y tampoco necesitan acceso a datos confidenciales (o PII). Si decide que la segregación de clústeres es la estrategia adecuada para su empresa, puede optar por agrupar las aplicaciones por el equipo que las posee.
4. Compare los requisitos de rendimiento de transmisión y almacenamiento de cada grupo de aplicaciones con los Cuotas sin servidor de MSK. Esto lo ayuda a determinar si un clúster sin servidor de MSK puede proporcionar la capacidad de transmisión agregada necesaria. De lo contrario, divida aún más los grupos más grandes en grupos más pequeños.
5. Cree clústeres sin servidor de MSK por cada grupo que identificó anteriormente mediante el Consola de administración de AWS, AWS CLI o plantillas de CloudFormation.
6. Identifique los temas que corresponden a cada nuevo clúster de MSK Serverless.
7. Escoja el mejor patrón de migración a Amazon MSK de acuerdo con los requisitos de replicación. Por ejemplo, cuando no necesita la transformación de datos y las aplicaciones pueden tolerar eventos de datos duplicados, puede usar las herramientas de migración de Apache Kafka, como MirrorMaker 2.0.
8. Una vez que haya verificado que los datos se replican correctamente en los nuevos clústeres, primero reinicie los consumidores en el nuevo clúster. Esto garantiza que no se perderán datos como resultado de la migración.
9. Después de que los consumidores reanuden el procesamiento de datos, reinicie los productores en el nuevo clúster y apague la canalización de replicación que creó anteriormente.

En el momento de escribir este artículo, MSK Serverless solo admite Gestión de identidades y accesos de AWS (IAM) para autenticación y control de acceso. Para obtener más información, consulte Proteger Apache Kafka es fácil y familiar con IAM Access Control for Amazon MSK. Si sus aplicaciones usan otros métodos admitidos por Apache Kafka, debe modificar el código de su aplicación para usar IAM Access Control en su lugar o usar la oferta aprovisionada de Amazon MSK.

Resumen

MSK Serverless elimina la sobrecarga operativa, incluido el aprovisionamiento, la configuración y el mantenimiento de Apache Kafka de alta disponibilidad. En esta publicación, mostré cómo dividir los clústeres de Apache Kafka ayuda a mejorar la seguridad, el rendimiento, la escalabilidad y la confiabilidad de sus servicios y aplicaciones de transmisión de datos en general. También describí dos estrategias principales para dividir un clúster monolítico de Apache Kafka mediante MSK Serverless. Si está utilizando una oferta aprovisionada de Amazon MSK, estas estrategias siguen siendo relevantes al considerar pasar de un modelo centralizado a uno descentralizado. Puede decidir la estrategia adecuada en función de las necesidades específicas de su empresa.

Para obtener más información sobre Amazon MSK, visite el sitio web oficial la página del producto.

Sobre la autora

Alí Alemi es Arquitecto de Soluciones Especialista en Streaming en AWS. Ali asesora a los clientes de AWS con las mejores prácticas arquitectónicas y los ayuda a diseñar sistemas de datos analíticos en tiempo real que sean confiables, seguros, eficientes y rentables. Trabaja hacia atrás a partir de los casos de uso de los clientes y diseña soluciones de datos para resolver sus problemas comerciales. Antes de unirse a AWS, Ali apoyó a varios clientes del sector público y socios consultores de AWS en su proceso de modernización de aplicaciones y migración a la nube.