Guide des stratégies de mise à l'échelle des clusters Elasticsearch pour la croissance

Elasticsearch est devenu l'épine dorsale d'innombrables applications nécessitant des capacités de recherche en temps réel, de journalisation et d'analyse. À mesure que les volumes de données augmentent et que les charges de requêtes s'intensifient, un cluster Elasticsearch est inévitablement confronté à des défis de mise à l'échelle. Mettre à l'échelle votre cluster de manière efficace est crucial pour maintenir les performances, assurer une haute disponibilité et gérer la croissance future sans interruption de service. Ce guide explore des stratégies éprouvées pour la mise à l'échelle horizontale et verticale, ainsi que des considérations essentielles concernant le matériel et l'allocation intelligente des shards.

Comprendre comment mettre à l'échelle correctement — avant que les performances ne se dégradent — fait la différence entre un système réussi et en croissance, et un goulot d'étranglement non réactif. Nous aborderons les méthodes fondamentales pour augmenter la capacité et les meilleures pratiques architecturales nécessaires pour maintenir la robustesse de votre cluster.

Comprendre les fondamentaux de la mise à l'échelle d'Elasticsearch

La mise à l'échelle d'un cluster Elasticsearch implique principalement deux stratégies : la mise à l'échelle verticale (scaling up) et la mise à l'échelle horizontale (scaling out). La stratégie optimale implique souvent un équilibre prudent des deux, dicté par les caractéristiques de votre charge de travail.

Mise à l'échelle verticale (Scaling Up)

La mise à l'échelle verticale implique l'augmentation des ressources des nœuds existants. C'est l'approche la plus simple, mais elle atteint rapidement des limites physiques.

Quand utiliser la mise à l'échelle verticale :

Lorsque la latence est la principale préoccupation et que vous avez besoin de réponses plus rapides aux requêtes à partir du jeu de données existant.
Pour gérer des charges de pointe élevées à court terme où l'ajout d'un nouveau nœud pourrait introduire une surcharge de coordination inutile.

Mises à niveau des ressources primaires :

RAM (Mémoire) : C'est souvent la mise à niveau la plus cruciale. Elasticsearch repose fortement sur la taille du tas JVM (qui doit généralement être réglée à 50 % de la RAM totale du système, jusqu'à environ 30-32 Go). Plus de mémoire permet des caches plus grands (données de champ, caches de requêtes) et une meilleure performance de la collecte des déchets (garbage collection).
CPU : Nécessaire pour les agrégations complexes, l'indexation intensive et une forte concurrence des requêtes.
Stockage (E/S disque) : Les disques SSD ou NVMe plus rapides améliorent considérablement le débit d'indexation et la vitesse de recherche, en particulier pour les charges de travail à forte intensité d'E/S.

⚠️ Avertissement sur la mise à l'échelle verticale : En raison des limitations de la JVM, vous ne pouvez pas allouer plus d'environ 32 Go au tas pour des pointeurs d'objets ordinaires compressés (oops) optimaux. Une mise à l'échelle verticale excessive est souvent une solution temporaire.

Mise à l'échelle horizontale (Scaling Out)

La mise à l'échelle horizontale implique l'ajout de nœuds supplémentaires au cluster. Cela distribue les données et la charge de requêtes sur plus de machines, offrant une scalabilité quasi-linéaire et une haute disponibilité.

Quand utiliser la mise à l'échelle horizontale :

Lorsque le volume de données dépasse la capacité des nœuds existants.
Lorsque vous devez améliorer le débit d'indexation global ou la concurrence des requêtes.
En tant que stratégie principale pour une croissance durable à long terme.

La mise à l'échelle horizontale est réalisée en ajoutant de nouveaux nœuds de données. Des nœuds de coordination peuvent également être ajoutés, mais c'est généralement l'expansion des nœuds de données qui stimule la croissance de la capacité.

Meilleures pratiques architecturales pour la scalabilité

La mise à l'échelle est plus que la simple addition de matériel ; elle exige une topologie d'index et de nœuds bien structurée.

Rôles des nœuds et spécialisation

