Retours sur le Cassandra Breakfast, 2ème édition

Le 18 septembre dernier s’est déroulée la seconde édition du Cassandra Breakfast dans nos locaux.

En partenariat avec DataStax, cet événement combinant petit déjeuner, atelier technique et retour d’expérience autour de Cassandra a été un succès. Les 3 speakers ont chacun effectué une présentation : Clément Lardeur (Xebia) a débuté par un workshop technique, puis Hayato Shimizu (DataStax) continua avec une présentation académique et enfin Arnaud Lemaire (Xebia) conclut la matinée par un retour d’expérience.

Les retours des participants sont très positifs :

"Le Cassandra Breakfast était d’un très bon niveau grâce à la diversité des présentations"

"Un excellent retour d’expérience et atelier technique"

"J’ai passé un très bon moment !"

Déploiement d’un cluster Cassandra sur EC2

L’objectif de cette atelier était de montrer comment bootstraper rapidement un nouveau projet Cassandra, notamment en combinant la puissance d’Amazon Web Services et de DataStax, afin de disposer rapidement d’une base de données hautement disponible, scalable, et performante en un temps record.

L’atelier a démarré par une courte présentation de 15 minutes, expliquant comment déployer et configurer un cluster Cassandra sur des instances EC2, ainsi que les manipulations à réaliser pour ajouter ou supprimer un nœud du cluster. Cette présentation est fortement inspiré de la documentation officielle fournit par DataStax :

Ensuite, s’en est suivit une démonstration de 30 minutes, où les participants ont pu voir le déploiement, en quelques clics, d’un cluster contenant 3 nœuds localisés dans la zone Europe d’AWS. Une fois le cluster démarré, nous avons effectué quelques stress tests en écriture et en lecture afin de vérifier son bon fonctionnement. Pour cela l’outil cassandra-stress disponible dans les sources du projet Apache Cassandra a été utilisée. Voici de mémoire quelques métriques tirées d’OpsCenter :

• insertion de 1M de lignes (avec 5 colonnes chacune) : ~ 6500 écritures/s;
• lecture de 1M de lignes : ~ 5000 lectures/s.

Ces chiffres bien sûr sont à titre purement indicatif, sachant que la base de données n’a subi aucun tunning particulier, et que ces tests ont été lancés directement depuis une des instances EC2, afin de ne pas être impacté par de potentielles latences réseaux, mais aussi pour ne pas surcharger la bande passante de Xebia. Si vous voulez en savoir plus sur les capacités de Cassandra et avoir un ordre d’idée du nombres d’écritures et de lectures par secondes possible selon le nombre de noeuds du cluster, alors je vous renvoie au benchmark indépendant commandité par DataStax : http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases.

Après la visualisation de la charge liés aux tests via OpsCenter, nous avons ajouté un nœud au cluster, ce qui a pris en tout et pour tout quelques minutes, et surtout n’a nécessité aucune interruption de service contrairement à certaines bases de données dont on ne citera pas le nom.

Cette atelier, bien que court, était une réelle occasion d’appréhender la puissance du NoSQL combinée à celle du Cloud. On comprends mieux pourquoi NetFlix (leader de la VOD sur Internet) utilise Cassandra et AWS en production depuis plus de 3 ans, et reverse à la communauté un certains nombre de projets "Open Source" liés à Cassandra, comme par exemple le driver Astyanax.

Retour d’expérience sur le projet Libon

La matinée s’est terminée par une présentation sur les cas d’utilisation de Cassandra sur le projet Libon d’Orange.

Libon s’articule essentiellement autour des contacts et des échanges entre l’utilisateur et ses contacts (chat, message vocal, notification d’appel, …). Cette grande quantité d’informations et les améliorations a apporter sur les performances de l’application ont lancé un grand chantier de migration des données vers Cassandra.

Lors de la présentation, nous avons pu découvrir la façon dont Libon modélise les files de discussions des utilisateurs pour qu’elles soient optimisées à la synchronisation des téléphones; mais également à l’affichage de l’application HTML5. 

L’application gère également les boites vocales et les échanges en temps réel de messages entre utilisateurs. Ces besoins impliquent qu’une migration de base de données ne doit pas nécessiter une coupure du service pendant plusieurs heures. La stratégie de migration mise en place par Libon pour le passage à Cassandra comprend 5 phases :

A part un problème sur l’utilisation des compteurs qui en cas d’erreur ont un état non défini (impossible de savoir si le compteur a finalement été incrémenté ou non), le passage à Cassandra pour Libon s’est bien passé. Ils ont cependant fait remarquer que le changement de Thrift vers CQL et le manque de mapping objet (dans la roadmap Cassandra) leur fait maintenir différents moteurs d’accès aux données.

Conclusion

En résumé, le Cassandra Breakfast était un des événements phares de la rentrée de Xebia. N’hésitez pas à suivre notre blog pour vous tenir au courant des prochaines actualités sur le sujet Cassandra !