Conceptos de Streaming con Apache Kafka

Para comprender mejor OCI Streaming con Apache Kafka, revise algunos términos y conceptos.

Términos

Apache Kafka: Apache Kafka es una plataforma de transmisión de eventos de código abierto. Se ejecuta como un sistema distribuido que consta de servidores y clientes. OCI Streaming con Apache Kafka le permite ejecutar clusters de Kafka totalmente gestionados en un arrendamiento con una compatibilidad del 100% con Apache Kafka.

Puede utilizar la consola, la API o la CLI de OCI para crear y actualizar el cluster y el agente.

Cluster: Sistema distribuido de servidores o agentes de Apache Kafka que almacenan y gestionan los datos de transmisión. En OCI Streaming con Apache Kafka, puede crear dos tipos de clusters: cluster inicial o cluster de alta disponibilidad.
Interoperador: Un servidor de Kafka que almacena datos y procesa solicitudes de clientes. En función de la carga de trabajo, puede crear de 1 a 30 agentes en cada cluster. Cada broker de un cluster es un nodo de cálculo que se utiliza para almacenar temas.

Puede utilizar la API o la CLI de Apache Kafka para crear y actualizar temas, particiones, registros y operaciones de productores y consumidores.

Tema: Categorías definidas por el usuario en un broker donde se almacenan los datos. Cada tema puede tener muchas particiones para la distribución de datos y el procesamiento paralelo.
Particiones: Los temas se dividen en el número especificado por el usuario de particiones que almacenan registros. Los registros se ordenan dentro de cada partición y a cada registro se le asigna un desplazamiento único que aumenta secuencialmente.
Registros: Pares de datos de valor clave que se escriben y leen en temas.
Productor: Aplicación que escribe registros en temas.
Consumidor: Aplicación que lee registros de temas.
Cluster coordinador: Una instancia de coordinador interno dentro de cada cluster que realiza un seguimiento de las actividades de un cluster, como las particiones. Un cluster con 2 o menos agentes obtiene un cluster de coordinador de nodo único. Los clusters más grandes obtienen un cluster de coordinador de 3 nodos. No puede ver los detalles del cluster de coordinador.

Límites de servicios


Límite	Valor
Clusters por arrendamiento	5
Brokers por cluster	30
Corredores por arrendamiento	150
Almacenamiento	Mínimo de 50 GB a máximo de 5 TB por broker Máximo de 150 TB por cluster
Entrada por cluster	sin límites
Salida por cluster	sin límites
Entrada por partición	sin límites
Salida por partición	sin límites
Particiones	sin límites
Máximo de conexiones de cliente	sin límites
Máximo de intentos de conexión	sin límites
Máximo de solicitudes (por segundo)	sin límites
Tamaño máximo de mensaje (MB)	sin límites
Tamaño Máximo de Solicitud (MB)	sin límites
Máximo de bytes de recuperación (MB)	sin límites
Claves de API	No aplicable
ACL	sin límites
Configuraciones	100 por arrendamiento
Actualizaciones de configuración	sin límites

Límites de funciones


Función	Soporte
Exactamente una vez semántica	Sí
Almacenamiento compactado basado en claves	Sí
Conectores personalizados	No
Soporte nativo de ksqlDB	No
Redes públicas	No
Redes privadas	Sí
OAuth	No
Logs de auditoría	Sí
Claves de cifrado autogestionadas	No
Escalado elástico automático	No
Uso compartido de flujos	No
Cuotas de clientes	Sí

Tipos de cluster

En OCI Streaming con Apache Kafka, puede crear dos tipos de clusters.

Cluster de inicio: Diseñado para pruebas y desarrollo donde la alta disponibilidad no es un requisito crítico. Un cúmulo inicial ofrece una configuración flexible en la que los cúmulos pueden tener entre 1 y 30 corredores.
Cluster de alta disponibilidad: Destinado a entornos de producción donde la alta disponibilidad es esencial. Estos clusters están configurados con un mínimo de 3 agentes distribuidos en varios dominios de errores o de disponibilidad para garantizar la redundancia y la tolerancia a fallos. El cluster puede escalar hasta un máximo de 30 agentes, lo que proporciona fiabilidad y resiliencia para las cargas de trabajo esenciales.

Opciones por defecto de cluster

Revise las siguientes opciones por defecto para un cluster de Kafka.

Conectividad

Por defecto, todos los clusters de Kafka se crean con conectividad privada y se puede acceder a ellos desde la VCN y la subred especificadas durante la creación del cluster. If more VCNs need access to the Kafka cluster, configure VCN peering.

