Jepsen: Prüfergebnisse für Bufstream 0.1

Update_2024-11-13

• Im ersten Bericht wurde behauptet, dass bei aktivem Auto-Commit ein Consumer automatisch die im jüngsten Poll zurückgegebenen Offsets committen könne, was zu Datenverlust führen könne.
• Mehrere Leser widersprachen jedoch und wiesen darauf hin, dass Auto-Commit-Consumer tatsächlich die Offsets des vorherigen Polls committen, nicht die des jüngsten.
• Experimente mit dem Java-Kafka-Client stützen dies; je nach Client kann das Verhalten jedoch unterschiedlich sein.
• Die konkrete Behauptung zu Auto-Commit wurde aus dem Bericht entfernt; weitere Untersuchungen sind nötig.

Hintergrund

• Kafka ist ein populäres Streaming-System, das Replikation, Sharding und append-only Logs bietet.
• Bufstream ist eine Alternative zu Kafka, die in Cloud-Umgebungen Datengovernance und Kosteneffizienz priorisiert.
• Ähnlich wie Kafka bietet Bufstream Sammlungen teilweise geordneter Logs, die als Topics bezeichnet werden; jedes Topic ist in Partitionen unterteilt.
• Bufstream ist mit standardmäßigen Kafka-Clients kompatibel und besteht aus Agents als zustandslosen Diensten, die die Kafka-API bereitstellen, einem Object Store zur Datenspeicherung sowie einem Koordinationsdienst.
• Bufstream senkt Kosten, indem Daten direkt in Object-Storage-Dienste geschrieben werden, und kann auf zustandslosen, automatisch skalierbaren VMs betrieben werden.

Client-Sicherheit

• Bufstream ist für verschiedene Streaming-Anwendungen ausgelegt und setzt unterschiedliche Client-Konfigurationsoptionen für einen sicheren Betrieb.
• Wie Kafka verwendet es standardmäßig acks = all und setzt enable.auto.commit = false, um Datenverlust zu vermeiden.
• Mit auto.offset.reset = earliest wird sichergestellt, dass Consumer das gesamte Log beobachten können.

Transaktionen

• Bufstream unterstützt Kafkas Transaktionssystem und bietet über eine komplexe Konfiguration eine schwache Form von Atomarität.
• Consumer können mit den Isolationsstufen read_uncommitted oder read_committed laufen; read_committed verhindert einige Phänomene (G1a, G1c).
• In Kafka, Redpanda und Bufstream tritt jedoch das G0-Phänomen auf, was nicht mit den dokumentierten Isolationsstufen übereinstimmt.

Testdesign

• Getestet wurden Bufstream 0.1.0 bis 0.1.3 mit der Jepsen-Testbibliothek und dem Java Kafka Client.
• Die Tests bewerten die Sicherheit von Bufstream, indem verschiedene Fehler injiziert werden.

Queue

• Es wurde eine Queue-Workload entworfen, die auf Kafkas Datenmodell abgestimmt ist und in Bufstream verwendet wird.
• Jeder logische Prozess führt Producer-, Consumer- und Admin-Clients aus und sendet Records für verschiedene Schlüssel.

Abbruch

• Auf Basis unerwarteter Ergebnisse wurde eine Workload entwickelt, die Transaktionen abbricht und Offsets verfolgt.
• Offsets nach abgebrochenen Transaktionen werden in vier Kategorien eingeteilt: Fortschritt, Zurückspulen, weiteres Zurückspulen, Sonstiges.

Bufstream-Ergebnisse

