Am 30. Januar hatten spoud und Puzzle ITC das Privileg, das dritte Kafka Meetup der Messaging & Streaming Group Schweiz zu hosten. Nebst einem schmackhaften Apéro lockte das Meetup mit zwei spannenden Talks von Samuel Benz (spoud.io) und Benoit Perroud (Sqooba).
Christian Gafner und Thomas Philipona berichten darüber.
Talk 1: Über DistributedLogs zur Datenbankreplikation (Speaker: Samuel Benz)
Bei mehreren Millionen Nutzern von Services ist der Betrieb von tausenden Server weltweit erforderlich. Um die bestehenden Bedürfnisse für weltweit verfügbare Services stemmen zu können, ist die Verwendung von verteilten Systemen unabdingbar geworden. Da die Qualität dieser Services stets zufriedenstellend sein muss, werden entsprechende Massnahmen nötig.
Hierbei spielt die Replikation von Datenbanken eine sehr wichtige Rolle. Sie trägt nicht zuletzt massgeblich bei der Verbesserung von User Experience bei, indem Ausfälle vermindert und Latenzen minimiert werden. Das replizieren von Datenbanken birgt aber Risiken, die es zu beachten gilt. Damit alle Prozesse im Konsens bleiben können, müssen sie synchron laufen und den dafür vorgesehenen Protokollen folgen. Die dabei verwendeten Prozesse ergeben aneinandergereiht einen Atomic Broadcast. Mit Atomic Broadcast lässt sich dann DistributedLog zur Anwendung bringen.
Was ist DistributedLog?
DistributedLog ist ein hochleistungsfähiger, replizierter Log-Stream-Speicher, welcher Langlebigkeit, Replikation und hohe Konsistenz als wesentliche Voraussetzungen für den Aufbau zuverlässiger verteilter Systeme bietet.
Talk 2: Datenlokalität innerhalb Kafka (Speaker: Benoit Perroud)
Bei Datenlokalität handelt es sich um das Wissen, wo und wie relevante Daten gehalten werden. Es gilt: Je näher die Daten zum aktuellen Standort, desto kleiner ist die beim Zugriff entstehende Latenz. Andererseits bieten Daten, die von weit entfernten Standorten abgefragt werden können, eine weitaus höhere Verfügbarkeit.
Hadoop, seit 2008 ein Top-Level-Projekt der Apache Software Foundation, ermöglicht die Durchführung von intensiven Rechenprozessen (Big Data) auf Computercluster. Mittels MapReduce werden die zu prozessierenden Daten in einzelne Teile aufgespalten und mehreren Rechnern gleichzeitig übergeben. Dies resultiert in einer sehr hohen Rechengeschwindigkeit, sodass viele Daten in kurzer Zeit verarbeitet werden können. Werden diese Daten jedoch abgefragt, entstehen Latenzen, sodass jeweils mit einem vergleichbar erheblichen Zeitaufwand gerechnet werden muss. Mit dem KIP-392 (Kafka Improvement Proposals) „Allow consumers to fetch from closest replica“ wurde diese Problematik auch innerhalb von Kafka Cluster adressiert. Dies ermöglicht es nun die Replicas so zu konfigurieren, dass sie über Datacenter und einzelne Racks hinaus verteilt werden. Und das Consumer, falls erlaubt. vom nächsten Replica lesen können. Dies resultiert in tieferer Latenz für die Zugriffe und weniger outbound traffic, was je nach Infrastruktur die Kosten für Datentransfer reduziert.