Les déploiements modernes d'Elasticsearch bénéficient grandement de l'attribution de rôles dédiés aux nœuds, en particulier dans les clusters plus grands. Cela prévient la contention des ressources entre les tâches lourdes (comme l'indexation) et les tâches critiques (comme la coordination des recherches).

Rôle du nœud	Responsabilité principale	Considération de meilleure pratique
Nœuds maîtres	Gestion de l'état du cluster, stabilité.	Ensemble dédié de 3 ou 5 nœuds. Ne devraient pas gérer les données ou les requêtes d'ingestion.
Nœuds de données	Stockage des données, indexation, recherche.	Mettre à l'échelle ceux-ci de manière agressive en fonction du volume de données et de la charge.
Nœuds d'ingestion	Pré-traitement des documents avant l'indexation (utilisation des pipelines d'ingestion).	Décharger le pré-traitement gourmand en CPU des nœuds de données.
Nœuds de coordination	Gestion des requêtes de recherche importantes, collecte des résultats des nœuds de données.	Ajouter ceux-ci lorsque les requêtes de recherche deviennent complexes ou surchargent fréquemment les nœuds de données avec la surcharge de coordination.

Stratégie d'allocation des shards

Les shards sont l'unité fondamentale de distribution et de parallélisme dans Elasticsearch. Une mauvaise allocation des shards est la cause principale des difficultés de mise à l'échelle.

1. Optimisation du nombre de shards primaires

Le choix du bon nombre de shards primaires (index.number_of_shards) est critique et ne peut pas être facilement modifié après la création de l'index (sauf en utilisant des alias d'index ou le réindexage).

Trop peu de shards : Limite le parallélisme lors des recherches et empêche une mise à l'échelle horizontale efficace.
Trop de shards : Entraîne une surcharge sur les nœuds maîtres, augmente inutilement l'empreinte mémoire et conduit à l'inefficacité du « problème des petits shards ».

Meilleure pratique : Visez des shards primaires d'une taille comprise entre 10 Go et 50 Go. Un bon point de départ est souvent 1 shard primaire par cœur de CPU par nœud de données, bien que cela varie considérablement selon la charge de travail.

2. Shards de réplique pour la haute disponibilité et le débit de lecture

Les shards de réplique (index.number_of_replicas) offrent une redondance et augmentent la capacité de lecture.

Définir number_of_replicas: 1 signifie que chaque shard primaire a une copie, assurant ainsi une haute disponibilité (HA).
L'augmentation des répliques (par exemple, à 2) augmente considérablement le débit de lecture en permettant aux recherches de solliciter simultanément plusieurs copies de shards.

Exemple de configuration HA :
Si vous avez 10 shards primaires et que vous définissez number_of_replicas: 1, le cluster nécessite au moins 20 copies de shards au total (10 primaires + 10 répliques) réparties entre les nœuds.

PUT /my_growing_index
{
  "settings": {
    "index.number_of_shards": 20,
    "index.number_of_replicas": 1 
  }
}

Prévention des points chauds (Hotspots) grâce à la conscience du placement

Lors de l'ajout de nouveaux nœuds, assurez-vous que les shards sont répartis uniformément dans le cluster. Elasticsearch tente de le faire automatiquement, mais vous devez vous assurer que les attributs des nœuds (comme la conscience des racks ou rack awareness) sont configurés, en particulier dans les déploiements multi-zones ou multi-centres de données.

Utilisez l'API Cluster Allocation Explainer pour diagnostiquer pourquoi les shards pourraient ne pas se déplacer vers de nouveaux nœuds ou pourquoi un nœud est surchargé.

Étapes pratiques de mise à l'échelle : Gérer la croissance

Lorsque les performances de votre cluster se dégradent (forte pression sur le tas JVM, requêtes lentes, indexation lente), suivez ces étapes dans l'ordre :

Étape 1 : Surveiller et diagnostiquer

Avant d'apporter des modifications, diagnostiquez le goulot d'étranglement. Indicateurs courants :

CPU élevé / Faible mémoire libre : Indique une sous-charge de calcul ou une famine de mémoire (nécessité potentielle d'une mise à l'échelle verticale).
Longueur excessive de la file d'attente disque : Indique un goulot d'étranglement E/S (nécessité de disques plus rapides ou d'ajout de nœuds).
Pics de latence de recherche : Souvent dus à un cache insuffisant ou à un nombre trop faible de shards/répliques (nécessite plus de mémoire ou une mise à l'échelle horizontale).

Étape 2 : Répondre aux besoins immédiats en ressources (ajustements verticaux)

Si la pression mémoire est élevée, augmentez la taille du tas JVM dans des limites sûres (max 32 Go) et assurez-vous qu'une RAM adéquate est disponible pour le cache du système de fichiers de l'OS.

Étape 3 : Mise à l'échelle horizontale (expansion horizontale)

Si vous ajoutez des nœuds, suivez cette procédure :

Provisionnez de nouveaux nœuds de données avec un matériel identique ou supérieur.
Configurez-les avec les rôles master-eligible ou data corrects.
Dirigez-les vers le cluster existant en utilisant discovery.seed_hosts.
Une fois que les nouveaux nœuds ont rejoint le cluster, Elasticsearch commencera automatiquement à rééquilibrer les shards existants pour utiliser la nouvelle capacité.

Étape 4 : Pérenniser les index (Réindexation)

Si les index existants ont un nombre de shards sous-optimal, ils ne peuvent pas utiliser pleinement les nouveaux nœuds. Vous devez les reconstruire :

Créez un nouveau modèle d'index ou utilisez l'API de création d'index avec le nombre souhaité de shards et de répliques.
Utilisez l'API Reindex pour migrer les données de l'ancien index mal dimensionné vers le nouveau.
Une fois la migration terminée, basculez le trafic en utilisant un alias.

Exemple de commande de réindexation :

POST _reindex
{
  "source": {
    "index": "old_index_bad_shards"
  },
  "dest": {
    "index": "new_index_optimized_shards"
  }
}

Résumé et liste de contrôle des meilleures pratiques

La mise à l'échelle efficace d'Elasticsearch exige une planification proactive ancrée dans la compréhension de la distribution et de la gestion des ressources. Évitez de mettre à l'échelle verticalement indéfiniment ; concentrez-vous sur la répartition de la charge horizontalement.

Points clés à retenir :

Prioriser la mise à l'échelle horizontale : Elle offre la meilleure voie pour une croissance continue et une résilience.
Nœuds maîtres dédiés : Maintenez la gestion du cluster stable en séparant les rôles de maître.
Le dimensionnement des shards est permanent : Visez une taille de shard primaire de 10 Go à 50 Go lors de la création de l'index.
Surveiller le tas JVM : Ne dépassez pas une taille de tas d'environ 30 Go par nœud.
Utiliser la réindexation : Reconstruisez les index cruciaux lorsque la mise à l'échelle horizontale nécessite une modification du nombre de shards primaires.