MixIt 2015 - retour d'expérience sur Kafka

Transcript

1. MIX-IT 04/2015 Retour d'expérience sur Kafka Vladislav Pernin @vladislavpernin
2. 1. Contexte 2. Concepts 3. Architecture 4. Métriques 5. Retour d'expérience
3. Contexte
4. Projet en cours & en production
5. Pourquoi un broker de messages ?
6. Découplage entre briques logicielles Brique 1 production Kafka Brique 2 consommation
7. Robustesse Brique 1 production Kafka Brique 2 consommation
8. Persistance sur disque Pas de perte de message sur panne ou arrêt
9. Absorber des vitesses de traitements différentes Brique 1 production Kafka Brique 2 consommation 6000 messages/s 5000 messages/s
10. Performance : Throughput & latence
11. Absorber des pics de charge
12. Consommer très vite
13. Volumétrie * 100 d'ici 2 ans
14. Scalabilité horizontale Kafka 1 Kafka 2 Kafka 3 Kafka n ...
15. Architecture en pipeline Collecte événements Topic Kafka Brique 1 Topic Kafka Brique 2 Topic Kafka ...
16. Collecte événements Kafka Brique 1 Brique 2 ... Brique 3 Brique 4
17. Concepts
18. LinkedIn engineering Opensourcé en 2011 chez Apache
19. Nom « académique » : Commit log distributed over several systems in a cluster
20. Broker de messages
21. Topics
22. Topic producer
23. Topic consumer
24. Un topic est partitionné
25. Message = clé + valeur Clé optionnelle
26. Un message consommé n'est pas effacé
27. Conservation des messages dans des fichiers de « logs » par topic & partition
28. Purge par expiration et/ou taille maximale et/ou par compaction basée sur la clé
29. message == byte[] serializer encode et deseralizer décode
30. Format des messages libre : string json byte[] avro ...
31. Le broker ne « connaît » pas les consumers
32. Ce n'est pas le broker qui push Le consumer pull
33. Pas d'acknowledge/commit/rollback du consumer
34. Un consumer maintient ses offsets de consommation
36. Offset : séquence index ordonné
38. Il suffit donc de reculer les offsets pour faire du replay Relire un message en particulier via son offset
39. Consumer group identiques => queue
40. Consumer group différents => topic (publish suscribe)
41. Delivery : at least one (messages jamais perdu mais peuvent être redélivrés)
42. Chaque message a une clé Peut être null
43. Le producer route les messages vers les partitions
44. Si la clé est null, routage aléatoire Sinon hash(key) % nb partitions
45. Partitioner custom possible
46. Conservation de l'ordre par partition
47. Possibilité de consommer en parallèle par partition pour les performances tout en gardant une notion d'ordre entre les messages
48. Mais pas inter partition
50. Consumer lag = retard
52. Architecture
53. Écrit en Scala Tourne sur une simple JVM
54. Architecture globale Zookeeper Zookeeper Zookeeper
55. Topics partitionnés Les partitions sont répliquées
56. Un leader et N réplicas Répartis sur les brokers du cluster
57. Un des nœuds est élu controler Responsable de la répartition des leaders
59. Partition = unité de parallélisme + partitions => + throughput en production & consommation => scalabilité
60. Mais aussi => + ressources système + de temps pour bascule leaders en failover + de latence si ack asynchrone + de mémoire côté client
61. Réplication synchrone tout leader n Réplication asynchrone
62. Replica : Jamais lu ni écrit par un consumer ou un producer Uniquement pour la tolérance aux pannes
63. Un topic avec une réplication de N tolère la perte de N-1 serveurs (min.isr = 1)
64. Le consumer commite ses offsets dans un topic Kafka dédié (Zookeeper avant)
65. Topic Kafka avec compaction A la lecture, on ne garde que la dernière version par clé Utile pour faire de l'event sourcing
66. Compression par le producer Décompression par le consumer transparente
67. Nativement et toujours persistant sur filesystem byte[] stocké directement sur fs sans transformation
68. Écrit mais pas flushé fsync sur intervalle max et/ou nombre de messages max
69. Mais alors pas ultra safe … Si réplica, ack ...
70. write : écritures disques séquentielles read : OS cache, API sendfile (zero copy) Avec une consommation == production, quasiment pas d'activité en lecture disque, tout depuis le cache OS
73. Client Java natif Clients scala, node.js, .NET, clojure, go, python, ruby, php, erlang, c/c++
74. Proxy REST Interface simple Performance moindre Pour les autres langages ou si le client n'est pas à jour
75. Architecture Moteur de règles Topic Kafka Ingestion événements Executor Hadoop Storm Topic Kafka HBase Topic Kafka Moteur de règles Topic Kafka
76. @LinkedIn : A modern stream-centric data architecture built around Apache Kafka
77. Les deux approches sont combinables : temps réel et batch en relisant tout ou partie
78. Dans les distributions Hadoop Cloudera et Hortonworks
79. Flume avec Flafka Source & sink Implémentation de channel
80. Kafka -> Hadoop via Camus ou Kangaroo
81. Agrégation de logs Appender logback, log4j2, ... Logstash à partir 1.5
82. Framework stream processing : Storm Spark streaming Samza
83. Métriques
84. Sur un PC portable (sans SSD), 1 producer multithreadé, 1 consumer, pas de réplication : 20 000 messages/s en production synchrone 330 000 messages/s en production asynchrone 200 000 messages/s en consommation < 2 ms en latence
85. Kafka@LinkedIn 300 brokers 18 000 topics & 140 000 partitions 220 milliards messages/j 40 Tbits/j in & 160 Tbits/j out
86. 1 cluster @LinkedIn 15 brokers 15 000 partitions réplication *2 400 000 messages/s 70 MB/s in & 400 MB/s out
87. Benchmark 3 serveurs Intel Xeon 2.5 GHz 6 core 7200 RPM SATA drives 32GB of RAM 1Gb Ethernet 1 topic & 6 partitions
88. Producer 1 thread, no réplication => 820 000/s (78 MB/s) 1 thread, 3* réplication asynchrone => 780 000/s (75 MB/s) 1 thread, 3* réplication synchrone => 420 000/s (40 MB/s) 3 producers, 3 serveurs, 3* réplication asynchrone => 2 000 000/s (190 MB/s)
89. Danger des brokers OK tant que ça tient en mémoire Performances KO quand les messages ne sont pas consommés assez vite et qu'ils doivent être écrits/paginés sur disque
90. Terrible car c'est justement le but d'un broker que d'absorber du lag
91. Kafka
92. Consumer 1 consumer (1 seul thread), début du topic (donc pas dans le cache de l'OS) => 940 000/s (90 MB/s) 3 consumers, 3 serveurs => 2 600 000/s (250 MB/s)
93. Latence 2 ms (median) 3 ms (99th percentile) 14 ms (99.9th percentile)
94. Producer & consumer 1 producer, 3* réplication asynchrone 1 consumer => 795 000/s (75 MB/s) Quasi identique au cas du producer seul La consommation est efficace et peu impactante
95. Retour d'expérience
96. Pas un remplaçant instantané de JMS Pas d'acquittement, de request/reply, de sélecteur, de XA
97. Absorption de pics de charge sereinement
98. Très performant
99. Utilisé depuis longtemps chez LinkedIn sous forte charge
100. Très stable
101. Bonne documentation Communauté assez active
102. Confluent Support entreprise possible
103. Une release par an Release sur patch important rapide
104. Montée en compétences relativement rapide
105. Packaging tar.gz RPM avec les distributions Hadoop ou parcel docker
106. CLI ligne de commande simple création, modification, suppression de topics
107. kafka-topics.bat --zookeeper localhost:2181 --create --topic topic-test --partitions 4 --replication-factor 1 kafka-topics.bat --zookeeper localhost:2181 --list kafka-topics.bat --zookeeper localhost:2181 --describe --topic topic-test
108. API de production super simple
109. Contention sur le producer en multithread en 0.8.1 => Un producer par thread
110. Option : utiliser la production asynchrone mais gestion des retry nécessaire
111. Option : envoi par batch (liste de messages en un appel réseau)
112. Producer 0.8.2 asynchrone par défaut Synchrone en attendant les Future Callback possible
113. Exemple production synchrone 0.8.2
114. APIs de consommation : High level consumer Low level (simple) consumer
115. High level API plus compliqué que l'API de production (rewrite en cours pour la 0.9)
116. Le commit est automatique sur délai Commit « manuel » possible pour plus de contrôle
117. Exemple consommation v0.8.1
118. Simple API n'a rien de simple mais offre plus de contrôle Vraiment très très bas niveau
119. API consumer 0.9 en cours
120. n threads de consommation == n partitions + de threads => threads consomment pas (intéressant pour le HA) - de threads => threads consomment plusieurs partitions
121. 8 partitions par topic Un peu sur partitionné pour la volumétrie actuelle (recommandations)
122. API changeante Compatibilité entre 0.7 et 0.8 KO
123. Commencer petit
124. 3 nœuds en production 2 replicas producer avec ack du leader et du réplica
125. Curseur latence et durabilité
126. flush toutes les secondes & tous les 10 000 messages
127. Taille de fetch > taille du plus gros message
128. Cluster Zookeeper nécessaire Élection de leader robuste
129. Zookeeper n'est pas fait pour des fortes charges en écriture
130. Commit des offsets à batcher dans Zookeeper
131. Manque d'unité entre Kafka et Zookeeper
132. Avec le stockage des offsets dans Kafka en 0.8.2, possibilité de diminuer drastiquement l'intervalle de commit
133. Principalement stream Replay pour un scénario de HA Consommation batch export Hadoop
134. Des messages avec une même clé sont routés dans la même partition Traitement dans un ordre précis
135. Si pas de clé métier et pas notion d'ordre, clé == null Routage aléatoire avec sticky entre 2 refresh Corrigé en 0.8.2
136. Veiller à une bonne répartition des messages par partition
137. Répartition automatique des leaders par broker marche bien
138. Serializer custom Utilisé pour plugger élégamment un mécanisme de sérialisation custom
139. Asséchement avant livraison (lag des consumers == 0)
140. Ecrit en Scala … lisible
141. Dépendance sur Scala peut entrer en conflit avec d'autres briques en Scala dans des versions différentes non compatibles
142. Dépendances Maven à assembler
143. Pas évident sous Windows en 0.8.1 OK en 0.8.2
144. Breakpoint en debug pas simple car les timeouts Zookeeper sautent (breakpoint type thread possible)
145. EmbeddedKafkaServer à écrire pour les tests unitaires/intégration Pas très compliqué Projet GitHub en cours
146. Facile de simuler un cluster localement en démarrant plusieurs brokers localement
147. Robustesse approuvée
148. Empreinte mémoire et CPU légère même en charge
149. En cas de perte d'un broker pour une longue période, script de réassignation de partitions à passer Travaux en cours 0.8.3
150. Pas encore de rack awareness Netflix y travaille
151. Settings par défaut + quelques paramètres recommandés Durée rétention, min isr, réplication, … importants
152. 20j de rétention le temps de pouvoir analyser sereinement un bug si nécessaire
153. Tolérant aux partitions réseaux dans certaines limites en 0.8.1 (voir Jepsen)
154. Paramétrage 0.8.2 pour éviter des « unclean » élections & min.isr
155. Script de démarrage de base service /etc/init.d à écrire Bientôt plus simple avec SystemD
156. Installation facilement automatisable Paramétrage simple
157. Logs corrects Log beaucoup en cas de failover Certains restent cryptiques
158. Doublon possible : rebalancing retry du producer
159. Ceinture & bretelle via idempotence (utilisé pour d'autres objectifs dans l'architecture)
160. Idempotent producer en réflexion
161. Pas d'IHM Pas indispensable mais pratique
162. Quelques contributions Certaines indéployables (rubygem, …) D'autres incomplètes (manque le lag)
164. Monitoring JMX complet et complexe Pas d’agrégation niveau cluster
165. Quelques scripts à écrire/assembler pour avoir une vision consolidée des topics et offsets
166. Sécurité Pas le focus du design originel Discussions sur le wiki (SSL, encryption, ...)
167. On a bien sûr pas tout vu mais l'essentiel
168. Conclusion
169. Complexité limitée Un peu « roots » Encore quelques défauts de jeunesse (API,ops) … surmontables Très performant Scalable Sûr
170. Questions ?
171. Merci
172. http://kafka.apache.org http://fr.slideshare.net/dave_revell/nearrealtime-analytics-with-kafka-and- hbase http://fr.slideshare.net/edwardcapriolo/apache-kafka-demo http://aphyr.com/tags/jepsen http://www.michael-noll.com http://fr.slideshare.net/Hadoop_Summit/building-a-realtime-data-pipeline- apache-kafka-at-linkedin http://www.ibm.com/developerworks/library/j-zerocopy/ http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2- million-writes-second-three-cheap-machines http://fr.slideshare.net/carolineboison/apache-kafka-40973171 http://blog.confluent.io Sources