Haute Disponibilité avec Apache Cassandra

Haute Disponibilité avec Apache Cassandra

Dec 2025

Déploiement d'un cluster Cassandra sous Docker pour analyser des ventes de jeux vidéo, tester la haute disponibilité et maîtriser la modélisation query-first.

#NoSQL #Apache Cassandra #Python #Docker #Architecture Distribuée #Data Engineering

Contexte et Objectifs : Découverte du NoSQL Distribué

Dans le cadre de mon apprentissage du domaine de la data, je voulais tester et mettre en œuvre une base de données NoSQL distribuée. Mon choix s’est porté sur Apache Cassandra. Pour rester dans un contexte métier concret et avoir un volume de données intéressant à manipuler, j’ai décidé d’analyser un jeu de données relatif aux ventes mondiales de jeux vidéo. Mon objectif était :

  • Comprendre comment Cassandra assure la haute disponibilité (High Availability) d’un cluster
  • Observer en temps réel la réaction des nœuds en cas de défaillance en production
  • Réaliser le transfert et la migration des données via des scripts Python Code Python pour la migration

Architecture et Modélisation “Query-First”

Pour simuler un environnement de production, j’ai configuré mon infrastructure via Docker de telle sorte que j’ai trois nœuds Cassandra distincts, tous connectés sur le même réseau virtuel. Docker Compose m’a permis de gérer facilement le déploiement et la configuration de ces nœuds Configuration Docker. Dans un premier temps, j’ai créé une table brute dans laquelle j’ai chargé l’intégralité du dataset.

Ensuite, je me suis heurté à la philosophie propre à Cassandra. Contrairement au SQL traditionnel, Cassandra ne supporte pas les jointures. On travaille sur le principe du Query-First : on modélise la base de données non pas selon les relations entre les entités, mais strictement en fonction des requêtes et des besoins métiers finaux.

J’ai donc créé des tables spécifiques pour répondre à des requêtes précises (top 10 des jeux les plus vendus par année, ventes par éditeur, etc.). C’est ici qu’intervient une logique très particulière à Cassandra : la distinction au sein de la clé primaire entre la clé de partition et la clé de clustering.

  • La clé de partition (Partition Key) : C’est elle qui détermine sur quel nœud physique du cluster la donnée va être stockée. Elle garantit la distribution des données.
  • La clé de clustering (Clustering Key) : Une fois la donnée stockée sur le bon nœud, cette clé détermine l’ordre de tri des données à l’intérieur de cette partition.

Voici comment j’ai structuré mes tables orientées requêtes pour ce projet :

TablePartition KeyClustering KeyObjectif métier
games_by_yearannéeglobal_salesTop 10 des ventes par année
sales_by_platformplateformenomCatalogue de jeux par console
sales_by_publisheréditeurannéeChronologie des ventes d’un éditeur
games_by_genre_year(année, genre)nomAnalyse des tendances genre-année
genres_by_platformplateformegenre, nomCatalogue détaillé par console

Défi Technique : Incompatibilité Python 3.12

Lors du développement de mes scripts d’ingestion, j’ai rencontré un problème bloquant : une incompatibilité entre Python 3.12 et le driver Cassandra. Le module asyncore a été supprimé des récentes versions de Python, ce qui faisait crasher la connexion au cluster. Pour contourner ce problème, j’ai dû installer le paquet externe pyasyncore et ajouter un “shim” (un bout de code de compatibilité) tout en haut de mon script Python : sys.modules["asyncore"] = pyasyncore. Cela a permis de restaurer la compatibilité et de lancer l’ingestion des données sans modifier le code source du driver.

Comment j’ai du gérer un problème de consommation exesive de RAM par mes trois nœuds Cassandra

Apache Cassandra est conçu en java, et il est très gourmand en ressources, notamment en RAM. Par défaut, Cassandra alloue une grande partie de la mémoire disponible pour optimiser les performances. Cependant, dans un environnement de développement ou de test avec des ressources limitées, cela peut rapidement devenir problématique. Pour contourner ce problème, j’ai dû ajuster la configuration de chaque nœud pour limiter la consommation de RAM. dans mon fichier docker-compose.yml, j’ai ajouté les variables d’environnement suivantes pour chaque nœud :

# Mode économie de RAM
 - MAX_HEAP_SIZE=512M
 - HEAP_NEWSIZE=100M

Configuration Docker

Tests de Haute Disponibilité et Niveaux de Cohérence

Une fois les données chargées, j’ai pu tester les mécanismes de haute disponibilité, notamment la notion de réplication (le fait que la donnée soit copiée sur plusieurs nœuds) et les niveaux de cohérence (Consistency Levels).

J’ai simulé une panne matérielle en production en coupant volontairement l’un de mes trois nœuds (docker stop cassandra-node3). J’ai ensuite exécuté mes requêtes de lecture avec différents niveaux de cohérence pour voir comment le cluster réagissait :

Niveau de cohérenceStatutRemarques suite à la perte du nœud 3
ONESuccèsLa requête aboutit car la réponse d’un seul nœud actif suffit.
QUORUMSuccèsLa requête aboutit car la majorité des nœuds (2 sur 3) sont encore en ligne.
ALLÉchecLa requête échoue car ce niveau exige que toute l’infrastructure réponde. Un nœud à terre bloque tout.

Bilan et Perspectives

Travailler sur ce projet m’a permis d’assimiler des concepts d’architecture distribuée extrêmement intéressants. Comprendre intimement le rôle des clés de partition et le comportement des nœuds selon le niveau d’exigence (ONE, QUORUM, ALL) m’aidera grandement pour de futurs projets. Ce socle de connaissances est indispensable pour mettre en place des architectures de données complexes, notamment des pipelines de streaming en temps réel, où la haute disponibilité et la tolérance aux pannes sont des enjeux critiques. Je suis désormais plus à l’aise avec les bases de données NoSQL, et je compte approfondir mes connaissances sur d’autres systèmes distribués comme MongoDB ou Redis. Ce projet a été une excellente introduction à la complexité et à la puissance des architectures distribuées modernes.

Liens pertinents