Dans cet article, je présente une étude comparant les environnements pour Apache Kafka. L’objectif ultime est de trouver la configuration la plus efficace et d’obtenir le meilleur rapport qualité-prix. Notre plateforme de données fournit des services gérés pour créer des plateformes analytiques pour de grands ensembles de données, en concurrence avec d'autres solutions du marché. Pour rester compétitifs, nous menons régulièrement des recherches internes pour identifier et améliorer nos points forts, garantissant ainsi de meilleures transactions. Cet article présente une de ces études. Actuellement, notre plateforme prend en charge AWS et GCP en tant que fournisseurs de cloud. Les deux proposent plusieurs générations de calcul et deux architectures de processeur (x86 avec Intel et AMD, et ARM). Je compare ces configurations à l'aide de diverses machines virtuelles Java (JVM) pour évaluer les performances des nouvelles versions sur des processeurs plus récents. Si vous voulez un TL;DR : ARM est génial. L’architecture moderne et coûteuse ne signifie pas toujours « meilleure ». Vous pouvez accéder directement aux résultats ou en savoir plus sur la méthodologie et la configuration. Méthodologie J'ai envisagé de tester les performances avec notre propre service, mais je voulais les comparer dans différents environnements que nous n'avons pas encore pris en charge. Je voulais découvrir de nouvelles machines virtuelles, régions et même d'autres fournisseurs de cloud. J'ai donc commencé par implémenter un projet de jouet qui utilise Kafka de base avec différentes images de conteneurs de base. De cette façon, je peux exécuter des outils de référence sur du matériel spécifique et mesurer les performances. Mon objectif est de tester différentes configurations pour identifier les résultats les plus intéressants. Pour cela, j'utilise l'idée de la matrice de test pour filtrer les premiers résultats. J'analyserai ces résultats en profondeur à l'aide d'outils tels que perf et eBPF pour affiner davantage les performances. Cas de test Décrivons d'abord les objectifs des tests. J'ai beaucoup d'expérience avec OpenJDK JVM, mais aujourd'hui, il existe de nombreuses alternatives proposées par Microsoft, Amazon et d'autres sociétés. Amazon Correto, par exemple, inclut des fonctionnalités supplémentaires et des correctifs optimisés pour AWS. Étant donné que la plupart de nos clients utilisent AWS, je souhaitais inclure Amazon Correto dans les tests pour voir comment ces JVM fonctionnent sur cette plate-forme. J'ai choisi ces versions pour la première comparaison : OpenJDK 11 (pour une comparaison rétrospective, même si elle est obsolète) OpenJDK 17 (la JVM actuellement utilisée) Amazon Coretto 11.0.22-amzn (une comparaison rétrospective alternative) Amazon Coretto 17.0.10-amzn (une alternative à notre version actuelle) Amazon Coretto 21.0.2-amzn (une version LTS plus récente qui devrait être meilleure) Une fois les versions définies, j'ai préparé quelques scripts pour créer des images Kafka en utilisant et . Amazon Correto OpenJDK Paramètres des images Pour les tests d'analyse comparative, j'ai modifié les paramètres de Kafka pour me concentrer sur des mesures de performances spécifiques. Je voulais tester différentes combinaisons de , il était donc important de minimiser les effets de la connectivité réseau et des performances du disque. Je l'ai fait en exécutant des conteneurs avec tmpfs pour le stockage des données : [JVM] x [instance_type] x [architecture] x [cloud_provider] podman run -ti \ --network=host \ --mount type=tmpfs,destination=/tmp \ kfbench:3.6.1-21.0.2-amzn-arm64 Naturellement, cette configuration n’est pas destinée à la production, mais il était nécessaire d’isoler les goulots d’étranglement du processeur et de la mémoire. La meilleure façon est de supprimer les influences du réseau et du disque des tests. Autrement, ces facteurs fausseraient les résultats. J'ai utilisé l'outil de référence sur la même instance pour garantir une latence minimale et une reproductibilité plus élevée. J'ai également essayé des tests sans configurations de réseau hôte et avec des réseaux virtuels isolés par groupe de contrôle, mais ceux-ci n'ont fait qu'ajouter une latence inutile et une utilisation accrue du processeur pour le transfert de paquets. Bien que tmpfs alloue dynamiquement de la mémoire et puisse provoquer une fragmentation et une latence, cela s'est avéré adéquat pour notre test. J'aurais pu utiliser ramdisk à la place, qui alloue de la mémoire de manière statique et évite ces problèmes, mais tmpfs était plus facile à implémenter et fournissait toujours les informations que nous recherchions. Pour nos besoins, cela a trouvé le bon équilibre. De plus, j'ai appliqué des pour supprimer plus fréquemment les données de la mémoire : paramètres Kafka supplémentaires ############################# Benchmark Options ############################# # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.bytes # Chaged from 1GB to 256MB to rotate files faster log.segment.bytes = 268435456 # https://kafka.apache.org/documentation/#brokerconfigs_log.retention.bytes # Changed from -1 (unlimited) to 1GB evict them because we run in tmpfs log.retention.bytes = 1073741824 # Changed from 5 minutes (300000ms) to delete outdated data faster log.retention.check.interval.ms=1000 # Evict all data after 15 seconds (default is -1 and log.retention.hours=168 which is ~7 days) log.retention.ms=15000 # https://kafka.apache.org/documentation/#brokerconfigs_log.segment.delete.delay.ms # Changed from 60 seconds delay to small value to prevent memory overflows log.segment.delete.delay.ms = 0 Voici un résumé des changements : est défini sur 15 secondes pour supprimer les données plus rapidement, et est limitée à 1 Go pour gérer le stockage dans tmpfs. est également modifiée à 256 Mo pour une rotation des fichiers plus rapide. Le temps de conservation des journaux la taille de conservation des journaux La taille du segment de journal L' est réduit à 1 seconde pour supprimer rapidement les anciennes données intervalle de vérification de la rétention Le est défini sur 0 pour éviter les problèmes de mémoire délai de suppression du segment Cette configuration n'est pas adaptée à une utilisation en production, mais elle est importante pour nos tests de référence car elle réduit les effets de facteurs non pertinents. Types d'instances Chez DoubleCloud, au moment de la rédaction de cet article, nous prenons en charge ces principales générations de ressources de calcul : : instances m5a (avec i1 représentant m5 avec processeurs Intel) Famille s1 : instances m6a (avec i2 représentant m6i avec processeurs Intel) Famille s2 : instances standard GCP n2 avec processeurs AMD Rome Famille sg1 Pour les processeurs Graviton, nous prenons en charge : : instances m6g (Graviton 2) Famille g1 : instances m7g (Graviton 3) Famille g2 De plus, j'ai testé les instances t2a sur GCP comme alternative à Graviton sur Ampere Altra. Nous ne les proposons pas à nos clients en raison du support régional limité d'AWS, mais je les ai inclus dans les benchmarks pour comparer les performances. Ceux-ci pourraient être une bonne option si vous êtes dans l’une des « bonnes » régions. Outil de référence Pour le benchmarking, j'ai développé un léger basé sur . Cet outil sature efficacement Kafka sans devenir lui-même le goulot d'étranglement. outil la bibliothèque et l'exemple Franz-go Bien que soit connu pour sa fiabilité et sa popularité, je l'ai évité en raison de problèmes potentiels avec cgo. librdkafka Test Kafka est réputé pour son évolutivité, permettant de diviser les sujets en plusieurs partitions afin de répartir efficacement les charges de travail horizontalement entre les courtiers. Cependant, je me suis concentré sur l'évaluation des performances monocœur pour notre attention particulière sur le rapport performance/prix. Par conséquent, les tests ont utilisé des sujets avec des partitions uniques pour utiliser pleinement les capacités de base individuelles. Chaque scénario de test comprenait deux types : Production synchrone : attend l'accusé de réception du message, idéal pour mesurer les environnements à faible latence où les millisecondes comptent, comme les applications en temps réel Production asynchrone : met en mémoire tampon les messages et les envoie par lots, typique des clients Kafka qui équilibrent les besoins en temps quasi réel avec une latence tolérable de 10 à 100 ms. J'ai utilisé des messages de 8 Ko, plus volumineux qu'un cas client moyen, pour saturer complètement les threads de partition de sujet. Résultats Je présente une série de graphiques comparant différents cas de test en utilisant une synthétique pour évaluer différentes architectures. Cette métrique quantifie , fournissant ainsi une évaluation simple de la rentabilité architecturale. métrique d'efficacité les millions de lignes que nous pouvons ingérer dans le courtier Kafka pour cent Il est important de reconnaître que les résultats réels peuvent varier en raison des remises supplémentaires proposées par les fournisseurs de cloud. Dans la mesure du possible, les tests ont été effectués à Francfort pour les deux fournisseurs de cloud (ou aux Pays-Bas dans les cas où les options de type d'instance étaient limitées). Graphiques Sur tous les graphiques, j'utilise des noms conventionnels pour les instances, les mêmes que ceux utilisés par leurs fournisseurs. Les instances sont triées d'abord par fournisseurs de cloud (AWS, puis GCP) puis par génération : de l'ancienne à la plus récente. Les résultats complets, bien que sous forme brute, sont disponibles dans ma . Vous y trouverez plus de données que celles présentées dans cet article, notamment les chiffres de latence et de bande passante, ainsi que les performances comparatives des différentes JVM. fiche d'analyse comparative complète Résultats AWS Famille s1 : performances les plus lentes Les instances s1 de « 1ère génération » basées sur la génération m5a avec AMD EPYC 7571, datant du troisième trimestre 2019, sont notre option héritée. Ils sont les moins efficaces et les plus lents parmi nos options à Francfort, coûtant environ ~0,2080 €/heure à la demande. La transition vers la nouvelle famille s2, coûtant environ 0,2070 €/h, permet d'obtenir une efficacité deux fois supérieure pour pratiquement le même prix. Nous encourageons les clients à migrer vers ces options plus rentables et plus performantes pour améliorer les temps de requête et la vitesse d'ingestion pour les applications analytiques. Famille g1 : efficacité comparable à s2 La famille g1 est basée sur Graviton 2 et offre historiquement un bon rapport qualité-prix, mais la nouvelle famille s2 avec processeurs AMD correspond désormais à son niveau d'efficacité pour Apache Kafka. Malgré une bande passante légèrement inférieure et un avantage de prix marginal, la famille g1 est désormais considérée comme obsolète par rapport aux options plus récentes. famille g2 : efficacité supérieure La famille g2, alimentée par Graviton 3, se distingue comme notre principale recommandation en raison de son efficacité supérieure. Il surpasse les familles s2 et i2 jusqu'à 39 % dans certains scénarios, offrant une solution rentable dans presque toutes les régions, ce qui le rend idéal pour la plupart des cas d'utilisation d'Apache Kafka. Compte tenu de la nature typiquement liée aux E/S de Kafka, l'optimisation de l'efficacité informatique s'avère cruciale pour réaliser des économies. J'ai observé une tendance croissante à adopter l'architecture arm64, avec près de la moitié de nos clusters tirant déjà parti de cette nouvelle technologie. tendances d'efficacité x86_64 Les tests montrent que chaque nouveau processeur AMD ou Intel s'améliore en termes de débit global et de latence. Malgré cela, les gains d’efficacité des nouvelles générations m6 et m7 ont plafonné. Même la génération m7, bien qu'elle offre potentiellement une latence plus faible dans certaines régions, est en deçà de l'efficacité par rapport à la famille g2, selon nos tests. Famille m7a : performances de latence de pointe La famille m7a excelle dans les applications à faible latence, surpassant les générations Intel et AMD précédentes en termes de débit et de latence. Bien qu'elle ne soit pas universellement disponible, cette architecture reflète les progrès d'AMD en matière d'amélioration des performances. S'il est accessible dans votre région, pensez au m7a pour des résultats supérieurs. Résultats GCP Comparaison d'efficacité avec AWS Les instances GCP ont généralement une efficacité inférieure à celle de leurs alternatives AWS. Cela a été une excellente idée pour moi, car les clients préfèrent généralement GCP pour sa rentabilité dans les applications analytiques, ce qui se traduit par des factures moins élevées. Notre famille sg1 utilise la génération standard n2, comparable à la famille AWS s2. Cependant, ma tentative d'étendre cette comparaison à d'autres types d'instances a été limitée par la disponibilité régionale, en particulier pour les générations c3 et n2. Processeurs Arm Tau : rentabilité Les instances Arm utilisant les processeurs Tau de GCP offrent une amélioration d'efficacité de 5 à 7 % par rapport à Graviton 2, ce qui en fait une option raisonnablement économique, . Bien que la prise en charge de GCP pour les instances arm soit limitée à quatre régions, elle offre des performances et une efficacité comparables à celles de la famille g1. si elle est disponible dans votre région Remises d’utilisation durable Étant donné que les clusters Apache Kafka utilisent constamment la machine virtuelle, tirer parti permet d’obtenir jusqu’à 20 % de remise. Cela rend les puissances de calcul encore plus anciennes, comme Ampere Altra, compétitives avec Graviton 3 en termes d'efficacité. Les comparaisons directes sont cependant délicates ici, en raison des remises AWS supplémentaires qui peuvent également s'appliquer. des remises d’utilisation durable Informations sur la JVM Je pensais voir une amélioration significative avec les nouvelles versions de JVM sur l'architecture ARM. Cependant, il semble que openjdk-11 et corretto-11 soient déjà assez optimisés pour ARM. Étant donné que les versions plus récentes de Kafka nécessitent Java 17 et versions ultérieures, je suis passé à Java 17, ce qui a entraîné un gain de performances d'environ 4 à 8 % dans nos tests de performance. De plus, la version 21.0.2-amzn semble prometteuse, offrant une amélioration supplémentaire des performances de 10 à 20 % sur les types d'instances les plus récents. Conclusions De temps en temps, j'effectue des recherches internes pour trouver des solutions optimales pour nos pôles de production et recueillir des informations utiles. L'évolution vers l'architecture ARM est avantageuse pour les services gérés, car elle permet d'économiser de l'argent et de réduire la consommation d'énergie. Le recours aux ARM s'est déjà révélé bénéfique, améliorant les performances et la rentabilité du service géré pour Apache Kafka et du service géré pour ClickHouse. Cette recherche a permis d'affiner notre matrice de tests, en identifiant les environnements les plus efficaces et les domaines à optimiser davantage. Nous sommes toujours là-dessus : peaufiner et peaufiner sous le capot, et je suis heureux de partager nos connaissances avec la communauté. Restez à l'écoute!
