Dimensionnement Optimal des Shards : Équilibrer la Performance et la Gestion du Cluster

Taille Optimale des Shards : Équilibrer Performance du Cluster et Gestion

Elasticsearch, un moteur de recherche et d'analyse distribué puissant, repose fortement sur sa capacité à gérer et distribuer efficacement les données sur les nœuds. Un composant essentiel de cette distribution est le concept de shards (fragments). Les shards sont des morceaux plus petits et gérables de votre index, et la manière dont vous dimensionnez et les distribuez a un impact profond sur les performances, la scalabilité et la facilité de gestion de votre cluster. Cet article explore les considérations critiques pour déterminer la taille optimale des shards dans Elasticsearch, vous aidant à trouver le juste équilibre entre la performance brute et la surcharge opérationnelle.

Comprendre le dimensionnement des shards est crucial pour tout déploiement Elasticsearch. Trop de petits shards peut entraîner une surcharge accrue, impactant les ressources des nœuds et la latence des requêtes. Inversement, trop peu de grands shards peut entraver la scalabilité, créer des points chauds (hot spots) et allonger les opérations de récupération. Ce guide vous fournira les connaissances et les stratégies pratiques pour prendre des décisions éclairées concernant votre allocation de shards, menant à un cluster Elasticsearch plus efficace et robuste.

Les Fondamentaux des Shards Elasticsearch

Avant de plonger dans les stratégies de dimensionnement, il est essentiel de saisir les concepts de base :

Index : Une collection de documents. Dans Elasticsearch, un index est divisé en plusieurs shards.
Shard : Une unité de distribution. Chaque shard est un index Lucene autonome. Un index peut contenir plusieurs shards, distribués sur différents nœuds du cluster.
Shard Primaire : Lorsqu'un index est créé, il se voit attribuer un nombre fixe de shards primaires. Ces shards sont l'endroit où vos données sont indexées. Une fois créé, le nombre de shards primaires ne peut pas être modifié. Vous pouvez, cependant, ajouter plus de shards de réplique.
Shard de Réplique : Des copies de vos shards primaires. Ils offrent une redondance et augmentent le débit de lecture. Si un shard primaire tombe en panne, une réplique peut être promue pour devenir le primaire. Le nombre de shards de réplique peut être modifié à tout moment.

Comment les Shards Impactent la Performance

Performance d'Indexation : Chaque shard nécessite des ressources pour l'indexation. Plus de shards signifie plus de surcharge pour les nœuds coordinateurs qui gèrent les requêtes. Cependant, si les shards deviennent trop grands, l'indexation dans un seul shard peut devenir un goulot d'étranglement.
Performance des Requêtes : Les requêtes de recherche sont distribuées à tous les shards primaires pertinents. Un nombre plus élevé de shards peut augmenter le nombre de requêtes à traiter, augmentant potentiellement la latence. Inversement, des shards très volumineux peuvent entraîner des temps de recherche plus longs, car Lucene doit parcourir plus de données au sein de ce shard.
Gestion du Cluster : Un grand nombre de shards augmente la charge sur le nœud maître, qui est responsable de la gestion de l'état du cluster. Cela impacte également la surcharge des opérations telles que la relocalisation des shards, la sauvegarde (snapshotting) et la récupération.
Utilisation des Ressources : Chaque shard consomme de la mémoire et des E/S disque. Trop de shards peuvent épuiser les ressources des nœuds, entraînant une dégradation des performances ou une instabilité du nœud.

Considérations Clés pour le Dimensionnement des Shards

La taille « idéale » d'un shard n'est pas un nombre fixe ; elle dépend de votre charge de travail spécifique, des caractéristiques des données et du matériel. Cependant, plusieurs facteurs devraient guider vos décisions :

1. Volume de Données et Taux de Croissance

Taille Actuelle des Données : Combien de données avez-vous dans votre index actuellement ?
Taux de Croissance : À quelle vitesse vos données augmentent-elles ? Cela aide à prédire les tailles futures des shards.
Politique de Rétention des Données : Allez-vous supprimer les anciennes données ? Cela a un impact sur la taille effective des données actives.

2. Charge d'Indexation

Taux d'Indexation : Combien de documents par seconde indexez-vous ?
Taille des Documents : Quelle est la taille moyenne des documents individuels ?
Débit d'Indexation : Vos nœuds peuvent-ils gérer la charge d'indexation avec la configuration de shard actuelle ?

3. Modèles de Requêtes (Query Patterns)

