Compte-rendu de la conférence Couchbase Live London

J'ai eu l'occasion d'assister au salon Couchbase Live London du 2 avril dernier. Voici quelques notes sur les sessions qui valaient le coup.

TL;DR: Une solution à suivre de près, indéniablement.

Keynote Amadeus (Dietmar Fauser, VP)

Amadeus développe (entre autres) un système de recommendation de voyage mis à disposition des agence et moteurs de recherche de voyages (par ex : Expedia). Ce système brasse une quantité gigantesque de voyages possibles depuis/vers toute destination, à toutes les dates, et est extrêmement sensible à la qualité de l'information sur la disponibilités des places dans les vols proposés. Ils gagnent ou perdent des millions sur la seule qualité de cette information.

Au cours de l'histoire de ce système, ils ont monté une architecture de cache de plus en plus compliquée (basée sur du memcached, au-dessus d'un cluster mysql, au-dessus de la source de donnée elle-même dans Oracle). Cette architecture a été remplacée avantageusement par un cluster Couchbase.

Et ça envoie :-)  Les chiffres parlent d'eux-mêmes : 2.6M read/s, 1M write/s sur un cluster de 30 (grosses) machines

Les forces de Couchbase selon lui :

• le rebalancing online (avec 0 impact sur la perf du cluster)
• bonne tenue du cache au "coldstart" (ce qui était une des faiblesses majeures de leur archi memcached)
• coûts des opérations réduits
• très rapide : la plupart des opérations en < 0.5 ms !
• perfs prédictibles
• la fonctionnalité de "read on replica", autrement dit "dirty reads" lors d'un crash d'un noeud. C'est-à-dire aller privilégier la disponibilité sur la cohérence quand on le souhaite
• multi-threading des IO disque : très haute utilisation des disques
• la fonctionnalité de "rack awareness"

Ils pensent utiliser Couchbase pour de nouveaux use-cases :

• cache de session distribué (NDA : Amadeus a une architecture applicative distribuée en de nombreux petits services)
• stockage document (tickets de vol et autres documents de voyages, une très grosse volumétrie chez eux)

Keynote Viber (Amir Ish-Shalom, system architect)

Viber a eu une croissance strictement exponentielle, en nombre de users, de messages échangés, etc. Impressionnant. Initialement, ils avaient une architecture MongoDB avec du Redis devant. Redis, utilisé en tant que cache, ou en tant que base in-memory non durable.

Ils ont eu trop de problèmes avec MongoDB :

• mauvaises perfs sur les datasets trop gros
• ça ne scale apparamment pas très bien quand il y a beaucoup de serveurs d'application qui consomment les data (Viber a une infra Amazon)

Et du côté de Redis : ça ne supporte pas le "sharding". Ils ont pendant un temps développé leur propre "sharder" en interne, mais celui-ci avait trop de limitations.

Ils sont passé à Couchbase. Résultat sans appel : les perfs meilleures avec moitié moins de machines.

Elément d'architecture intéressant à noter : ils ont dédiés des clusters entiers à des patterns d'accès. Tel cluster majoritairement en lecture ; tel cluster lecture/écriture, etc.

Ils ont aujourd'hui 7 clusters en parallèle, le plus gros ayant 60 noeuds actifs. Ils ont également mis en oeuvre la réplication inter-datacenter.

Leurs travaux futurs : utiliser les nouveaux connecteurs, basés sur le canal de réplication cross-datacenter de Couchbase XDCR, pour déverser de la donnée dans Hadoop et dans ElasticSearch.

Ticket Master

Ticket Master est une société qui fait du ticketing de spectacles, sport, etc. Rien de bien intéressant, si ce n'est le use-case : utiliser Couchbase pour consolider une vision unique de données fréquemment dupliquée entre différents silos du SI. A garder en tête, car le multi-canal est dans l'air du temps, l'intégration de données en provenance de silos disparates est un vrai enjeu.

Concur

Concur est une société spécialisée dans la gestion des voyages et frais professionnels des employés.

Je retiens ce qui leur a fait choisir Couchbase :

• l'opérabilité : les outils de management ops, le monitoring, les mises à jour côté serveur sans downtime
• la performance

Conclusion

Couchbase commence à avoir des références vraiment solides sur l'opérabilité et la performance. Nous avons d'ailleurs eu droit à une démonstration assez convaincante des outils d'opération (la "console") sur un cluster live, avec ajout de noeud, ré-équilibrage à chaud, etc.

Dans des cas d'utilisation de type :

• cache, qu'il soit majoritairement en lecture ou lecture/écriture
• avec fortes contraintes de temps de réponse
• distribué, élastique
• plutôt clé-valeur (l'aspect document est présent mais plus jeune et moins riche qu'un MongoDB par exemple)

Alors vous devez jeter un oeil à Couchbase.