Cuotas de Broker Disk

De manera predeterminada, las cuotas de disco del broker se aplican para garantizar la estabilidad y evitar el uso excesivo de los recursos del disco. Cuando un disco de broker alcanza el 97% de capacidad, el funcionamiento del productor está limitado por la velocidad, mientras que las operaciones del consumidor no se ven afectadas y continúan funcionando como se esperaba. Cuando un disco de broker alcanza el 98% de capacidad, todas las operaciones del productor se bloquean, mientras que las operaciones del consumidor pueden seguir consumiendo eventos y confirmando desplazamientos sin interrupción. Puede cambiar este comportamiento predeterminado y definir cuotas de almacenamiento personalizadas en un archivo de configuración de cluster.

Archivo de Configuración de Cluster

Al crear un cluster de Kafka, el archivo de configuración de cluster se crea con propiedades por defecto en función del tipo de cluster. La configuración de la propiedad está diseñada para equilibrar la fiabilidad, la durabilidad y la facilidad de uso. Puede utilizar el archivo por defecto o crear un archivo personalizado. Para obtener una lista de las propiedades configurables y no configurables, consulte Managing Cluster Configurations.

Cluster de alta disponibilidad

allow.everyone.if.no.acl.found=true
auto.create.topics.enable=false
leader.imbalance.per.broker.percentage=1
default.replication.factor=3
offsets.topic.replication.factor=3
min.insync.replicas=2
transaction.state.log.min.isr=2
transaction.state.log.replication.factor=3


Propiedad	Valor por defecto	Finalidad
`allow.everyone.if.no.acl.found`	verdadero	Si no se encuentra ninguna ACL para un recurso, todos los usuarios pueden acceder al cluster.
`auto.create.topics.enable`	falso	Los temas no se crean automáticamente, se deben crear explícitamente para un mejor control.
`leader.imbalance.per.broker.percentage`	1	Controla el umbral de desequilibrio de líder por broker para el reequilibrio.
`default.replication.factor`	3	Se crean nuevos temas con 3 réplicas para una alta durabilidad.
`offsets.topic.replication.factor`	3	El tema de desviaciones internas se replica 3 veces para obtener resiliencia.
`min.insync.replicas`	2	Al menos 2 réplicas deben reconocer una escritura para mayor durabilidad.
`transaction.state.log.min.isr`	2	Mínimo de réplicas sincronizadas para el log de estado de transacción.
`transaction.state.log.replication.factor`	3	Factor de replicación para el log de estado de transacción.

Cluster de arranque

allow.everyone.if.no.acl.found=true
auto.create.topics.enable=false
leader.imbalance.per.broker.percentage=1
default.replication.factor=1
offsets.topic.replication.factor=1
min.insync.replicas=1
transaction.state.log.min.isr=1
transaction.state.log.replication.factor=1


Propiedad	Valor por defecto	Finalidad
`allow.everyone.if.no.acl.found`	verdadero	Si no se encuentra ninguna ACL para un recurso, todos los usuarios pueden acceder al cluster.
`auto.create.topics.enable`	falso	Los temas no se crean automáticamente, se deben crear explícitamente para un mejor control.
`leader.imbalance.per.broker.percentage`	1	Controla el umbral de desequilibrio de líder por broker para el reequilibrio.
`default.replication.factor`	1	Los nuevos temas se crean con 1 réplica (sin redundancia).
`offsets.topic.replication.factor`	1	El tema de desviaciones internas tiene una sola réplica.
`min.insync.replicas`	1	Solo 1 réplica necesita reconocer una escritura.
`transaction.state.log.min.isr`	1	Mínimo de réplicas sincronizadas para el log de estado de transacción.
`transaction.state.log.replication.factor`	1	Factor de replicación para el log de estado de transacción.

Planificación del tamaño y el almacenamiento del cluster

Revise las directrices de tamaño de cluster para optimizar y aprovechar al máximo un cluster de OCI Streaming con Apache Kafka.

Directrices generales

Si necesita más rendimiento, puede implantar las siguientes acciones:

Aumentar el número de brokers en el cluster
Aumentar el número de particiones en el cluster
Aumento de OCPU por broker

Si necesita una latencia inferior, puede implantar las siguientes acciones:

Usar corredores más grandes con mayor memoria
Utilizar lotes más pequeños, linger.ms más cortos y optimizar la ruta de red

Si la durabilidad es más importante que la latencia, considere definir el parámetro de configuración del productor acks definido en all.

No planificar ni configurar el cluster afecta al rendimiento del cluster.

