- Kafka a réussi à l’ère des data centers comme journal distribué, mais dans le cloud public, le coût réseau inter-AZ et la charge d’exploitation des disques locaux deviennent importants
- WarpStream est une plateforme de streaming sans disque compatible avec le protocole Apache Kafka, qui fonctionne sur un stockage objet comme S3 sans disque local ni rééquilibrage des brokers
- Dans un cluster Kafka sur 3 zones de disponibilité, le coût de transfert inter-AZ est d’environ 0,053 $ par 1 GiB streamé, même dans le meilleur des cas, soit plus que le coût de stockage mensuel de 1 GiB sur S3 à 0,021 $
- WarpStream sépare stockage et calcul, ainsi que données et métadonnées, avec un Agent binaire Go sans état et un magasin de métadonnées distinct, tandis que les données restent dans le stockage objet du compte cloud du client
- Le coût peut être réduit de 5 à 10 fois sur la plupart des workloads Kafka, mais l’implémentation actuelle impose une latence P99 d’environ 400 ms pour les requêtes Produce et d’environ 1 seconde de bout en bout entre producteur et consommateur
La structure de base de Kafka, devenue coûteuse dans le cloud
- Depuis sa publication en open source en 2011, Apache Kafka s’est imposé comme une infrastructure de base des architectures de streaming
- Le problème n’est pas tant Kafka lui-même que le fait que sa conception, adaptée au data center de LinkedIn en 2011, correspond mal aux workloads cloud modernes
- Le coût et la charge opérationnelle sont particulièrement visibles
- Économie du cloud : le mode de réplication de Kafka peut fortement augmenter les coûts de bande passante inter-AZ
- Charge opérationnelle : exploiter son propre cluster Kafka exige une équipe dédiée et des outils sur mesure
- Des systèmes similaires qui stockent les données sur disque local peuvent rencontrer les mêmes problèmes de coût et d’exploitation
Kafka-nomics : le coût des transferts inter-AZ
- Dans un cluster Kafka classique réparti sur 3 zones de disponibilité, les données produites sont écrites hors zone avec une probabilité de 2/3 à cause de l’emplacement du leader de partition, puis le leader réplique ces données vers les followers des deux autres zones
- Le coût pour transférer 1 GiB entre zones est estimé à 0,022 $
- egress depuis la zone source : 0,01 $
- ingress dans la zone de destination : 0,01 $
- Même dans le meilleur des cas, le coût pour streamer 1 GiB est d’environ
0.02 * 2/3 + 0.02 * 2 = $0.053
- Stocker 1 GiB pendant un mois sur S3 coûte 0,021 $, et le coût de copie des données de Kafka du producteur au consommateur permettrait de conserver les mêmes données plus de deux mois sur S3
- Dans les clusters Kafka à fort débit, ce sont les frais de bande passante inter-AZ qui dominent le coût plutôt que le matériel, jusqu’à représenter 70 à 90 % du coût du workload
- Même avec un faible débit, si la durée de rétention est longue, la capacité de stockage augmente, et une approche en SSD local avec réplication triple peut coûter environ 10 à 20 fois plus par GiB qu’un stockage objet comme S3, même en supposant 100 % d’utilisation du disque
L’exploitation du cluster à la charge des développeurs
- Les développeurs adoptent Kafka pour résoudre des problèmes métier, mais doivent d’abord apprendre Kafka, ZooKeeper ou KRaft, l’élection du leader, les partitions, les consumer groups, le rééquilibrage, le tuning des brokers et celui des clients
- Le plan de données de Kafka, les brokers, ainsi que le plan de contrôle fondé sur le consensus — contrôleurs, ZooKeeper, etc. — s’exécutent tous directement sur des SSD locaux
- Un cluster Kafka auto-hébergé nécessite une équipe spécialisée et des outils personnalisés pour effectuer en toute sécurité même des opérations de base comme le remplacement de nœuds ou l’extension du cluster
- L’outil intégré de réaffectation de partitions d’Apache Kafka ne peut pas générer automatiquement un plan de réaffectation lors de la mise hors service d’un broker, et l’administrateur doit rédiger lui-même le plan de déplacement des réplicas de partition
- Même les services hébergés comme AWS MSK ne suppriment pas complètement la charge opérationnelle
- La documentation de rééquilibrage de cluster de MSK renvoie vers la documentation d’Apache Kafka
- Cette procédure inclut l’édition manuelle d’un JSON pour indiquer quelles partitions déplacer vers quels brokers
- Cruise Control peut alléger la charge, mais ajoute aussi de nouveaux concepts à apprendre, un service supplémentaire à déployer et superviser, ainsi que des points de fragilité opérationnels
- Cruise Control est lui-même une application JVM qui dépend d’Apache Kafka et de ZooKeeper
Une approche qui place le streaming sur le stockage objet
- Husky, créé chez Datadog, était une base de données colonnaire pour données d’observabilité fonctionnant directement sur S3, et se comportait en grande partie comme un data lake sans état et à autoscaling
- Après la création de Husky, un cluster Kafka paraissait relever d’une architecture ancienne par comparaison
- Chez Datadog, la bande passante Kafka se mesurait en dizaines de GiB/s et le stockage des brokers en NVMe de l’ordre du PiB
- Les workloads de stockage à grande échelle ont du mal, dans le cloud, à rivaliser avec l’économie, la fiabilité, la scalabilité et l’élasticité du stockage objet
- Des technologies big data comme Snowflake et Databricks conçoivent elles aussi leurs systèmes autour du stockage objet générique
- Construire directement sur S3 un système comparable à Kafka permet de réduire simultanément deux charges
- réduction des coûts
- réduction des problèmes d’exploitation propres à Kafka traditionnel
- La difficulté centrale est de construire une infrastructure de streaming à faible latence sur un support de stockage à forte latence comme S3, sans disque local, tout en conservant la sémantique du protocole Kafka
Architecture de WarpStream
- WarpStream est une plateforme de streaming compatible avec le protocole Apache Kafka, qui fonctionne directement sur des magasins d’objets génériques comme AWS S3, GCP GCS et Azure Blob Storage
- Il n’y a pas de coût de bande passante inter-AZ, pas de disques locaux à administrer, et la solution peut s’exécuter dans le VPC du client
- À la place des brokers Kafka, WarpStream utilise un Agent
- L’Agent est un binaire Go sans état
- Il n’utilise pas la JVM
- Il parle le protocole Kafka
- N’importe quel Agent peut jouer le rôle de leader de topic, gérer les commits d’offsets des consumer groups et agir comme coordinateur de cluster
- WarpStream remplace la structure avec état de Kafka par deux séparations
- séparation du stockage et du calcul, avec déport des données vers S3
- séparation des données et des métadonnées, avec déport des métadonnées vers un magasin de métadonnées sur mesure
- Une fois tout le stockage transféré vers le stockage objet, il n’est plus nécessaire de rééquilibrer les données lorsqu’on augmente ou réduit le nombre d’Agents selon la charge
- En cas de panne, les requêtes peuvent être immédiatement retentées sur un autre Agent, ce qui accélère la reprise
- Les problèmes de hotspots où certains brokers Kafka sont plus chargés à cause d’un déséquilibre des données par partition sont eux aussi largement réduits
- Les métadonnées d’un Virtual Cluster WarpStream sont stockées dans une base de données de métadonnées personnalisée
- La réplication des données, la durabilité et la disponibilité sont assurées par le bucket de stockage objet, et les données du client restent dans son compte cloud
- La seule chose qui sort du compte cloud, ce sont les métadonnées du workload nécessaires au consensus, comme l’ordre des batches dans une partition
- L’architecture détaillée est décrite dans la documentation d’architecture de WarpStream
Exemples de coûts et compromis sur la latence
- Dans l’environnement de test, un workload de streaming continu produit en permanence 140 MiB/s de données, consommées par 3 consommateurs dédiés, pour un total de 560 MiB/s de transfert continu
- Le coût réseau inter-AZ sur l’ensemble du compte cloud a été mesuré à moins de 15 $ par jour en moyenne
- Si le même workload était exécuté sur un cluster Kafka, les seuls coûts réseau inter-AZ seraient estimés à 641 $ par jour
- formule de calcul :
0.14GiB * $0.053/GiB * 60 * 60 * 24
- Le coût des opérations API S3 pour ce même workload est inférieur à 40 $ par jour
- Le matériel nécessaire pour les Agents se limite à des VM totalisant 27 vCPU
- Le coût total de possession de la plupart des workloads Kafka peut être 5 à 10 fois plus faible avec WarpStream
- Le principal inconvénient est la latence
- le P99 des requêtes Produce est actuellement d’environ 400 ms
- car aucun accusé de réception n’est envoyé avant que les données ne soient stockées durablement sur S3 et validées dans le control plane cloud
- la latence P99 de bout en bout entre producteur et consommateur est d’environ 1 seconde
- Si le workload peut tolérer une latence P99 d’environ 1 seconde entre producteur et consommateur, il est possible de réduire de 5 à 10 fois le coût du streaming par GiB tout en éliminant presque toute la charge opérationnelle
- L’interface n’est pas un protocole propriétaire mais Kafka, et la solution peut fonctionner dans des environnements utilisant AWS S3, GCP GCS et Azure Blob Storage
Expérience développeur et utilisation
- WarpStream s’attaque d’abord à deux problèmes majeurs de Kafka : l’économie du cloud et la charge opérationnelle
- Kafka pose aussi un problème d’expérience développeur, les partitions étant considérées comme une abstraction de trop bas niveau pour écrire des applications complexes de traitement de flux
- Il est prévu d’aborder plus tard des moyens de rapprocher l’écriture d’applications de traitement de flux de celle des applications traditionnelles
- La démo peut être lancée en moins de 30 secondes
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStream est la présentation produit d’une entreprise qui vend une alternative basée sur le stockage objet à Apache Kafka, et les chiffres et comparaisons du texte doivent être lus dans ce contexte
1 commentaires
Avis sur Hacker News
L’affirmation selon laquelle « presque toutes les entreprises tech utilisent Kafka » me semble fausse
Je n’ai pas de preuves à opposer, mais sur les 6 entreprises où j’ai travaillé récemment, aucune n’utilisait Kafka ; dans l’entreprise précédente, j’avais piloté son adoption, mais on l’a abandonné plus tard
LinkedIn a créé Kafka pour résoudre des problèmes d’hyper-échelle que 99 % des gens n’ont pas, et même si les ingénieurs ont la réputation d’utiliser des technologies dont ils n’ont pas besoin, je pense que la plupart réussissent à éviter d’utiliser Kafka
Si c’est tout ce dont on a besoin, il est facile à utiliser comme un simple broker de messages sans période de rétention ; si l’on a besoin de faire des choses particulières en exploitant la persistance, on peut aller dans cette direction
Si l’on a des sentiments négatifs envers un outil open source robuste et largement utilisé, même dans sa forme de base, c’est généralement à cause de certaines fonctionnalités ou de certains cas d’usage spécifiques
Au contraire, ce genre de formulation donne une mauvaise image de ce fournisseur. On peut critiquer Kafka ou lui faire concurrence sur ses avantages et inconvénients techniques, mais déformer sa position sur le marché n’est pas terrible
Je ne doute pas qu’il existe de bons cas d’usage, mais jusqu’ici je n’ai vu que des adeptes enthousiastes qui essayaient de l’imposer dans n’importe quelle situation, ce qui m’a laissé un mauvais arrière-goût ; je suis donc plutôt dans le camp de ceux qui le « détestent »
Je suis d’accord avec la partie « Accidental SRE », mais Kafka est une technologie solide, et c’est pour cela qu’il existe aussi quantité d’outils de type « un Kafka meilleur que Kafka », comme Redpanda
La fin semble s’éloigner du sujet. Même si ce n’est pas largement utilisé, cela n’a rien à voir avec le fait que ce soit ou non une technologie clivante. Pour les personnes qui résolvent les problèmes de passage à l’échelle du 1 % mentionné, cela peut toujours être un objet qu’on aime ou qu’on déteste
C’est un peu comme dire que l’affirmation « les Lamborghini divisent » est fausse parce que la plupart des gens n’ont pas de Lamborghini. L’auteur a aussi explicitement limité le périmètre en disant « dans le domaine des données »
J’ai quelques questions
Ainsi, le coût des PUT S3 est proportionnel au nombre d’Agents en cours d’exécution et à l’intervalle de flush, pas au nombre de topic-partitions. Les requêtes Produce ne sont pas acquittées tant que les données ne sont pas stockées de façon durable dans S3 et dans le plan de contrôle cloud
Je pense qu’on ne devrait pas avoir à choisir entre fiabilité et coût. WarpStream offre le niveau de fiabilité et de disponibilité d’un déploiement sur 3 zones de disponibilité pour le coût d’une seule zone de disponibilité
L’ordre est géré par une base de données de métadonnées personnalisée exécutée dans le plan de contrôle cloud
Il n’y a pas de problème en soi à avoir un cluster Kafka dans chaque zone de disponibilité et à ne répliquer qu’au moment de les fusionner plus tard. Mais dès qu’on a des systèmes distribués et des zones de disponibilité, les ingénieurs, ainsi que les exigences métier, finissent généralement par choisir une configuration multi-zones de disponibilité. C’est pareil pour les régions
La plupart des clusters Kafka sont donc multi-zones de disponibilité, alors qu’en réalité ce n’est souvent pas nécessaire, et la facture qui en résulte est imputée à Kafka
Le protocole Kafka ne préserve pas réellement l’ordre des opérations au sein d’une partition Kafka. Il préserve l’ordre des opérations au sein d’une paire producteur-partition, et encore, seulement avec une configuration spécifique
L’implémentation standard préserve l’ordre dans lequel le broker reçoit les messages du producteur, mais du point de vue d’un système externe, cela revient plutôt à dire que, lorsqu’elle est correctement configurée, les messages d’une clé donnée et d’un producteur donné sont préservés dans leur ordre de réception
Le Cloud Metadata Store joue-t-il en fait le rôle d’attribution des offsets ?
Je suis Ryan Worl, cofondateur et CTO de WarpStream. Je suis très heureux d’annoncer la developer preview de notre système de streaming compatible avec le protocole Kafka, construit directement sur S3.
Il n’y a pas de disques/nœuds avec état à exécuter, pas de rééquilibrage des données, pas de ZooKeeper, et pas de coûts de bande passante entre zones de disponibilité, ce qui le rend 5 à 10 fois moins cher.
Si vous avez des questions sur WarpStream, j’y répondrai avec mon cofondateur richieartoul.
L’une des raisons pour lesquelles je ne l’avais pas fait, c’est que je sentais un paradoxe : si l’échelle n’est pas importante, est-ce que les utilisateurs ne devraient pas simplement utiliser SQLite directement plutôt que vouloir un Kafka en miniature ?
Mais il se peut que des gens aiment la sémantique du protocole Kafka, ou qu’ils utilisent déjà Kafka et se rendent compte que l’échelle envisagée n’est pas la bonne et qu’ils n’ont pas besoin d’en supporter la complexité. Bonne chance.
Si vous prenez en charge Cloudflare R2, ce serait aussi intéressant pour le multicloud.
Fournit-il aussi des garanties d’ordre comme celles que Kafka fournit au niveau des partitions ?
Si le « 5 à 10 fois moins cher » vient surtout de la réduction des coûts entre zones de disponibilité, AWS MSK ne le propose-t-il pas aussi ?
Une chose est sûre : faire tourner Kafka « dans les règles de l’art » sur des VM individuelles chez un fournisseur cloud coûte absurdement cher.
Je me souviens avoir eu avec plusieurs clients une discussion très simple à propos de Kafka et Hadoop : pourquoi répliquer à nouveau les données au niveau VM/disque alors que les disques sont déjà fournis comme un système entièrement redondant ?
Dans ce cas, c’était Azure Storage, qui proposait du stockage localement redondant, redondant par zone de disponibilité et géoredondant, dont une bonne partie pouvait être utilisée pour exécuter des disques managés.
C’est pourquoi un service managé Hadoop/Kafka cloud bien conçu utilise des adaptateurs de stockage afin d’exploiter la redondance intégrée du fournisseur. C’est aussi pour cela que certains fournisseurs cloud proposent des brokers d’événements compatibles Kafka.
Le reste de WarpStream ressemble plutôt à la cerise sur le gâteau, mais je suis curieux de savoir comment l’architecture interne évite les coûts entre zones de disponibilité.
Pour contexte, je travaille chez Microsoft, mais avant de les rejoindre il y a près de dix ans, je construisais des clusters Hadoop/Spark/Kafka.
Certaines implémentations de Raft autorisent des nœuds qui ont un droit de vote mais ne peuvent pas devenir leader de quorum. Par exemple, une agence dont tout le trafic passe par un tunnel VPN asymétrique ne devrait pas être élue leader, mais sait quels candidats elle peut voir.
Le coût de base d’exploitation d’un cluster était donc plus proche de 2,2 fois que de 3 fois le matériel, ce qui faisait une grosse différence pour les petites solutions ou les sandboxes de développeurs. C’est important quand 3 shards ne fournissent pas tout à fait assez de charge mais que 5 en font trop, ou même dans la différence entre 6 et 7.
Le problème, c’est qu’en réplication géographique, cela ne résout pas les deux problèmes au cœur de cet article. Du point de vue de l’économie du cloud, la stratégie de réplication de Kafka crée par conception d’énormes coûts de bande passante entre zones de disponibilité ; du point de vue opérationnel, exploiter son propre cluster Kafka nécessite en pratique une équipe dédiée et des outils custom sophistiqués.
Cela dit, il faut retrouver cette capacité dans le cloud, surtout quand le balancier recommence à revenir vers davantage d’auto-hébergement, comme cela a toujours été le cas par le passé.
EBS et les solutions similaires ont un coût. C’est particulièrement cher quand on a besoin de beaucoup d’IOPS. On peut économiser les coûts de trafic entre zones de disponibilité, mais on finit par payer des sommes absurdes pour le stockage.
En répliquant soi-même, on peut utiliser du stockage attaché bien moins cher.
À richieartoul : l’article de blog force un peu le trait.
Kafka n’exige pas intrinsèquement une équipe d’experts dédiée et des millions de dollars tant qu’on n’exploite pas de très gros clusters.
En revanche, je suis entièrement d’accord sur le fait qu’un cluster réparti sur 3 zones de disponibilité engloutit de l’argent en frais de transfert entre zones. C’est aussi comme cela qu’AWS vend MSK. Le transfert entre zones de disponibilité est présenté comme « gratuit », mais en réalité il est déjà inclus dans le prix.
Ça a l’air intéressant, mais après avoir lu « Accidental SRE », j’ai deux questions.
Le bare metal existe depuis longtemps, et je n’ai pas l’impression que gérer son propre bare metal soit devenu beaucoup plus facile. Si c’était vraiment facile, les utilisateurs finaux géreraient davantage eux-mêmes ce genre de choses.
Alors, comment gérez-vous ce service ? Est-ce chez un fournisseur cloud, ou sur bare metal ?
Vous avez tous les deux beaucoup d’expérience avec FoundationDB, qui est généralement autogéré. Avez-vous donc de nouveau choisi FoundationDB comme stockage de métadonnées ? Si oui, ou si non, j’aimerais savoir pourquoi.
Ainsi, toutes les données du client restent dans son compte cloud et dans ses buckets S3, et nous ne pouvons ni les voir ni y toucher. Le client doit bien exécuter lui-même le WarpStream Agent, mais ce n’est qu’un conteneur sans état facile à gérer.
Nous avons étudié FoundationDB pour le stockage de métadonnées, mais avons finalement choisi de ne pas l’utiliser. Pour rendre le niveau gratuit économiquement viable, il fallait rendre le stockage de métadonnées aussi efficace que possible pour ce cas d’usage précis, et cela nécessitait quelque chose de plus custom.
FoundationDB reste néanmoins une excellente technologie. Parmi les nombreuses bases de données distribuées que j’ai utilisées, c’est la meilleure.
Dire « Combien de partitions faut-il utiliser ? Ce n’est pas clair, mais une fois qu’on a choisi, on ne peut plus jamais changer, donc il faut bien choisir » est tout simplement faux. Le nombre de partitions peut être modifié
Et l’affirmation répétée selon laquelle « exploiter Kafka nécessite toute une équipe d’ingénieurs » m’échappe aussi. D’après mon expérience, ce n’est pas vrai. Les coûts d’exploitation sont certes élevés, mais dans notre équipe cela ne demande pas beaucoup de temps d’ingénierie
Très intéressant. J’ai conçu quelque chose de similaire et je comptais l’implémenter en Zig https://github.com/fremantle-industries/transit
Une grande partie de la puissance de Kafka vient de son API, et j’en suis arrivé à une conclusion similaire : la complexité de gestion des clusters finira par être abstraite par différentes implémentations
Si l’on peut implémenter la persistance Kafka au-dessus de l’espace de clés S3, on peut commencer par une persistance directe dans S3 comme WarpStream, puis ajouter ensuite des mécanismes de hiérarchisation avec des disques chauds plus rapides et de la mémoire afin de réduire la latence de bout en bout
J’aime bien cette direction. Si tu veux en discuter plus en profondeur, tu peux me contacter sur Twitter https://twitter.com/rupurt
Dans un ancien poste, j’ai construit quelque chose qui ressemblait sans doute beaucoup à ce produit. Nous avions plusieurs dizaines de To de trafic de machine learning par jour, et comme nous n’avions pas besoin de latence temps réel, nous avons tout déplacé vers S3, ce qui a réduit les coûts d’environ 90 %
C’était construit sur la JVM, et nous utilisions encore un cluster Kafka de 6 brokers pour conserver les métadonnées. Quand tout était initialement dans Kafka, il y avait probablement 300 brokers
Le modèle calcul/stockage de Kafka ne passe pas très bien à l’échelle pour les cas d’usage extrêmes où l’on peut accepter de la latence, et le modèle d’Apache Pulsar convenait mieux. Cela dit, à l’époque, Pulsar n’était pas assez stable pour être utilisé en production
L’un des points clés de l’efficacité économique était que les volumes de données étaient suffisamment importants pour ne pas avoir à attendre longtemps avant d’atteindre une taille de fichier rentable. J’ai du mal à imaginer qu’un pipeline à moins de 10 Mo/s fonctionne efficacement de cette façon
Est-ce que c’était memq de Pinterest, ou bien autre chose ?
Le titre de l’article aurait dû être « Kafka is dead. Long live WarpStream. ». La partie « long live » désigne le successeur
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!