Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MixIt 2015 - retour d'expérience sur Kafka

MixIt 2015 - retour d'expérience sur Kafka

Edc84722f6c279f6a3ef1584fc03acff?s=128

Vladislav Pernin

April 15, 2015
Tweet

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

  35. None
  36. Offset : séquence index ordonné

  37. None
  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

  49. None
  50. Consumer lag = retard

  51. None
  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
  58. None
  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
  71. None
  72. None
  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)
  163. None
  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