Jepsen : résultats de la vérification de Bufstream 0.1

Mise à jour_2024-11-13

• Le rapport initial affirmait qu’avec l’auto-commit activé, un consumer pouvait valider automatiquement l’offset renvoyé par le poll le plus récent, ce qui pouvait entraîner une perte de données.
• Cependant, plusieurs lecteurs ont objecté qu’un consumer en auto-commit valide en réalité l’offset du poll précédent, et non celui du plus récent.
• Les résultats d’expériences avec le client Java Kafka vont également dans ce sens, même si le comportement peut varier selon les clients.
• L’affirmation précise concernant l’auto-commit a été retirée du rapport, et des recherches supplémentaires sont nécessaires.

Contexte

• Kafka est un système de streaming populaire qui fournit réplication, sharding et logs append-only.
• Bufstream est une solution alternative à Kafka qui privilégie la gouvernance des données et l’efficacité des coûts dans les environnements cloud.
• Comme Kafka, Bufstream fournit des ensembles de logs partiellement ordonnés appelés topics, chacun étant divisé en partitions.
• Bufstream est compatible avec les clients Kafka standard et se compose d’un agent, service sans état qui expose l’API Kafka, d’un object store qui stocke les données, et d’un service de coordination.
• Bufstream réduit les coûts en écrivant directement les données dans un service de stockage objet, et peut être exploité sur des VM sans état à mise à l’échelle automatique.

Sécurité côté client

• Bufstream est conçu pour divers types d’applications de streaming et définit plusieurs options de configuration client pour garantir un comportement sûr.
• Comme Kafka, il utilise acks = all par défaut et définit enable.auto.commit = false afin d’éviter les pertes de données.
• Il utilise auto.offset.reset = earliest afin que les consumers puissent observer l’intégralité du log.

Transactions

• Bufstream prend en charge le système de transactions de Kafka et fournit une forme faible d’atomicité via une configuration complexe.
• Les consumers peuvent s’exécuter avec les niveaux d’isolation read_uncommitted ou read_committed, et read_committed empêche certains phénomènes (G1a, G1c).
• Des phénomènes G0 se produisent sur Kafka, Redpanda et Bufstream, ce qui ne correspond pas aux niveaux d’isolation documentés.

Conception des tests

• Les tests ont porté sur Bufstream 0.1.0 à 0.1.3, en utilisant la bibliothèque de test Jepsen et le client Java Kafka.
• Les tests évaluent la sûreté de Bufstream en injectant différents types de pannes.

File d’attente

• Une charge de travail de type file d’attente, alignée sur le modèle de données de Kafka, a été conçue pour être utilisée sur Bufstream.
• Chaque processus logique exécute des clients producer, consumer et admin, et envoie des records pour différentes clés.

Aborts

• Sur la base de résultats inattendus, une charge de travail a été conçue pour interrompre des transactions et suivre les offsets.
• Les offsets après une transaction interrompue ont été classés en quatre catégories : avance, rembobinage, rembobinage supplémentaire, autre.

Résultats de Bufstream

Consumer bloqué (#1)

• De la version 0.1.0 à 0.1.3-rc.8, consumer.poll() renvoyait immédiatement sans retourner de records.
• Bufstream a résolu le problème dans la version 0.1.3-rc.6 en rafraîchissant le cache.

Producer et consumer bloqués (#2)

• Même en 0.1.3-rc.6, des appels InitProducerId ou listOffsets pouvaient échouer.
• Bufstream a résolu le problème en ajoutant une logique de polling supplémentaire.

Offset 0 incorrect (#3)

• De la version 0.1.0 à 0.1.3-rc.2, un offset 0 incorrect pouvait être attribué.
• Bufstream a corrigé ce problème dans la version 0.1.3-rc.6.

Perte d’écritures transactionnelles (#4)

• En 0.1.2, des records de transactions validées pouvaient disparaître.
• Bufstream a corrigé le problème dans la version 0.1.3-rc2.

Perte d’écritures due au filtrage côté serveur (#5)

• En 0.1.3-rc.8, une perte d’écritures pouvait se produire en réaction à des défauts mineurs.
• Bufstream a corrigé le problème dans la version 0.1.3-rc.12.

Résultats de Kafka

Message d’erreur trompeur (KIP-588)

• ProducerFencedException peut aussi survenir lors d’un timeout transactionnel.
• Il est recommandé à l’équipe Kafka de modifier le message d’erreur.

Risque d’attente infinie à la fermeture du consumer (KAFKA-17734)

• Un appel à Consumer.close() peut attendre indéfiniment sur des IO réseau.
• Le problème est suivi via KAFKA-17734.

Offsets consumer imprévisibles après échec de transaction (KAFKA-17582)

• La documentation sur le comportement attendu des offsets consumer lors d’un échec de transaction est insuffisante.
• Après une transaction interrompue, un consumer peut rembobiner ses offsets ou continuer à avancer.

[GN⁺]

Avis Hacker News

• En enquêtant sur les problèmes survenant dans Kafka, une écriture invisible a été découverte. Cela soulève la possibilité qu’un message Produce retardé soit inclus dans une transaction future, violant ainsi les garanties transactionnelles. Il y a aussi un soupçon selon lequel le client Java Kafka pourrait réutiliser des numéros de séquence lorsqu’une requête expire. Davantage de tests sur Kafka sont nécessaires

  • Il semble que Jepsen doive refaire une enquête approfondie sur Kafka. La dernière remonte à 2013, et il y a de fortes chances de découvrir de nombreux problèmes dans Kafka lui-même. Des problèmes comme « accusé de réception de l’écriture puis suppression silencieuse » paraissent très graves

• En regardant la page produit de Bufstream, je me demande comment ces deux affirmations peuvent être compatibles

  • Bufstream s’exécute entièrement dans un VPC AWS ou GCP, ce qui permet de contrôler totalement les données, les métadonnées et la disponibilité. Bufstream ne communique jamais avec l’extérieur
  • La tarification de Bufstream est simple : 0,002 $ par GiB non compressé (environ 2 $ par TiB). Aucun frais par cœur, agent ou appel
  • Il ne semble pas que toute l’activité puisse reposer sur un système de confiance

• Je suis surpris par la fonctionnalité d’auto-commit de Kafka

  • Un consommateur Kafka peut automatiquement valider des offsets, qu’ils aient réellement été traités ou non. Cela signifie que si le consommateur récupère des enregistrements, les valide, puis plante, ces enregistrements peuvent être perdus
  • D’après la documentation, lorsque l’auto-commit est activé, les offsets des messages renvoyés à chaque appel de la méthode poll sont automatiquement préparés pour validation. Si le traitement des messages n’est pas terminé, il existe un risque de perdre la progression des messages en cas de crash
  • Ajuster l’intervalle d’auto-commit peut aider à réduire les traitements en double, mais pas la perte de messages

• Le protocole transactionnel de Kafka semble fondamentalement défectueux et nécessite une correction

  • Excellente enquête et excellent article

• Je me demande si Kyle a examiné NATS Jetstream

• Je n’ai pas trouvé le projet GitHub de bufstream. Je me demande si quelqu’un a un indice

• Après avoir lu l’article de blog et la documentation associés, Kafka définit le « exactly-once delivery » comme une propriété de l’opération « lecture-traitement-écriture ». Il vaudrait sans doute mieux la décrire comme une transaction

• La phrase « une transaction peut être observée en partie ou en totalité » devrait probablement se lire comme « un consommateur peut l’observer en partie ou en totalité »

• Je me demande à quoi sert ce logiciel. Instrumentation ? Boîte noire ?