Si se configuran menos agentes, se produce un bajo rendimiento, una alta latencia y una sobrecarga de agentes.
La configuración de menos particiones da como resultado un paralelismo deficiente y un uso bajo del consumidor.
La configuración de corredores con poca potencia da como resultado una alta latencia de recuperación o producción, problemas de GC y corredores inestables.
La configuración de demasiadas particiones en brokers más pequeños da como resultado un alto uso de memoria, una gran cantidad de metadatos y un nuevo equilibrio inestable.

Referencias de rendimiento

Revise las métricas de rendimiento de los clusters de Kafka con procesadores basados en Arm, el factor de replicación definido en 3 y el parámetro de configuración de productor acks definido en 1.

Configuración de agente	Particiones	Rendimiento máximo del productor	Rendimiento máximo del consumidor	Latencia
3 corredores, cada uno con la siguiente configuración: 2 A1 OCPU 12 Memoria de GB 200 GB de almacenamiento de bloques 10 VPU	1.000	161.21 MB por segundo	394.38 MB por segundo	50,70 ms
3 corredores, cada uno con la siguiente configuración: 12 A1 OCPU 72 Memoria de GB 300 GB de almacenamiento de bloques 10 VPU	2.000	368.76 MB por segundo	678.39 MB por segundo	27,79 ms
3 corredores, cada uno con la siguiente configuración: 20 AI OCPU 120 Memoria de GB 500 GB de almacenamiento de bloques 10 VPU	2.000	505.13 MB por segundo	710.82 MB por segundo	21,11 ms
18 corredores, cada uno con la siguiente configuración: 2 AI OCPU 12 Memoria de GB 300 GB de almacenamiento de bloques 10 VPU	2.000	379.39 MB por segundo	690.27 MB por segundo	80,18 ms
18 corredores, cada uno con la siguiente configuración: 12 AI OCPU 72 Memoria de GB 500 GB de almacenamiento de bloques 10 VPU	4.000	788.73 MB por segundo	998.11 MB por segundo	74,53 ms
18 corredores, cada uno con la siguiente configuración: 20 AI OCPU 120 Memoria de GB 1000 GB de almacenamiento de bloques 10 VPU	4.000	1.08 GB por segundo	1.15 GB por segundo	71,29 ms
30 brokers, cada uno con la siguiente configuración: 2 AI OCPU 12 Memoria de GB 300 GB de almacenamiento de bloques 10 VPU	4.000	617.60 MB por segundo	1.02 GB por segundo	98,27 ms
30 brokers, cada uno con la siguiente configuración: 12 AI OCPU 72 Memoria de GB 500 GB de almacenamiento de bloques 10 VPU	6.000	1.65 GB por segundo	1.34 GB por segundo	65,81 ms
30 brokers, cada uno con la siguiente configuración: 20 AI OCPU 120 Memoria de GB 1000 GB de almacenamiento de bloques 10 VPU	6.000	2.41 GB por segundo	2.09 GB por segundo	56,82 ms

Las métricas de rendimiento dependen de varios factores y las mejoras en una configuración podrían llevar a compensaciones en otras.

Por ejemplo, los números de rendimiento varían en función de factores como el tamaño del mensaje, el tipo de compresión, el tamaño del lote y linger.ms. Un tamaño de lote superior puede aumentar el rendimiento, pero también puede provocar una mayor latencia.

El aumento del número de particiones suele mejorar el rendimiento y el rendimiento del productor. Sin embargo, también aumenta el uso de recursos de los productores y consumidores e introduce más gastos generales de metadatos. Esto puede ralentizar la elección de líderes y la gestión de réplicas sincronizadas (ISR), lo que puede aumentar la latencia de las solicitudes de producción y recuperación.

Debe ajustar los parámetros según los requisitos.

Para optimizar la latencia, reduzca batch.size y linger.ms y evite la compresión intensa.
Para maximizar el rendimiento, aumente batch.size, active la compresión y utilice más particiones y agentes para escalar horizontalmente.

Supervise siempre de cerca las métricas de latencia y rendimiento, y ajuste el cluster de forma iterativa en función de los patrones de carga de trabajo reales.

Migrar

Puede migrar datos de un cluster de Apache Kafka autogestionado a un cluster de OCI Streaming con Apache Kafka.

La solución recomendada para este caso de uso de migración es crear un conector MirrorMaker 2.0 en un cluster de conexión.

A continuación se muestra un ejemplo de configuración client.properties:

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
ssl.truststore.location=</path/to/truststore.jks>
ssl.truststore.password=<truststore-password>
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<username>" password="<password>";

Documentación de Oracle Cloud Infrastructure