Concepts liés à Streaming avec Apache Kafka
Pour mieux comprendre OCI Streaming avec Apache Kafka, passez en revue certains termes et concepts.
Conditions
- Apache Kafka
- Apache Kafka est une plate-forme de streaming d'événements open source. Il s'exécute comme un système distribué composé de serveurs et de clients. OCI Streaming with Apache Kafka vous permet d'exécuter des clusters Kafka entièrement gérés dans une location avec une compatibilité à 100 % avec Apache Kafka.
Vous utilisez la console, l'API ou l'interface de ligne de commande OCI pour créer et mettre à jour le cluster et le broker.
- Cluster
- Système distribué de serveurs ou de courtiers Apache Kafka qui stockent et gèrent les données de transmission en continu. Dans OCI Streaming avec Apache Kafka, vous pouvez créer deux types de cluster : un cluster de démarrage ou un cluster haute disponibilité.
- Broker
- Serveur Kafka qui stocke les données et traite les demandes client. En fonction de la charge globale, vous pouvez créer entre 1 et 30 brokers dans chaque cluster. Chaque broker d'un cluster est un noeud de calcul utilisé pour stocker des rubriques.
Vous utilisez l'API ou l'interface de ligne de commande Apache Kafka pour créer et mettre à jour des rubriques, des partitions, des enregistrements, ainsi que des opérations de fournisseur de portlets et de destinataire.
- Sujet
- Catégories définies par l'utilisateur dans un broker où les données sont stockées. Chaque rubrique peut comporter de nombreuses partitions pour la distribution des données et le traitement parallèle.
- Partitions
- Les rubriques sont divisées en nombre de partitions spécifié par l'utilisateur qui stockent les enregistrements. Les enregistrements sont triés au sein de chaque partition et un décalage unique croissant séquentiellement est affecté à chaque enregistrement.
- Enregistrements
- Paires de données de valeur de clé écrites et lues à partir de sujets.
- Producteur
- Application qui écrit les enregistrements dans les rubriques.
- Destinataire
- Application qui lit les enregistrements des rubriques.
- Groupe de coordinateurs
- Instance de coordinateur interne au sein de chaque cluster qui suit les activités d'un cluster, telles que les partitions. Un cluster avec 2 brokers ou moins obtient un cluster de coordinateurs de noeud unique. Les clusters plus grands reçoivent un cluster de coordinateurs à 3 noeuds. Vous ne pouvez pas afficher les détails du cluster de coordinateurs.
Limites de service
| Limite | Valeur |
|---|---|
| Clusters par location | 5 |
| Courtiers par cluster | 30 |
| Courtiers par location | 150 |
| Stockage |
50 Go minimum à 5 To maximum par courtier 150 To maximum par cluster |
| Entrée par cluster | pas de limites |
| Sortie par cluster | pas de limites |
| Entrée par partition | pas de limites |
| Sortie par partition | pas de limites |
| Partitions | pas de limites |
| Nombre maximal de connexions client | pas de limites |
| Nombre maximum de tentatives de connexion | pas de limites |
| Nombre maximal de demandes (par seconde) | pas de limites |
| Taille maximale des messages (Mo) | pas de limites |
| Taille maximale de demande (Mo) | pas de limites |
| Nombre maximal d'octets d'extraction (Mo) | pas de limites |
| Clés d'API | Sans objet |
| listes de contrôle d'accès | pas de limites |
| Configurations | 100 par location |
| Mises à jour de la configuration | pas de limites |
Limites des fonctionnalités
| Fonction | Assistance |
|---|---|
| Exactement une fois sémantique | Oui |
| Stockage compacté basé sur une clé | Oui |
| Connecteurs personnalisés | Non |
| Support natif ksqlDB | Non |
| Réseau public | Non |
| Réseau privé | Oui |
| OAuth | Non |
| Journaux d'audit | Oui |
| Clés de cryptage autogérées | Non |
| Redimensionnement élastique automatique | Non |
| Partage de flux | Non |
| Quota de clients | Oui |
Types de cluster
Dans OCI Streaming avec Apache Kafka, vous pouvez créer deux types de cluster.
- Cluster de démarrage
- Conçu à des fins de test et de développement, lorsque la haute disponibilité n'est pas une exigence essentielle. Une grappe de démarrage offre une configuration flexible où les grappes peuvent avoir entre 1 et 30 courtiers.
- Cluster haute disponibilité
- Destiné aux environnements de production où la haute disponibilité est essentielle. Ces clusters sont configurés avec un minimum de 3 brokers répartis sur plusieurs domaines de disponibilité ou de pannes pour garantir la redondance et la tolérance aux pannes. Le cluster peut évoluer jusqu'à un maximum de 30 courtiers, offrant fiabilité et résilience pour les charges de travail critiques.
Options par défaut du cluster
Passez en revue les options par défaut suivantes pour un cluster Kafka.
- Connectivité
- Par défaut, tous les clusters Kafka sont créés avec une connectivité privée et sont accessibles à partir du VCN et du sous-réseau spécifiés lors de la création du cluster. Si davantage de réseaux cloud virtuels ont besoin d'accéder au cluster Kafka, configurez l'appairage VCN.
- Quotas du disque Broker
- Par défaut, les quotas de disque du broker sont appliqués pour garantir la stabilité et empêcher la surutilisation des ressources de disque. Lorsqu'un disque de courtier atteint une capacité de 97 %, l'exploitation du producteur est limitée par le taux tandis que les opérations du consommateur ne sont pas affectées et continuent de fonctionner comme prévu. Lorsqu'un disque de broker atteint une capacité de 98 %, toutes les opérations du producteur sont bloquées, tandis que les opérations du consommateur peuvent continuer à consommer des événements et à valider des décalages sans interruption. Vous pouvez modifier ce comportement par défaut et définir des quotas de stockage personnalisés dans un fichier de configuration de cluster.
- Fichier de configuration de cluster
- Lorsque vous créez un cluster Kafka, le fichier de configuration du cluster est créé avec des propriétés par défaut en fonction du type de cluster. Les paramètres de propriété sont conçus pour équilibrer la fiabilité, la durabilité et la facilité d'utilisation. Vous pouvez utiliser le fichier par défaut, ou créer un fichier personnalisé. Pour obtenir la liste des propriétés configurables et non configurables, reportez-vous à Gestion des configurations de cluster.
Cluster haute disponibilité
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=3Propriété Valeur par défaut Objet allow.everyone.if.no.acl.foundvrai Si aucune liste de contrôle d'accès n'est trouvée pour une ressource, tous les utilisateurs sont autorisés à accéder au cluster. auto.create.topics.enablefaux Les sujets ne sont pas créés automatiquement, ils doivent être créés explicitement pour un meilleur contrôle. leader.imbalance.per.broker.percentage1 Contrôle le seuil de déséquilibre de leader par courtier pour le rééquilibrage. default.replication.factor3 De nouvelles rubriques sont créées avec 3 répliques pour une durabilité élevée. offsets.topic.replication.factor3 La rubrique des décalages internes est répliquée 3 fois pour la résilience. min.insync.replicas2 Au moins 2 répliques doivent accuser réception d'une écriture pour plus de durabilité. transaction.state.log.min.isr2 Nombre minimal de répliques synchronisées pour le journal d'état des transactions. transaction.state.log.replication.factor3 Facteur de réplication pour le journal d'état des transactions. Cluster de démarrage
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=1Propriété Valeur par défaut Objet allow.everyone.if.no.acl.foundvrai Si aucune liste de contrôle d'accès n'est trouvée pour une ressource, tous les utilisateurs sont autorisés à accéder au cluster. auto.create.topics.enablefaux Les sujets ne sont pas créés automatiquement, ils doivent être créés explicitement pour un meilleur contrôle. leader.imbalance.per.broker.percentage1 Contrôle le seuil de déséquilibre de leader par courtier pour le rééquilibrage. default.replication.factor1 De nouveaux sujets sont créés avec 1 réplique (aucune redondance). offsets.topic.replication.factor1 La rubrique des décalages internes comporte une seule réplique. min.insync.replicas1 Seule 1 réplique doit accuser réception d'une écriture. transaction.state.log.min.isr1 Nombre minimal de répliques synchronisées pour le journal d'état des transactions. transaction.state.log.replication.factor1 Facteur de réplication pour le journal d'état des transactions.
Planifier la taille du cluster et le stockage
Consultez les directives de dimensionnement du cluster pour optimiser et tirer le meilleur parti d'un cluster OCI Streaming avec Apache Kafka.
Instructions générales
Si vous avez besoin de plus de débit, vous pouvez implémenter les actions suivantes :
- Augmenter le nombre de brokers dans le cluster
- Augmenter le nombre de partitions dans le cluster
- Augmenter l'OCPU par broker
Si vous avez besoin d'une latence plus faible, vous pouvez implémenter les actions suivantes :
- Utiliser des brokers plus volumineux avec une mémoire plus élevée
- Utiliser des lots plus petits,
linger.msplus court et optimiser le chemin réseau
Si la durabilité est plus importante que la latence, envisagez de définir le paramètre de configuration du producteur acks sur all.
Le fait de ne pas planifier ni configurer le cluster a une incidence sur les performances du cluster.
- La configuration de moins de brokers entraîne un faible débit, une latence élevée et une surcharge du broker.
- La configuration d'un nombre réduit de partitions entraîne un mauvais parallélisme et une faible utilisation par le consommateur.
- La configuration de brokers sous-puissants entraîne une latence élevée de l'extraction ou de la production, des problèmes de ramasse-miettes et des brokers instables.
- La configuration d'un trop grand nombre de partitions sur des brokers plus petits entraîne une utilisation élevée de la mémoire, une saturation des métadonnées et un rééquilibrage instable.
Tests d'évaluation des performances
Passez en revue les mesures de performances sur les clusters Kafka avec des processeurs Arm, le facteur de réplication défini sur 3 et le paramètre de configuration du fournisseur de portlets acks défini sur 1.
| Configuration du broker | Partitions | Débit maximal du producteur | Débit maximal du consommateur | Latence |
|---|---|---|---|---|
3 brokers, chacun avec la configuration suivante :
|
1 000 | 161.21 Mo par seconde | 394.38 Mo par seconde | 50,70 ms |
3 brokers, chacun avec la configuration suivante :
|
2 000 | 368.76 Mo par seconde | 678.39 Mo par seconde | 27,79 ms |
3 brokers, chacun avec la configuration suivante :
|
2 000 | 505.13 Mo par seconde | 710.82 Mo par seconde | 21.11 ms |
18 brokers, chacun avec la configuration suivante :
|
2 000 | 379.39 Mo par seconde | 690.27 Mo par seconde | 80,18 ms |
18 brokers, chacun avec la configuration suivante :
|
4 000 | 788.73 Mo par seconde | 998.11 Mo par seconde | 74,53 ms |
18 brokers, chacun avec la configuration suivante :
|
4 000 | 1.08 Go par seconde | 1.15 Go par seconde | 71,29 ms |
30 brokers, chacun avec la configuration suivante :
|
4 000 | 617.60 Mo par seconde | 1.02 Go par seconde | 98,27 ms |
30 brokers, chacun avec la configuration suivante :
|
6 000 | 1.65 Go par seconde | 1.34 Go par seconde | 65,81 ms |
30 brokers, chacun avec la configuration suivante :
|
6 000 | 2.41 Go par seconde | 2.09 Go par seconde | 56,82 ms |
Les indicateurs de performances dépendent de plusieurs facteurs et les améliorations apportées à une configuration peuvent entraîner des compromis dans d'autres.
Par exemple, les numéros de débit varient en fonction de facteurs tels que la taille des messages, le type de compression, la taille des lots et linger.ms. Une taille de batch plus élevée peut augmenter le débit, mais peut également entraîner une latence plus élevée.
L'augmentation du nombre de partitions améliore généralement le débit et les performances du producteur. Toutefois, elle augmente également l'utilisation des ressources par les producteurs et les consommateurs et augmente la surcharge liée aux métadonnées. Cela peut ralentir l'élection de leader et la gestion des répliques synchronisées (ISR), ce qui peut augmenter la latence des demandes de production et d'extraction.
Vous devez régler les paramètres en fonction des exigences.
- Pour optimiser la latence, réduisez
batch.sizeetlinger.mset évitez la compression lourde. - Pour optimiser le débit, augmentez
batch.size, activez la compression et utilisez davantage de partitions et de brokers pour évoluer horizontalement.
Surveillez toujours étroitement les mesures de latence et de débit et réglez le cluster de manière itérative en fonction de modèles de charge de travail réels.
Migrer
Vous pouvez migrer des données d'un cluster Apache Kafka autogéré vers un cluster OCI Streaming avec Apache Kafka.
La solution recommandée pour ce cas d'utilisation de migration est de créer un connecteur MirrorMaker 2.0 dans un cluster de connexion.
Voici un exemple de configuration
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>";