Complexité des Requêtes : Vos requêtes sont-elles de simples recherches par mots-clés ou des agrégations complexes ?
Fréquence des Requêtes : À quelle fréquence les requêtes sont-elles exécutées sur vos données ?
Exigences de Latence des Requêtes : Quels sont vos temps de réponse acceptables ?

4. Topologie et Ressources du Cluster

Nombre de Nœuds : Combien de nœuds y a-t-il dans votre cluster ?
Matériel des Nœuds : CPU, RAM et disque (SSD est fortement recommandé pour Elasticsearch).
Limite de Shards par Nœud : Elasticsearch a une limite par défaut pour le nombre maximal de shards qu'un nœud peut contenir afin de prévenir les problèmes de performance. Ceci est contrôlé par cluster.routing.allocation.total_shards_per_node (la valeur par défaut est 1000). Il est conseillé de maintenir le nombre réel de shards bien en dessous de cette limite.

Meilleures Pratiques pour l'Allocation des Shards

1. Viser une Taille de Shard Cible

Bien qu'il n'y ait pas de chiffre magique, une taille de shard cible couramment recommandée se situe entre 10 Go et 50 Go. Cette plage représente souvent un bon équilibre.

Trop petit (< 10 Go) : Peut entraîner une surcharge excessive. Chaque shard a une empreinte mémoire et contribue à la charge du nœud maître. Gérer des milliers de minuscules shards devient un fardeau opérationnel important.
Trop grand (> 50 Go) : Peut causer des problèmes de performance. Les opérations de fusion de segments, de récupération et de rééquilibrage prennent plus de temps. Si un grand shard échoue, sa récupération peut prendre beaucoup de temps.

2. Considérer les Index Basés sur le Temps

Pour les données de séries temporelles (logs, métriques, événements), l'utilisation d'index basés sur le temps est une pratique standard et très efficace. Cela implique de créer de nouveaux index pour des périodes spécifiques (par exemple, journalières, hebdomadaires, mensuelles).

Exemple : Au lieu d'un seul index massif, vous pourriez avoir logs-2023.10.26, logs-2023.10.27, etc.
Avantages : Gestion des données plus facile (suppression des anciens index via la Gestion du Cycle de Vie des Index - ILM), meilleure performance car les requêtes ciblent souvent les données récentes, et tailles de shards contrôlées.

3. Implémenter la Gestion du Cycle de Vie des Index (ILM)

Les politiques ILM vous permettent d'automatiser la gestion des index en fonction de leur âge, de leur taille ou du nombre de documents. Vous pouvez définir des phases pour un index (chaud, tiède, froid, suppression) et spécifier des actions pour chaque phase, y compris la modification du nombre de répliques, la réduction de la taille des index (shrinking) ou leur suppression.

Phase Chaude (Hot) : L'index est activement écrit et interrogé. Maximiser les performances.
Phase Tiède (Warm) : L'index n'est plus écrit mais est toujours interrogé. Il peut être déplacé vers du matériel moins performant, potentiellement avec moins de répliques ou réduit en taille.
Phase Froide (Cold) : Interrogé rarement. Les données peuvent être déplacées vers un stockage moins coûteux, avec encore moins de répliques ou gelées (frozen).
Phase Suppression (Delete) : Les données ne sont plus nécessaires et sont supprimées.

4. Éviter la Sur-Fragmentation (Over-Sharding)

La sur-fragmentation se produit lorsque vous avez beaucoup trop de shards pour la taille de votre cluster et le volume de données. C'est un piège courant qui entraîne une mauvaise performance et des problèmes de gestion.

Symptômes : Utilisation élevée du CPU sur les nœuds maîtres, mises à jour lentes de l'état du cluster, temps de récupération longs et lenteur générale.
Atténuation : Planifiez votre nombre de shards primaires dès le début. Pour les index basés sur le temps, commencez avec un nombre raisonnable de shards primaires par index (par exemple, 1 ou 3). Vous pouvez toujours ajouter des répliques plus tard.

5. Ne Pas Sur-Indexer (Over-Index)

De même, évitez de créer un nombre excessif d'index lorsque ce n'est pas nécessaire. Chaque index ajoute une surcharge. Pour les données qui ne sont pas des séries temporelles pour lesquelles vous n'avez pas de mécanisme de partitionnement naturel, déterminez si un seul index avec un nombre de shards approprié est suffisant.

6. Considérer le Paramètre `number_of_shards`

