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

Human Talks Lyon Kafka 12/11/2013

Human Talks Lyon Kafka 12/11/2013

Petite présentation et retour d'expérience sur Apache Kafka, un broker distribué, persistant, scalable et performant

Edc84722f6c279f6a3ef1584fc03acff?s=128

Vladislav Pernin

November 12, 2013
Tweet

Transcript

  1. Human Talks Lyon 12/11/2013 Retour d'expérience sur Kafka Vladislav Pernin

    @vladislavpernin
  2. Un broker distribué, persistant, scalable et performant Retour d'expérience

  3. Cas d'usage / contexte Concepts Retour d'expérience

  4. Cas d'usage / contexte

  5. Projet en cours

  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/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. Scalabilité horizontale Kafka 1 Kafka 2 Kafka n

  12. Alternative : JMS API, pas un protocole Clustering difficile Performance

    en mode persistant limitée Scale pas
  13. Alternative : AMQP Exemple : RabbitMQ Bon produit Performance en

    mode persistant meilleure que JMS mais < 6000/s Scale pas
  14. Linkedin engineering Opensourcé en 2011 chez Apache

  15. En production sur des clusters avec des volumétries énormes (28

    billions/j,300 000/s,1000 clients)
  16. Concepts

  17. Topics

  18. Topic producer

  19. Topic consumer

  20. Écrit en Scala Tourne sur une simple JVM

  21. Architecture globale

  22. Un topic est partitionné

  23. Les partitions sont répliquées

  24. Un leader et N réplicas Répartis sur les brokers du

    cluster
  25. Nativement persistant sur filesystem

  26. read : OS cache, API sendfile write : écritures disques

    séquentielles
  27. Un message consommé n'est pas effacé

  28. Conservation des fichiers de logs de tous les messages par

    topic
  29. Purge par expiration et/ou taille maximale

  30. Le broker ne « connaît » pas les consumers

  31. Pas d'acknowledge/commit/rollback du consumer

  32. Un consumer maintient son état de consommation dans Zookeeper :

    offset
  33. Il suffit donc de reculer les offsets pour faire du

    replay
  34. Deux sémantiques possibles : - Queue - Publish / Subscribe

  35. Delivery : at least one

  36. Conservation de l'ordre par partition

  37. Un topic avec une réplication de N tolère la perte

    de N-1 serveurs
  38. Client java natif Clients .NET, clojure, go, python, ruby, php

  39. Ecosystème Hadoop friendly

  40. Framework stream processing : Storm & Samza friendly

  41. Retour d'expérience

  42. Stable

  43. API de production super simple

  44. API de consommation moins simple

  45. Contention sur le producer en multithread => Un producer par

    thread
  46. Ou utiliser la production asynchrone mais gestion des retry nécessaire

  47. Commit des offsets dans Zookeeper à batcher

  48. Ecrit en Scala

  49. Dépendance sur Scala peut entrer en conflit avec d'autres briques

    en Scala dans des versions différentes non compatibles
  50. Cluster Zookeeper nécessaire Une bonne chose ...

  51. Manque d'unité entre Kafka et Zookeeper, projet de stocker les

    offsets dans Kafka
  52. Facile de simuler un cluster localement en démarrant plusieurs brokers

  53. Robustesse approuvée

  54. Doublons possibles sur perte d'un nœud

  55. Tolérant aux partitions réseaux dans certaines limites (voir Jepsen)

  56. Dépendances Maven à assembler

  57. Pas évident sous Windows

  58. Empreinte mémoire et CPU légère

  59. Script de démarrage de base /etc/init.d à écrire

  60. Installation automatisable facile Paramétrage simple

  61. Logs de qualité

  62. Pas d'IHM (Est ce nécessaire ?)

  63. Monitoring JMX complet et complexe Pas d’agrégation niveau cluster

  64. Quelques scripts à écrire/assembler pour avoir une vision consolidée des

    topics et offsets
  65. Bonne documentation Communauté assez active

  66. Utilisé depuis longtemps chez Linkedin

  67. Reste très jeune API changeante Compatibilité entre 0.7 et 0.8

    KO
  68. Montée en compétences assez rapide

  69. Quelques chiffres

  70. Sur un PC portable, 1 producer, 1 consumer 20 000

    messages/s en production synchrone 330 000 messages/s en production asynchrone 200 000 messages/s en consommation < 2 ms en latence
  71. Questions ?

  72. Merci

  73. 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/blog/2013/03/13/running-a-multi-broker-apache-kafka-cluster- on-a-single-node/ http://fr.slideshare.net/Hadoop_Summit/building-a-realtime-data-pipeline-apache-kafka-at- linkedin Sources des

    schémas