Amazon MSK sin servidor es un tipo de cluster de Streaming administrado por Amazon para Apache Kafka (Amazon MSK) que le facilita ejecutar Apache Kafka sin tener que administrar y escalar la capacidad del clúster. MSK Serverless aprovisiona y escala automáticamente los recursos informáticos y de almacenamiento. Con MSK Serverless, puede utilizar Apache Kafka a pedido y pagar por los datos que transmite y retiene según el uso.
La implementación de infraestructura en múltiples VPC y múltiples cuentas se considera la mejor práctica, ya que facilita la escalabilidad y mantiene los límites de aislamiento. En un entorno de múltiples cuentas, los productores y consumidores de Kafka pueden existir dentro de la misma VPC; sin embargo, a menudo están ubicados en diferentes VPC, a veces dentro de la misma cuenta, en una cuenta diferente o incluso en varias cuentas diferentes. Existe la necesidad de una solución que pueda extender el acceso a los clústeres MSK Serverless a productores y consumidores desde múltiples VPC dentro de la misma cuenta de AWS y en múltiples cuentas de AWS. La solución debe ser escalable y sencilla de mantener.
En esta publicación, lo guiaremos a través de múltiples enfoques de soluciones que abordan las opciones de conectividad de acceso entre VPC y entre cuentas de MSK Serverless, y analizamos las ventajas y limitaciones de cada enfoque.
Conectividad y autenticación MSK Serverless
Cuando se crea un clúster MSK Serverless, AWS administra la infraestructura del clúster en su nombre y extiende la conectividad privada a sus VPC a través de puntos finales de VPC con tecnología de Enlace privado de AWS. Usted inicia su conexión al clúster a través de un servidor de inicio que contiene un registro de todos sus corredores subyacentes.
En el momento de la creación, se asigna un nombre de dominio completo (FQDN) al servidor de arranque del clúster. El FQDN del servidor de arranque tiene el formato general de boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, y sus brokers de cluster siguen el formato de bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, donde ClusterUniqueID.xx es exclusivo de su clúster y bxxxx es un rango de corredores dinámico (b0001, b0037 y b0523 pueden ser algunos de sus corredores asignados en un momento dado). Vale la pena señalar que los corredores asignados a su clúster son dinámicos y cambian con el tiempo, pero su dirección de arranque sigue siendo la misma para el clúster. Toda su comunicación con el clúster comienza con el servidor de arranque que puede responder con la lista de corredores activos cuando sea necesario. Para una comunicación Kafka adecuada, su cliente MSK debe poder resolver los nombres de dominio de su servidor de arranque, así como de todos sus intermediarios.
En la creación del clúster, usted especifica las VPC con las que desea que se comunique el clúster (hasta cinco VPC en la misma cuenta que su clúster). Para cada VPC especificada durante la creación del clúster, se crean puntos finales de la VPC del clúster junto con una zona hospedada privada que incluye una lista de su servidor de arranque y todos los agentes dinámicos que se mantienen actualizados. Las zonas alojadas privadas facilitan la resolución de los FQDN de su servidor de arranque y corredores, desde dentro de las VPC asociadas definidas durante la creación del clúster, hasta los respectivos puntos finales de VPC para cada uno.
Acceso entre cuentas
Para poder extender la conectividad privada de sus productores y consumidores de Kafka a su clúster MSK Serverless, debe considerar tres aspectos principales: conectividad privada, autenticación y autorización, y resolución DNS.
El siguiente diagrama resalta las posibles opciones de conectividad. Aunque el diagrama las muestra todas aquí con fines de demostración, en la mayoría de los casos, usará una o más de estas opciones dependiendo de su arquitectura, no es necesario que todas estén en la misma configuración.
En esta sección, analizamos las diferentes opciones de conectividad junto con sus ventajas y desventajas. También cubrimos los aspectos de autenticación y resolución de DNS asociados con las opciones de conectividad relevantes.
Capa de conectividad privada
Esta es la conectividad de red privada subyacente. Puede lograr esta conectividad mediante el emparejamiento de VPC, Pasarela de tránsito de AWSo PrivateLink, como se indica en el diagrama anterior. Emparejamiento de VPC simplifica la configuración, pero carece de soporte para enrutamiento transitivo. En la mayoría de los casos, el emparejamiento se utiliza cuando tiene una cantidad limitada de VPC o si sus VPC generalmente se comunican con una cantidad limitada de VPC de servicios principales sin la necesidad de conectividad lateral o enrutamiento transitivo. Por otro lado, AWS Transit Gateway facilita el enrutamiento transitivo y puede simplificar la arquitectura cuando se tiene una gran cantidad de VPC y, especialmente, cuando se requiere conectividad lateral. PrivateLink es más adecuado para ampliar la conectividad a un recurso específico de forma unidireccional entre VPC o cuentas sin exponer la conectividad completa de VPC a VPC, agregando así una capa de aislamiento. PrivateLink es útil si tiene CIDR superpuestos, lo cual es un caso que no es compatible con Transit Gateway o el emparejamiento de VPC. PrivateLink también es útil cuando las partes conectadas se administran por separado y cuando se requiere conectividad unidireccional y aislamiento.
Si elige PrivateLink como opción de conectividad, deberá utilizar un Balanceador de carga de red (NLB) con un grupo objetivo de tipo IP con sus objetivos registrados establecidos como las direcciones IP de los puntos finales zonales de su clúster MSK Serverless.
Autenticación y autorización de clúster
Además de tener conectividad privada y poder resolver los nombres de dominio del servidor de arranque y de los brokers, para que sus productores y consumidores tengan acceso a su clúster, necesita configurar sus clientes con las credenciales adecuadas. Soportes MSK sin servidor Gestión de identidades y accesos de AWS (IAM) autenticación y autorización. Para el acceso entre cuentas, su cliente MSK debe asumir una función que tenga las credenciales adecuadas para acceder al clúster. Esta publicación se centra principalmente en los aspectos de conectividad entre cuentas y resolución de nombres. Para obtener más detalles sobre la autenticación y autorización entre cuentas, consulte lo siguiente Repositorio GitHub.
Resolución DNS
Para que los productores y consumidores de Kafka ubicados en cuentas de toda la organización puedan producir y consumir hacia y desde el clúster centralizado MSK Serverless, deben poder resolver los FQDN del servidor de arranque del clúster, así como de cada uno de los intermediarios del clúster. Al comprender la naturaleza dinámica de la asignación de corredores, la solución tendrá que adaptarse a dicho requisito. En la siguiente sección, abordamos cómo podemos satisfacer esta parte de los requisitos.
Resolución DNS entre cuentas del clúster
Ahora que hemos analizado cómo funciona MSK Serverless, cómo se extiende la conectividad privada y los requisitos de autenticación y autorización, analicemos cómo funciona la resolución DNS para su clúster.
Para cada VPC asociada con su clúster durante la creación del clúster, se crea un punto final de VPC junto con un zona hospedada privada. Las zonas alojadas privadas permiten la resolución de nombres de los FQDN del servidor de arranque del clúster y los brokers asignados dinámicamente, desde cada VPC respectiva. Esto funciona bien cuando las solicitudes provienen de cualquiera de las VPC que se agregaron durante la creación del clúster porque ya tienen los puntos finales de VPC necesarios y las zonas alojadas privadas relevantes.
Analicemos cómo puede extender la resolución de nombres a otras VPC dentro de la misma cuenta que no se incluyeron durante la creación del clúster y a otras que pueden estar ubicadas en otras cuentas.
Ya eligió la opción de conectividad privada que mejor se adapta a sus requisitos de arquitectura, ya sea emparejamiento de VPC, PrivateLink o Transit Gateway. Suponiendo que también haya configurado sus clientes MSK para que asuman roles que tengan las credenciales de IAM correctas para facilitar el acceso al clúster, ahora debe abordar el aspecto de la conectividad de resolución de nombres. Vale la pena señalar que, aunque enumeramos diferentes opciones de conectividad mediante el emparejamiento de VPC, Transit Gateway y PrivateLink, en la mayoría de los casos solo están presentes una o dos de estas opciones de conectividad. No necesariamente es necesario tenerlos todos; se enumeran aquí para demostrar sus opciones y usted es libre de elegir las que mejor se adapten a su arquitectura y requisitos.
En las siguientes secciones, describimos dos métodos diferentes para abordar la resolución de DNS. Para cada método, existen ventajas y limitaciones.
Zonas alojadas privadas
El siguiente diagrama destaca la arquitectura de la solución y sus componentes. Tenga en cuenta que, para simplificar el diagrama y dejar espacio para detalles más relevantes requeridos en esta sección, hemos eliminado algunas de las opciones de conectividad.
La solución comienza con la creación de una zona alojada privada, seguida de la creación de una asociación VPC.
Crear una zona alojada privada
Comenzamos creando una zona alojada privada para la resolución de nombres. Para que la solución sea escalable y fácil de mantener, puede optar por crear esta zona alojada privada en la misma cuenta del clúster MSK Serverless; en algunos casos, es preferible crear la zona alojada privada en una cuenta de red centralizada. Tener la zona alojada privada creada en la cuenta del clúster MSK Serverless facilita la administración centralizada de la zona alojada privada junto con el clúster MSK. Luego podemos asociar la zona alojada privada centralizada con VPC dentro de la misma cuenta o en otras cuentas diferentes. Elegir centralizar sus zonas privadas alojadas en una cuenta de red también puede ser una solución viable a considerar.
El propósito de la zona alojada privada es poder resolver los FQDN del servidor de arranque, así como todos los brokers asociados al clúster asignados dinámicamente. Como se analizó anteriormente, el formato FQDN del servidor de arranque es boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, y los intermediarios del clúster utilizan el formato bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, con las bxxxx siendo el ID del corredor. Debe crear la nueva zona alojada privada con el dominio principal configurado como kafka-serverless.Region.amazonaws.com, con un registro A-Alias llamado *.kafka-serverless.Region.amazonaws.com apuntando al punto final de la VPC regional del clúster MSK Serverless en la VPC del clúster MSK. Esto debería ser suficiente para dirigir todo el tráfico dirigido a su clúster a los puntos finales de la VPC del clúster principal que especificó en su zona hospedada privada.
Ahora que ha creado la zona alojada privada, para que funcione la resolución de nombres, debe asociar la zona alojada privada con cada VPC donde tenga clientes para el clúster MSK (productor o consumidor).
Asociar una zona alojada privada con VPC en la misma cuenta
Para las VPC que están en la misma cuenta que el clúster de MSK y no se incluyeron en la configuración durante la creación del clúster, puede asociarlas a la zona alojada privada creada mediante el Consola de administración de AWS editando la configuración de la zona alojada privada y agregando las VPC respectivas. Para obtener más información, consulte Asociación de más VPC con una zona alojada privada.
Asociar una zona alojada privada en VPC entre cuentas
Para las VPC que están en una cuenta diferente a la cuenta del clúster MSK, consulte Asociación de una VPC de Amazon y una zona alojada privada que creó con diferentes cuentas de AWS. Los pasos clave son los siguientes:
- Crear una autorización de asociación de VPC en la cuenta donde se crea la zona hospedada privada (en este caso, es la misma cuenta que la cuenta del clúster MSK Serverless) para autorizar que las VPC remotas se asocien con la zona hospedada:
- Asociar la VPC con la zona alojada privada en la cuenta donde tienes las VPC con los clientes MSK (cuenta remota), haciendo referencia a la autorización de asociación que creaste anteriormente:
- Eliminar la autorización de VPC para asociar la VPC con la zona alojada:
Eliminar la autorización no afecta la asociación, solo le impide volver a asociar la VPC con la zona alojada en el futuro. Si desea volver a asociar la VPC con la zona alojada, deberá repetir los pasos 1 y 2 de este procedimiento.
Tenga en cuenta que su VPC debe tener la enableDnsSupport y enableDnsHostnames Atributos DNS habilitados para que esto funcione. Estas dos configuraciones se pueden configurar en la configuración de DNS de VPC. Para obtener más información, consulte Atributos DNS en su VPC.
Estos procedimientos funcionan bien para todas las cuentas remotas cuando la conectividad se amplía mediante el emparejamiento de VPC o Transit Gateway. Si su opción de conectividad utiliza PrivateLink, la zona alojada privada debe crearse en la cuenta remota (la cuenta donde están los puntos finales de la VPC de PrivateLink). Además, es necesario crear un registro A-Alias que se resuelva en el punto final de PrivateLink en lugar del punto final del clúster MSK, como se indica en el diagrama anterior. Esto facilitará la resolución de nombres para el punto final de PrivateLink. Si otras VPC necesitan acceder al clúster a través de la misma configuración de PrivateLink, debe seguir el mismo procedimiento de asociación de zona alojada privada que se describió anteriormente y asociar sus otras VPC con la zona alojada privada creada para su VPC PrivateLink.
Limitaciones
La solución de zonas alojadas privadas tiene algunas limitaciones clave.
En primer lugar, porque está utilizando kafka-serverless.Region.amazonaws.com como dominio principal para nuestra zona alojada privada y su registro A-Alias utiliza *.kafka-serverless.Region.amazonaws.com, todo el tráfico al servicio MSK Serverless que se origina desde cualquier VPC asociada con esta zona hospedada privada se dirigirá al punto final regional de la VPC del clúster específico que especificó en el registro Alias A de la zona hospedada.
Esta solución es válida si tiene un clúster MSK Serverless en su VPC de servicio centralizado. Si necesita proporcionar acceso a varios clústeres MSK Serverless, puede utilizar la misma solución pero adaptando un enfoque de zona alojada privada distribuida en lugar de un enfoque centralizado. En un enfoque de zona alojada privada distribuida, cada zona alojada privada puede apuntar a un clúster específico. Las VPC asociadas con esa zona hospedada privada específica se comunicarán solo con el clúster respectivo que figura en la zona hospedada privada específica.
Además, después de establecer una asociación de VPC con una zona hospedada privada que resuelva *.kafka-serverless.Region.amazonaws.com, la VPC respectiva solo podrá comunicarse con el clúster definido en esa zona hospedada privada específica y con ningún otro clúster. . Una excepción a esta regla es si se crea un clúster local dentro de la misma VPC cliente, en cuyo caso los clientes dentro de la VPC solo podrán comunicarse con el clúster local.
También puede utilizar PrivateLink para acomodar múltiples clústeres creando un PrivateLink más una zona alojada privada por clúster, replicando los pasos de configuración descritos anteriormente.
Ambas soluciones, que utilizan zonas alojadas privadas distribuidas o PrivateLink, aún están sujetas a la limitación de que para cada VPC cliente, solo puede comunicarse con el clúster MSK Serverless para el que está configurada su zona alojada privada asociada.
En la siguiente sección, analizamos otra posible solución.
Reglas de resolución y AWS Resource Access Manager
El siguiente diagrama muestra una descripción general de alto nivel de la solución utilizando Ruta del Amazonas 53 reglas de resolución y Administrador de acceso a recursos de AWS.
La solución comienza con la creación. Puntos finales de resolución entrante y saliente de Route 53, que están asociados con la VPC del clúster MSK. Luego, crea una regla de reenvío de resolución en la cuenta MSK que no está asociada con ninguna VPC. A continuación, comparte la regla de resolución entre cuentas mediante Resource Access Manager. En la cuenta remota a la que necesita extender la resolución de nombres, debe aceptar el recurso compartido y asociar las reglas de resolución con sus VPC de destino ubicadas en la cuenta remota (la cuenta donde se encuentran los clientes MSK).
Para obtener más información sobre este enfoque, consulte el tercer caso de uso en Simplifique la administración de DNS en un entorno de múltiples cuentas con Route 53 Resolver.
Esta solución se adapta a múltiples clústeres centralizados sin servidor de MSK en un enfoque más escalable y flexible. Por lo tanto, la solución cuenta con direccionar las solicitudes DNS para que sean resueltas por la VPC donde se encuentran los clusters MSK. Pueden coexistir varios clústeres MSK Serverless, donde los clientes de una VPC particular pueden comunicarse con uno o más de ellos al mismo tiempo. Esta opción no es compatible con el enfoque de solución de zona alojada privada.
Limitaciones
Aunque esta solución tiene sus ventajas, también tiene algunas limitaciones.
En primer lugar, para una cuenta de consumidor o productor objetivo en particular, todos sus clústeres MSK Serverless deben estar en la misma VPC de servicio principal en la cuenta MSK. Esto se debe al hecho de que la regla de resolución se establece a nivel de cuenta y utiliza.kafka-serverless.Region.amazonaws.com como dominio principal, dirigiendo su resolución a un par entrante/saliente de punto final de resolución de VPC específico dentro de esa VPC de servicio. . Si necesita tener clústeres separados en diferentes VPC, considere crear cuentas separadas.
La segunda limitación es que todas sus VPC cliente deben estar en la misma región que su VPC central MSK Serverless. La razón detrás de esta limitación es que las reglas de resolución que apuntan a un par de puntos finales de resolución (en realidad, apuntan al punto final de salida que se conecta con los puntos finales de entrada) deben estar en la misma región que las reglas de resolución, y Resource Access Manager se extenderá la participación sólo dentro de la misma Región. Sin embargo, esta solución es buena cuando tiene varios clústeres de MSK en la misma VPC principal y, aunque sus clientes remotos están en diferentes VPC y cuentas, todavía están dentro de la misma región. Una solución alternativa para esta limitación es duplicar la creación de reglas de resolución y punto final de resolución saliente en una segunda región, donde el punto final de salida recorre el punto final de resolución entrante original de la primera región asociado con la VPC del clúster MSK Serverless (suponiendo que se facilite la conectividad IP). . Esta segunda regla de resolución de región se puede compartir mediante Resource Access Manager dentro de la segunda región.
Conclusión
Puede configurar el acceso entre VPC y entre cuentas de MSK Serverless en entornos de múltiples cuentas utilizando zonas alojadas privadas o reglas de resolución de Route 53. La solución analizada en esta publicación le permite centralizar su configuración mientras extiende el acceso entre cuentas, lo que la convierte en una solución escalable y fácil de mantener. Puede cree sus clústeres MSK Serverless con acceso entre cuentas para productores y consumidores, mantenga su enfoque en los resultados de su negocio y obtenga información de fuentes de datos en toda su organización sin tener que dimensionar y administrar correctamente una infraestructura de Kafka.
Sobre la autora
Domador Soliman es arquitecto senior de soluciones en AWS. Ayuda a los clientes de proveedores de software independientes (ISV) a innovar, crear y escalar en AWS. Tiene más de dos décadas de experiencia en la industria y es un inventor con tres patentes concedidas. Su experiencia abarca múltiples dominios tecnológicos, incluidas telecomunicaciones, redes, integración de aplicaciones, análisis de datos, IA/ML e implementaciones en la nube. Se especializa en redes AWS y tiene una profunda pasión por el aprendizaje automático, la IA y la IA generativa.
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
- PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
- PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
- PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
- Fuente: https://aws.amazon.com/blogs/big-data/secure-connectivity-patterns-for-amazon-msk-serverless-cross-account-access/