Hängende Consumer (#1)

• Von 0.1.0 bis 0.1.3-rc.8 trat ein Problem auf, bei dem consumer.poll() sofort zurückkehrte, aber keine Records lieferte.
• Bufstream behob das Problem in 0.1.3-rc.6 durch das Aktualisieren des Caches.

Hängende Producer und Consumer (#2)

• Auch in 0.1.3-rc.6 traten Probleme auf, bei denen InitProducerId-Aufrufe oder listOffsets-Aufrufe fehlschlugen.
• Bufstream behob das Problem durch zusätzliche Polling-Logik.

Falscher Offset 0 (#3)

• Von 0.1.0 bis 0.1.3-rc.2 trat ein Problem auf, bei dem fälschlicherweise Offset 0 zugewiesen wurde.
• Bufstream behob dieses Problem in 0.1.3-rc.6.

Schreibverlust bei Transaktionen (#4)

• In 0.1.2 trat ein Problem auf, bei dem Records aus committeten Transaktionen verschwanden.
• Bufstream behob das Problem in 0.1.3-rc2.

Schreibverlust durch serverseitiges Filtering (#5)

• In 0.1.3-rc.8 führte die Reaktion auf geringfügige Fehler zu Schreibverlust.
• Bufstream behob das Problem in 0.1.3-rc.12.

Kafka-Ergebnisse

Irreführende Fehlermeldung (KIP-588)

• ProducerFencedException kann auch bei einem Transaktions-Timeout auftreten.
• Dem Kafka-Team wird empfohlen, die Fehlermeldung anzupassen.

Möglichkeit unendlichen Wartens beim Beenden von Consumern (KAFKA-17734)

• Ein Aufruf von Consumer.close() kann bei Netzwerk-I/O unendlich lange blockieren.
• Das Problem wird unter KAFKA-17734 verfolgt.

Unvorhersehbare Consumer-Offsets nach Transaktionsfehlern (KAFKA-17582)

• Es fehlt an Dokumentation zum beabsichtigten Verhalten von Consumer-Offsets bei Transaktionsfehlern.
• Consumer können nach einer abgebrochenen Transaktion ihre Offsets zurückspulen oder weiter fortschreiten.

[GN⁺]

Hacker-News-Kommentare

• Bei der Untersuchung von Problemen in Kafka wurde ein unsichtbarer Schreibvorgang entdeckt. Das wirft die Möglichkeit auf, dass verzögerte Produce-Nachrichten in zukünftige Transaktionen aufgenommen werden und damit Transaktionsgarantien verletzen. Es besteht auch der Verdacht, dass der Kafka Java Client bei Request-Timeouts Sequenznummern wiederverwenden kann. Weitere Kafka-Tests sind nötig

  • Es sieht so aus, als müsste Jepsen Kafka erneut eingehend untersuchen. Die letzte Untersuchung war 2013, und es ist gut möglich, dass in Kafka selbst viele Probleme gefunden werden. Probleme wie „nach Bestätigung stillschweigend verworfen“ wirken sehr schwerwiegend

• Beim Blick auf die Produktseite von Bufstream frage ich mich, wie diese beiden Aussagen zusammenpassen

  • Bufstream läuft vollständig innerhalb einer AWS- oder GCP-VPC, sodass man volle Kontrolle über Daten, Metadaten und Verfügbarkeit hat. Bufstream kommuniziert niemals nach außen
  • Die Preise von Bufstream sind einfach: 0,002 $ pro unkomprimiertem GiB (etwa 2 $ pro TiB). Keine Gebühren pro Core, Agent oder Aufruf
  • Es wirkt nicht so, als würde das gesamte Geschäft auf einem Trust-System basieren

• Ich bin überrascht von Kafkas Auto-Commit-Funktion

  • Kafka-Consumer können Offsets automatisch committen, unabhängig davon, ob die Verarbeitung tatsächlich abgeschlossen wurde. Das bedeutet, dass Records verloren gehen können, wenn ein Consumer Records pollt, committet und danach abstürzt
  • Laut Dokumentation werden bei aktiviertem Auto-Commit die Offsets der zurückgegebenen Nachrichten bei jedem Aufruf der poll-Methode automatisch zum Commit vorgemerkt. Wenn die Nachrichtenverarbeitung nicht abgeschlossen ist, besteht bei einem Absturz das Risiko, dass der Verarbeitungsfortschritt verloren geht
  • Das Anpassen des Auto-Commit-Intervalls kann bei doppelter Verarbeitung helfen, aber nicht bei Nachrichtenverlust

• Das Kafka-Transaktionsprotokoll ist grundlegend problematisch und muss korrigiert werden

  • Hervorragende Untersuchungsarbeit und sehr gut geschrieben

• Ich frage mich, ob Kyle sich NATS Jetstream angesehen hat

• Ich konnte das GitHub-Projekt von bufstream nicht finden. Ich frage mich, ob jemand einen Hinweis hat

• Nach dem Lesen der zugehörigen Blogposts und Dokumentation scheint Kafka „exactly once delivery“ als Eigenschaft einer „Read-Process-Write-Operation“ zu definieren. Es wäre wohl besser, das als Transaktion zu beschreiben

• Die Formulierung „Transaktionen können teilweise oder vollständig beobachtet werden“ sollte wohl als „Consumer können sie teilweise oder vollständig beobachten“ gelesen werden

• Ich frage mich, wofür diese Software verwendet wird. Instrumentierung? Blackbox?