Tema de Amazon Managed Streaming para Apache Kafka como origen - Amazon EventBridge

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Tema de Amazon Managed Streaming para Apache Kafka como origen

Puedes usar EventBridge Pipes para recibir registros de un tema de Amazon Managed Streaming for Apache Kafka (Amazon MSK). Si lo desea, también puede filtrar o enriquecer estos registros antes de enviarlos a uno de los destinos disponibles para su procesamiento. Existen ajustes específicos de Amazon MSK que puede elegir al configurar una tubería. EventBridge Pipes mantiene el orden de los registros del agente de mensajes al enviar esos datos al destino.

Amazon MSK es un servicio completamente administrado que puede usar para crear y ejecutar aplicaciones que utilizan Apache Kafka para procesar datos de streaming. Amazon MSK simplifica la configuración, el escalado y la administración de clústeres que ejecutan Apache Kafka. Con Amazon MSK, puede configurar su aplicación para varias zonas de disponibilidad y para garantizar la seguridad con AWS Identity and Access Management (IAM). Amazon MSK es compatible con múltiples versiones de código abierto de Kafka.

Amazon MSK como fuente funciona de forma similar al uso de Amazon Simple Queue Service (Amazon SQS) o Amazon Kinesis. EventBridgesondea internamente los mensajes nuevos de la fuente y, a continuación, invoca al destino de forma sincrónica. EventBridge lee los mensajes por lotes y los proporciona a su función como carga útil de eventos. El tamaño máximo del lote es configurable. (El valor predeterminado es 100 mensajes).

En el caso de las fuentes basadas en Apache Kafka, EventBridge admite parámetros de control del procesamiento, como las ventanas de procesamiento por lotes y el tamaño del lote.

EventBridge lee los mensajes de forma secuencial para cada partición. Después de EventBridge procesar cada lote, confirma las compensaciones de los mensajes de ese lote. Si el objetivo de la canalización devuelve un error para alguno de los mensajes de un lote, EventBridge vuelve a intentarlo con todo el lote de mensajes hasta que el procesamiento se realice correctamente o los mensajes caduquen.

EventBridge envía el lote de mensajes en caso de que invoque al destino. La carga de eventos contiene una matriz de mensajes. Cada elemento de matriz contiene detalles del tema y el identificador de partición de Amazon MSK, junto con una marca de hora y un mensaje codificado en base64.

Eventos de ejemplo

En el siguiente evento de ejemplo se muestra la información que recibe la canalización. Puede usar este evento para crear y filtrar sus patrones de eventos o para definir la transformación de entrada. No todos los campos se pueden filtrar. Para obtener más información sobre los campos que puede filtrar, consulte Filtrado EventBridge de Amazon Pipes.

[ { "eventSource": "aws:kafka", "eventSourceArn": "arn:aws:kafka:sa-east-1:123456789012:cluster/vpc-2priv-2pub/751d2973-a626-431c-9d4e-d7975eb44dd7-2", "eventSourceKey": "mytopic-0", "topic": "mytopic", "partition": "0", "offset": 15, "timestamp": 1545084650987, "timestampType": "CREATE_TIME", "key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", "value":"SGVsbG8sIHRoaXMgaXMgYSB0ZXN0Lg==", "headers": [ { "headerKey": [ 104, 101, 97, 100, 101, 114, 86, 97, 108, 117, 101 ] } ] } ]

Sondeo y posición inicial de flujos

Tenga en cuenta que el sondeo de flujos durante la creación de canalizaciones y las actualizaciones es, en última instancia, coherente.

  • Durante la creación de canalizaciones, es posible que se demore varios minutos en iniciar el sondeo de los eventos del flujo.

  • Durante las actualizaciones de las canalizaciones, es posible que se demore varios minutos en detener y reiniciar el sondeo de los eventos del flujo.

Esto significa que, si especifica LATEST como posición inicial del flujo, la canalización podría omitir eventos durante la creación de canalizaciones o las actualizaciones. Para garantizar que no se pierda ningún evento, especifique la posición inicial del flujo como TRIM_HORIZON.

Autenticación de clústeres de MSK

EventBridge necesita permiso para acceder al clúster de Amazon MSK, recuperar registros y realizar otras tareas. Amazon MSK admite varias opciones para controlar el acceso de los clientes al clúster de MSK. Para obtener más información acerca de este método de autenticación que se utiliza, consulte ¿Cómo elegir EventBridge un bróker bootstrap.

Acceso sin autenticar

Recomendamos utilizar únicamente el acceso no autenticado para el desarrollo. El acceso no autenticado solo funcionará si la autenticación basada en roles de IAM está deshabilitada para el clúster.

Autenticación SASL/SCRAM

Amazon MSK admite autenticación simple y autenticación de capa de seguridad/mecanismo de autenticación de respuesta por desafío saltado (SASL/SCRAM) con cifrado de seguridad de la capa de transporte (TLS). EventBridge Para conectarse al clúster, debe almacenar las credenciales de autenticación (credenciales de inicio de sesión) en secreto. AWS Secrets Manager