Lors de la création d'un index, le paramètre number_of_shards définit le nombre de shards primaires. Ce paramètre est immuable après la création de l'index.

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // Exemple : 3 shards primaires
      "number_of_replicas": 1   // Exemple : 1 shard de réplique
    }
  }
}

Astuce : Pour les index plus petits ou ceux avec une charge d'indexation/requête très faible, un seul shard primaire peut suffire. Pour les index plus grands et plus actifs, 3 ou 5 shards primaires peuvent offrir une meilleure distribution et résilience, surtout si vous prévoyez de diviser l'index plus tard (bien que la division soit complexe).

7. Rééquilibrage et Relocalisation

Elasticsearch rééquilibre automatiquement les shards pour assurer une distribution uniforme sur les nœuds. Cependant, si les shards sont trop volumineux, ces opérations peuvent être gourmandes en ressources et lentes. Des shards plus petits et plus nombreux peuvent parfois se rééquilibrer plus rapidement, mais cela est contrecarré par la surcharge liée à la gestion d'un plus grand nombre de shards.

8. Optimisation des Performances des Requêtes

Si les performances de vos requêtes se dégradent, évaluez votre stratégie de shards. Considérez :

Nombre de Shards : Trop de shards peuvent augmenter la surcharge de coordination.
Taille des Shards : De très grands shards peuvent ralentir la fusion des segments et la recherche au sein du shard.
Conception de l'Index : Utilisez-vous des mappages et des analyseurs appropriés ?

Calcul de Votre Nombre Optimal de Shards

Il n'existe pas de formule unique, mais voici une approche courante :

Estimez votre volume total de données par index sur son cycle de vie.
Déterminez votre taille de shard cible (par exemple, 30 Go).
Calculez le nombre de shards primaires nécessaires : Volume Total de Données / Taille de Shard Cible.
Arrondissez à l'entier supérieur. Cela vous donne votre number_of_shards pour l'index.
- Exemple : Si vous prévoyez 90 Go de données et visez des shards de 30 Go, vous auriez besoin de 90GB / 30GB = 3 shards primaires.
Considérez la résilience et la distribution : Pour les index critiques, envisagez d'utiliser 3 ou 5 shards primaires pour permettre une meilleure distribution et des options de récupération, même si votre volume de données initial ne l'exige pas strictement. Le compromis est une surcharge accrue.
Commencez de manière conservatrice : Il est généralement plus facile d'ajouter des répliques que de modifier le nombre de shards primaires (ce qui nécessite généralement une réindexation ou des solutions de contournement complexes). En cas de doute, commencez avec moins de shards primaires et surveillez les performances.

Scénario Exemple : Analyse de Logs

Supposons que vous indexiez des logs d'application :

Volume de Données : Vous prévoyez 1 To de logs par mois.
Rétention des Données : Vous conservez les logs pendant 30 jours.
Taille de Shard Cible : Vous visez 20 Go.
Index Quotidiens : Vous créez des index quotidiens (logstash-AAAA.MM.JJ). Chaque index quotidien contiendra approximativement 1TB / 30 jours ≈ 33Go de données.
Shards Primaires par Index : Compte tenu de la cible de 20 Go et du volume quotidien de 33 Go, vous pourriez choisir 2 shards primaires par index (33GB / 20GB ≈ 1.65, arrondi à 2). Cela garantit que les shards individuels restent dans votre taille cible.
Répliques : Vous décidez de 1 réplique pour une haute disponibilité.
Total des Shards : Sur la période de rétention de 30 jours, vous aurez 30 index, chacun avec 2 shards primaires et 2 shards de réplique, totalisant 60 shards primaires et 60 shards de réplique actifs à un moment donné.

Cette approche maintient les shards individuels gérables et permet une suppression efficace des données en supprimant simplement les anciens index.

Conclusion

Le dimensionnement optimal des shards dans Elasticsearch est un exercice d'équilibre continu. En comprenant l'interaction entre le nombre de shards, la taille des shards, la charge d'indexation, les modèles de requêtes et les ressources du cluster, vous pouvez prendre des décisions éclairées. Privilégiez les index basés sur le temps pour les données de séries temporelles, utilisez ILM pour la gestion automatisée, et gardez toujours à l'esprit la surcharge opérationnelle liée à la gestion des shards. Viser des tailles de shard comprises entre 10 Go et 50 Go, tout en évitant la sur-fragmentation, constitue un excellent point de départ. Une surveillance régulière et un réglage fin des performances garantiront que votre cluster Elasticsearch reste efficace, évolutif et résilient à mesure que vos données augmentent.