Human Talks Lyon Kafka 12/11/2013

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Un broker distribué, persistant, scalable et performant Retour d'expérience

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Cas d'usage / contexte

Slide 5

Slide 5 text

Projet en cours

Slide 6

Slide 6 text

Découplage entre briques logicielles Brique 1 production Kafka Brique 2 consommation

Slide 7

Slide 7 text

Robustesse Brique 1 production Kafka Brique 2 consommation

Slide 8

Slide 8 text

Persistance sur disque Pas de perte de message sur panne/arrêt

Slide 9

Slide 9 text

Absorber des vitesses de traitements différentes Brique 1 production Kafka Brique 2 consommation 6000 messages/s 5000 messages/s

Slide 10

Slide 10 text

Performance : Throughput Latence

Slide 11

Slide 11 text

Scalabilité horizontale Kafka 1 Kafka 2 Kafka n

Slide 12

Slide 12 text

Alternative : JMS API, pas un protocole Clustering difficile Performance en mode persistant limitée Scale pas

Slide 13

Slide 13 text

Alternative : AMQP Exemple : RabbitMQ Bon produit Performance en mode persistant meilleure que JMS mais < 6000/s Scale pas

Slide 14

Slide 14 text

Linkedin engineering Opensourcé en 2011 chez Apache

Slide 15

Slide 15 text

En production sur des clusters avec des volumétries énormes (28 billions/j,300 000/s,1000 clients)

Slide 16

Slide 16 text

Concepts

Slide 17

Slide 17 text

Topics

Slide 18

Slide 18 text

Topic producer

Slide 19

Slide 19 text

Topic consumer

Slide 20

Slide 20 text

Écrit en Scala Tourne sur une simple JVM

Slide 21

Slide 21 text

Architecture globale

Slide 22

Slide 22 text

Un topic est partitionné

Slide 23

Slide 23 text

Les partitions sont répliquées

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Nativement persistant sur filesystem

Slide 26

Slide 26 text

read : OS cache, API sendfile write : écritures disques séquentielles

Slide 27

Slide 27 text

Un message consommé n'est pas effacé

Slide 28

Slide 28 text

Conservation des fichiers de logs de tous les messages par topic

Slide 29

Slide 29 text

Purge par expiration et/ou taille maximale

Slide 30

Slide 30 text

Le broker ne « connaît » pas les consumers

Slide 31

Slide 31 text

Pas d'acknowledge/commit/rollback du consumer

Slide 32

Slide 32 text

Un consumer maintient son état de consommation dans Zookeeper : offset

Slide 33

Slide 33 text

Il suffit donc de reculer les offsets pour faire du replay

Slide 34

Slide 34 text

Deux sémantiques possibles : - Queue - Publish / Subscribe

Slide 35

Slide 35 text

Delivery : at least one

Slide 36

Slide 36 text

Conservation de l'ordre par partition

Slide 37

Slide 37 text

Un topic avec une réplication de N tolère la perte de N-1 serveurs

Slide 38

Slide 38 text

Client java natif Clients .NET, clojure, go, python, ruby, php

Slide 39

Slide 39 text

Ecosystème Hadoop friendly

Slide 40

Slide 40 text

Framework stream processing : Storm & Samza friendly

Slide 41

Slide 41 text

Retour d'expérience

Slide 42

Slide 42 text

Stable

Slide 43

Slide 43 text

API de production super simple

Slide 44

Slide 44 text

API de consommation moins simple

Slide 45

Slide 45 text

Contention sur le producer en multithread => Un producer par thread

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Commit des offsets dans Zookeeper à batcher

Slide 48

Slide 48 text

Ecrit en Scala

Slide 49

Slide 49 text

Dépendance sur Scala peut entrer en conflit avec d'autres briques en Scala dans des versions différentes non compatibles

Slide 50

Slide 50 text

Cluster Zookeeper nécessaire Une bonne chose ...

Slide 51

Slide 51 text

Manque d'unité entre Kafka et Zookeeper, projet de stocker les offsets dans Kafka

Slide 52

Slide 52 text

Facile de simuler un cluster localement en démarrant plusieurs brokers

Slide 53

Slide 53 text

Robustesse approuvée

Slide 54

Slide 54 text

Doublons possibles sur perte d'un nœud

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Dépendances Maven à assembler

Slide 57

Slide 57 text

Pas évident sous Windows

Slide 58

Slide 58 text

Empreinte mémoire et CPU légère

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Installation automatisable facile Paramétrage simple

Slide 61

Slide 61 text

Logs de qualité

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Quelques scripts à écrire/assembler pour avoir une vision consolidée des topics et offsets

Slide 65

Slide 65 text

Bonne documentation Communauté assez active

Slide 66

Slide 66 text

Utilisé depuis longtemps chez Linkedin

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Montée en compétences assez rapide

Slide 69

Slide 69 text

Quelques chiffres

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Questions ?

Slide 72

Slide 72 text

Merci

Slide 73

Slide 73 text

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