Para obtener más información sobre Secrets Manager, consulte Autenticación de usuario y contraseña con AWS Secrets Manager (en la Guía para desarrolladores de Amazon Managed Streaming for Apache Kafka.

Amazon MSK no admite la autenticación SASL/PLAIN.

Autenticación basada en roles de IAM

Puede utilizar IAM para autenticar la identidad de los clientes que se conectan al clúster de MSK. Si la autenticación de IAM está activa en tu clúster de MSK y no proporcionas un secreto para la autenticación, EventBridge se utilizará automáticamente la autenticación de IAM de forma predeterminada. Para crear e implementar políticas basadas en roles o usuarios de IAM, utilice la consola o la API de IAM. Para obtener más información, consulte IAM access control (Control de acceso de IAM) en la Guía para desarrolladores de Amazon Managed Streaming for Apache Kafka.

Para poder conectarte EventBridge al clúster de MSK, leer registros y realizar otras acciones necesarias, añade los siguientes permisos a la función de ejecución de tus tuberías.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kafka-cluster:Connect", "kafka-cluster:DescribeGroup", "kafka-cluster:AlterGroup", "kafka-cluster:DescribeTopic", "kafka-cluster:ReadData", "kafka-cluster:DescribeClusterDynamicConfiguration" ], "Resource": [ "arn:aws:kafka:region:account-id:cluster/cluster-name/cluster-uuid", "arn:aws:kafka:region:account-id:topic/cluster-name/cluster-uuid/topic-name", "arn:aws:kafka:region:account-id:group/cluster-name/cluster-uuid/consumer-group-id" ] } ] }

Puede asignar estos permisos a un clúster, un tema y un grupo específicos. Para obtener más información, consulte Acciones de Amazon MSK para Kafka en la Guía para desarrolladores de Amazon Managed Streaming for Apache Kafka.

Autenticación TLS mutua

TLS mutua (mTLS) proporciona autenticación bidireccional entre el cliente y el servidor. El cliente envía un certificado al servidor para que el servidor verifique el cliente, mientras que el servidor envía un certificado al cliente para que el cliente verifique el servidor.

En el caso de Amazon MSK, EventBridge actúa como cliente. Configura un certificado de cliente (como secreto en Secrets Manager) para autenticarse EventBridge con los agentes de su clúster de MSK. El certificado de servidor debe estar firmado por una entidad de certificación que esté en el almacén de confianza del servidor. El clúster de MSK envía un certificado de servidor para autenticar EventBridge a los corredores. EventBridge El certificado del servidor debe estar firmado por una entidad emisora de certificados que se encuentre en el almacén de AWS confianza.

Amazon MSK no admite certificados de servidor autofirmados, ya que todos los agentes de Amazon MSK utilizan certificados públicos firmados por las CA de Amazon Trust Services, que son de confianza de forma predeterminada EventBridge .

Para obtener más información sobre mTLS para Amazon MSK, consulte Mutual TLS Authentication (Autenticación con TLS mutua) en la Guía para desarrolladores de Amazon Managed Streaming for Apache Kafka.

Configuración del secreto de mTLS

El secreto CLIENT_CERTIFICATE_TLS_AUTH requiere un campo de certificado y un campo de clave privada. Para una clave privada cifrada, el secreto requiere una contraseña de clave privada. El certificado y la clave privada deben estar en formato PEM.

nota

EventBridge admite los algoritmos de cifrado de clave privada PBES1 (pero no PBES2).

El campo de certificado debe contener una lista de certificados y debe comenzar por el certificado de cliente, seguido de cualquier certificado intermedio, y finalizar con el certificado raíz. Cada certificado debe comenzar en una nueva línea con la siguiente estructura:

-----BEGIN CERTIFICATE----- <certificate contents> -----END CERTIFICATE-----

Secrets Manager admite secretos de hasta 65 536 bytes, que supone suficiente espacio para cadenas de certificados largas.

El formato de la clave privada debe ser PKCS #8, con la siguiente estructura:

-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----

Para una clave privada cifrada, utilice la siguiente estructura:

-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----

El siguiente ejemplo muestra el contenido de un secreto para la autenticación de mTLS mediante una clave privada cifrada. Para una clave privada cifrada, incluya la contraseña de la clave privada en el secreto.

{ "privateKeyPassword": "testpassword", "certificate": "-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" }

¿Cómo elegir EventBridge un bróker bootstrap

EventBridge elige un agente de arranque en función de los métodos de autenticación disponibles en su clúster y de si proporciona un secreto para la autenticación. Si proporciona un secreto para mTLS o SASL/SCRAM, elige EventBridge automáticamente ese método de autenticación. Si no proporciona un secreto, EventBridge elija el método de autenticación más seguro que esté activo en su clúster. El siguiente es el orden de prioridad en el que se EventBridge selecciona un intermediario, desde la autenticación más fuerte hasta la más débil:

  • mTLS (secreto proporcionado para mTLS)

  • SASL/SCRAM (secreto proporcionado para SASL/SCRAM)

  • SASL IAM (no se proporciona secreto y la autenticación de IAM está activa)

  • TLS no autenticada (no se proporciona secreto y la autenticación de IAM no está activa)

  • Texto sin formato (no se proporciona secreto y tanto la autenticación de IAM como la TLS no autenticada no están activas)

nota

Si no EventBridge puede conectarse al tipo de corredor más seguro, no intentará conectarse a un tipo de corredor diferente (más débil). Si EventBridge quiere elegir un tipo de intermediario más débil, desactive todos los métodos de autenticación más seguros de su clúster.

Configuración de red

EventBridge debe tener acceso a los recursos de Amazon Virtual Private Cloud (Amazon VPC) asociados a su clúster de Amazon MSK.

  • Para acceder a la VPC de su clúster de Amazon MSK, EventBridge puede utilizar el acceso saliente a Internet para las subredes de su fuente. Para las subredes públicas, debe ser una puerta de enlace NAT administrada. Para las subredes privadas, puede ser una puerta de enlace NAT o su propia NAT. Asegúrese de que la NAT tiene una dirección IP pública y puede conectarse a Internet.

  • EventBridge Pipes también admite la entrega directa de eventos AWS PrivateLink, lo que le permite enviar eventos desde una fuente de eventos ubicada en un Amazon Virtual Private Cloud (Amazon VPC) a un destino de Pipes sin tener que atravesar la red pública de Internet. Puedes usar Pipes para sondear desde Amazon Managed Streaming for Apache Kafka (Amazon MSK), Apache Kafka autogestionado y Amazon MQ fuentes que residen en una subred privada sin necesidad de implementar una puerta de enlace a Internet, configurar reglas de firewall o configurar servidores proxy.

    Para configurar un punto de enlace de VPC, consulte Crear un punto de enlace de VPC en la Guía del usuario.AWS PrivateLink Para el nombre del servicio, seleccione. com.amazonaws.region.pipes-data

Configure sus grupos de seguridad de Amazon VPC con las siguientes reglas (como mínimo):

  • Reglas de entrada: permita todo el tráfico en el puerto del agente de Amazon MSK para los grupos de seguridad especificados para su fuente.

  • Reglas de salida: permiten todo el tráfico en el puerto 443 para todos los destinos. Permita todo el tráfico en el puerto del broker de Amazon MSK para los grupos de seguridad especificados para su fuente.

    Los puertos de bróker incluyen:

    • 9092 para texto sin formato

    • 9094 para TLS

    • 9096 para SASL

    • 9098 para IAM

nota

La configuración de Amazon VPC se puede detectar a través de la API de Amazon MSK. No tiene que configurarla durante la configuración.

ID del grupo de consumidores personalizable

Al configurar Apache Kafka como origen, puede especificar un ID de grupo de consumidores. Este ID de grupo de consumidores es un identificador existente para el grupo de consumidores de Apache Kafka al que desea que se una su canalización. Puede utilizar esta función para migrar cualquier configuración de procesamiento de registros de Apache Kafka en curso de otros consumidores a otra. EventBridge

Si especifica un ID de grupo de consumidores y hay otros sondeadores activos dentro de ese grupo de consumidores, Apache Kafka distribuirá los mensajes entre todos los consumidores. En otras palabras, EventBridge no recibe todos los mensajes relacionados con el tema de Apache Kafka. Si EventBridge quiere gestionar todos los mensajes del tema, desactive cualquier otro sondeo de ese grupo de consumidores.

Además, si especificas un ID de grupo de consumidores y Apache Kafka encuentra un grupo de consumidores válido existente con el mismo ID, EventBridge ignora el StartingPosition parámetro de tu canal. En su lugar, EventBridge comienza a procesar los registros de acuerdo con la compensación comprometida del grupo de consumidores. Si especificas un ID de grupo de consumidores y Apache Kafka no encuentra un grupo de consumidores existente, EventBridge configura tu fuente con el especificado. StartingPosition

El ID del grupo de consumidores que especifique debe ser único entre todos los orígenes de eventos de Apache Kafka. Tras crear una canalización con el ID de grupo de consumidores especificado, no puede actualizar este valor.

Escalado automático del origen de Amazon MSK

Al crear inicialmente una fuente de Amazon MSK, EventBridge asigna un consumidor para procesar todas las particiones del tema de Apache Kafka. Cada consumidor tiene varios procesadores que se ejecutan en paralelo para gestionar el aumento de las cargas de trabajo. Además, aumenta o reduce EventBridge automáticamente el número de consumidores en función de la carga de trabajo. Para conservar el orden de mensajes en cada partición, el número máximo de consumidores es un consumidor por partición en el tema.

En intervalos de un minuto, EventBridge evalúa el desfase de compensación por consumo de todas las secciones del tema. Si el retraso es demasiado alto, la partición recibe los mensajes más rápido de lo que EventBridge puede procesarlos. Si es necesario, EventBridge añade o elimina consumidores del tema. El proceso de escalado para agregar o eliminar consumidores se produce dentro de los tres minutos posteriores a la evaluación.

Si tu público objetivo está sobrecargado, EventBridge reduce el número de consumidores. Esta acción reduce la carga de trabajo de la canalización al reducir el número de mensajes que los consumidores pueden recuperar y enviar a la canalización.