Guide des stratégies de mise à l'échelle d'un cluster Elasticsearch pour la croissance

La mise à l'échelle d'un cluster Elasticsearch devient urgente lorsque les recherches ralentissent, les files d'attente d'indexation s'accumulent ou les disques se remplissent plus vite que prévu. À mesure que les volumes de données et les charges de requêtes augmentent, vous devez savoir s'il faut ajouter des ressources aux nœuds existants, ajouter plus de nœuds, modifier la stratégie de sharding ou reconcevoir les index chauds.

Ce guide couvre la mise à l'échelle verticale et horizontale, les rôles des nœuds, le dimensionnement des shards et les étapes pratiques pour faire croître un cluster sans tâtonner.

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

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

Mise à l'échelle verticale (Scale Up)

La mise à l'échelle verticale consiste à augmenter les 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 préoccupation principale et que vous avez besoin de réponses de requêtes plus rapides à partir de l'ensemble de données existant.
Pour une pression à court terme où l'ajout et le rééquilibrage de nouveaux nœuds prendraient plus de temps que le soulagement dont vous avez besoin.

Améliorations principales des ressources :

RAM (Mémoire) : Elasticsearch a besoin du tas JVM et d'un grand cache du système de fichiers du système d'exploitation. Un point de départ courant est de définir le tas près de 50 % de la RAM système tout en restant en dessous du seuil du pointeur d'objet ordinaire compressé, souvent autour de 26-32 Go selon la JVM.
CPU : Nécessaire pour les agrégations complexes, l'indexation lourde et une forte concurrence des requêtes.
Stockage (E/S disque) : Des SSD ou des disques NVMe plus rapides améliorent considérablement le débit d'indexation et la vitesse de recherche, en particulier pour les charges de travail à E/S élevées.

Avertissement sur la mise à l'échelle verticale : De très grands tas JVM peuvent perdre les avantages du pointeur d'objet ordinaire compressé et peuvent subir des pauses de garbage collection plus longues. La RAM supplémentaire est toujours utile pour le cache du système de fichiers, mais augmenter la taille du tas n'est pas un plan de mise à l'échelle à long terme.

Mise à l'échelle horizontale (Scale Out)

La mise à l'échelle horizontale consiste à ajouter plus de nœuds au cluster. Cela distribue les données et la charge des requêtes sur plusieurs machines, offrant une évolutivité 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 global d'indexation ou la concurrence des requêtes.
Comme 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 coordinateurs peuvent également être ajoutés, mais généralement, l'expansion des nœuds de données entraîne la croissance de la capacité.

Meilleures pratiques architecturales pour l'évolutivité

La mise à l'échelle ne consiste pas seulement à ajouter du matériel ; elle nécessite une topologie d'index et de nœuds bien structurée.

Rôles des nœuds et spécialisation

Les déploiements Elasticsearch modernes bénéficient grandement de l'attribution de rôles dédiés aux nœuds, en particulier dans les grands clusters. Cela évite 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 Master	Gestion de l'état du cluster, stabilité.	Ensemble dédié de 3 ou 5 nœuds. Ne doit pas gérer les données ou les requêtes d'ingestion.
Nœuds de données	Stockage des données, indexation, recherche.	Mettez-les à l'échelle 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 (à l'aide de pipelines d'ingestion).	Déchargez le prétraitement intensif en CPU des nœuds de données.
Nœuds coordinateurs	Gestion des grandes requêtes de recherche, collecte des résultats des nœuds de données.	Ajoutez-les lorsque les requêtes de recherche deviennent complexes ou surchargent fréquemment les nœuds de données avec des frais généraux 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 numéro un des problèmes de mise à l'échelle.

1. Optimisation du nombre de shards primaires

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

Trop peu de shards : Limite le parallélisme lors des recherches et empêche une mise à l'échelle horizontale efficace.
Trop de shards : Ajoute des frais généraux à l'état du cluster, augmente l'utilisation de la mémoire et crée le problème des "petits shards" où les coûts de coordination dominent le travail utile.

Meilleure pratique : Pour de nombreuses charges de travail de séries temporelles et de journalisation, visez des tailles de shards de l'ordre de la dizaine de gigaoctets, souvent environ 10 Go à 50 Go. Traitez cela comme une plage de départ, puis testez avec votre propre taux d'indexation, fenêtre de rétention et modèle de requête.

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

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

Définir number_of_replicas: 1 signifie que chaque shard primaire a une copie, assurant la haute disponibilité (HA).
L'augmentation des réplicas peut améliorer la capacité de lecture car les recherches peuvent être servies par des copies primaires ou réplicas, mais cela augmente également l'utilisation du stockage et le travail d'indexation.

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

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

Prévenir les points chauds avec la connaissance de la topologie

Lors de l'ajout de nouveaux nœuds, assurez-vous que les shards sont répartis sur les domaines de défaillance. Elasticsearch se rééquilibre automatiquement, mais la connaissance de la zone ou du rack ne fonctionne que si vous configurez les attributs des nœuds et les paramètres de connaissance de l'allocation.

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 (pression élevée du 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é/Mémoire libre faible : Indique une famine de calcul ou de mémoire (besoin potentiel de mise à l'échelle verticale).
Longueur excessive de la file d'attente du disque : Indique un goulot d'étranglement d'E/S (besoin de disques plus rapides ou d'ajout de nœuds).
Pics de latence de recherche : Souvent dû à une mise en cache insuffisante ou à trop peu de shards/réplicas (besoin de plus de mémoire ou de 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 les limites de sécurité (max 32 Go) et assurez-vous qu'une RAM adéquate est disponible pour le cache du système de fichiers du système d'exploitation.

É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 du matériel identique ou supérieur.
Configurez-les avec les rôles corrects. Pour la croissance de la capacité, cela signifie généralement des rôles de données tels que data_hot, data_content ou data selon votre déploiement.
Pointez-les vers le cluster existant en utilisant discovery.seed_hosts.
Une fois que les nouveaux nœuds rejoignent, 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 des nombres de shards sous-optimaux, 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 Create Index avec le nombre souhaité de shards et de réplicas.
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 à l'aide d'un alias.

Exemple de commande de réindexation :

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

Liste de contrôle des meilleures pratiques

La mise à l'échelle d'Elasticsearch fonctionne mieux lorsque vous surveillez d'abord, modifiez une variable à la fois et maintenez la disposition des shards alignée sur votre modèle de croissance.

Points clés à retenir :

Priorisez la mise à l'échelle horizontale : Elle offre la meilleure voie pour une croissance continue et la résilience.
Nœuds Master dédiés : Maintenez la gestion du cluster stable en séparant les rôles de master.
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.
Surveillez le tas JVM : Maintenez le tas en dessous du seuil de pointeur compressé pour votre JVM et laissez suffisamment de RAM pour le cache du système d'exploitation.
Utilisez la réindexation : Reconstruisez les index cruciaux lorsque la mise à l'échelle horizontale nécessite une modification du nombre de shards primaires.