2. Inhalt
Wer wir sind
Was Apache Kafka ist
Wie wir Kafka nutzen und was wir mit Kafka & AWS erlebt haben
Wie ein Cluster funktioniert und ausfällt
Was ihr noch wissen wollt (Fragen)
3. Wer wir sind
Software Engineers bei emetriq
Java, JavaScript, Ruby (Chef), Groovy…
Apache Kafka, Cassandra, ElasticSearch
„You build it, you run it“
Moritz Siuts
@coderaid
Robert von Massow
@skompele
4. Über emetriq
kollaborativer Datenpool mit intelligenten Datenprodukten
Viele Firmen bringen Daten in den Pool ein und wir veredeln diese
Produkte sind z.B. Targeting, Retargeting oder Recommendations
Wir suchen Leute mit Talent & Interesse an:
Big Data, Cloud, Java, Ruby, Scala, Agile…
hiring (emetriq.com/jobs) and firing (jeder bekommt eine Nerf-Gun)
6. Was Kafka ist
Publish-Subscribe-Messaging System
„Kafka is a distributed, partitioned, replicated commit log service“
„Unified platform for handling all the real-time data feeds a large company
might have“
Entwickelt bei LinkedIn, verwendet u.a. bei Netflix, Yahoo…
12. Kafka Producer
Synchron oder asynchron
Batching
Compression
public class KafkaProducer<K, V> implements Producer<K, V> {
public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback){
...
}
}
13. Was macht Kafka mit den Daten?
Writes an Logfile anhängen
Beim fetch von file auf socket schreiben
Async/Background
Replication
Daten löschen wenn veraltet (Retention Time pro Topic)
Log compaction
Leader election
14. API High Level Consumer
Kann 1 bis n Topics konsumieren
Konsumiert ein oder mehr Partitionen
Können in einer ConsumerGroup zusammengefasst werden
Maximal ein Consumer pro Partition (in der gleichen Group)
18. Kafka @ emetriq
6 Kafka-Broker mit je 4 TB
ca. 2600 Msg-In/s pro Broker (15.600 Msg-In/s im Cluster zur Mittagszeit)
Teilweise hohe Peaks (z.B. wenn jemand 5 Tore in einem Spiel schießt)
Deployed in AWS: eu-west-1, je 2 Broker pro AZ, c4.xlarge Instanzen
typisch: Replikationsfaktor 2; Retention Time 14 Tage
Async-Batch-Producer mit GZIP Compression (keine Log-Compaction)
19. TTL greift nicht bei Broker Recovery
Wenn ein Broker seine Daten verliert, werden sie neu gezogen
Die TTL eines Topics gilt für die Timestamps der Logfiles auf der Platte
Die Files werden beim Recovery neu angelegt
BAM: doppelter Diskspace benötigt bis zum Ende der TTL
https://issues.apache.org/jira/browse/KAFKA-1379
20. Skalierung / Performance
Zookeeper macht viele IOPS, deshalb Provisioned IOPS EBS nehmen
vor allem wenn die Consumer zu oft die Offsets commiten
Kafka braucht echt wenig CPU und auch RAM
wenn man sein Netzwerk auslastet bekommt man aber schnell Probleme
bei AWS braucht man also trotzdem große Instanzen
http://blog.parsely.com/post/1738/kafkapocalypse/
21. Langsame EBS
Langsame EBS können zu
Problemen bei
in-sync-replicas (ISR) führen
ISR = max. 4000 Msg hinter Leader
22. Producer Queues
„Kafka will remain available in the presence of node failures after a short fail-
over period“
Die Queues müssen groß genug sein um die fail-over-period abzufangen
Vor allem in Autoscaling-Szenarien spannend (und wenn man Code
optimiert und mit einem Mal n-fach mehr Req/Server abarbeitet)