Guide de dimensionnement des shards Elasticsearch : équilibrer performances et évolutivité

Elasticsearch est un moteur de recherche et d'analyse distribué puissant qui excelle dans le traitement de volumes massifs de données. Cependant, atteindre des performances et une stabilité optimales dépend fortement de la manière dont vous structurez la distribution de vos données—en particulier, le dimensionnement des shards. Les shards sont les éléments fondamentaux des index Elasticsearch ; ils déterminent comment les données sont partitionnées, répliquées et distribuées sur les nœuds du cluster. Un dimensionnement inapproprié des shards peut entraîner de graves goulots d'étranglement de performance, une augmentation de la charge opérationnelle ou, à l'inverse, une sous-utilisation des ressources.

Ce guide de dimensionnement des shards Elasticsearch vous offre une méthode pratique pour choisir un nombre initial de shards et le valider avec des métriques de charge réelles. L'objectif n'est pas un nombre parfait ; c'est une disposition de shards qui reste récupérable, interrogeable et abordable à mesure que vos données croissent.

Comprendre les shards Elasticsearch

Avant de plonger dans le dimensionnement, il est essentiel de comprendre ce qu'est un shard et comment il fonctionne au sein de l'architecture du cluster. Un index dans Elasticsearch est composé d'un ou plusieurs shards primaires. Chaque shard primaire est un index indépendant basé sur Lucene pouvant héberger des données.

Shards primaires vs répliques

Shards primaires : Ils contiennent les données réelles. Ils sont responsables des opérations d'indexation et de recherche. Lorsque vous définissez le nombre de shards primaires pour un index, vous décidez comment les données seront distribuées horizontalement sur le cluster.
Shards répliques : Ce sont des copies des shards primaires. Ils fournissent une redondance (tolérance aux pannes) et augmentent le débit de recherche en permettant aux requêtes d'être servies à la fois par les copies primaires et répliques.

L'impact du nombre de shards

Le nombre total de shards (Primaires + Répliques) impacte directement la surcharge du cluster. Chaque shard nécessite de la mémoire (espace heap) et des ressources CPU pour suivre son état et ses métadonnées. Trop de petits shards submergent le nœud maître et augmentent la surcharge de gestion du cluster, entraînant une dégradation des performances, même si les shards individuels sont petits.

Contraintes clés et recommandations de dimensionnement

Il n'existe pas de "nombre magique" unique pour la taille des shards. La taille optimale dépend fortement de votre volume de données, de votre taux d'indexation et de vos modèles de requêtes. Cependant, la documentation Elasticsearch et les meilleures pratiques de la communauté offrent plusieurs directives cruciales.

1. Seuil de taille : la taille optimale d'un shard

Le facteur le plus critique est la taille des données contenues dans un seul shard.

Plage cible courante : De nombreux clusters de production visent des shards primaires dans la plage 10 Go à 50 Go.
Prudence avec les grands shards : Les shards plus grands peuvent fonctionner pour certaines charges de travail en append-only ou à faible requête, mais ils augmentent le temps de récupération et rendent la relocalisation plus coûteuse. Testez avant de vous fier à des shards proches ou au-dessus de 100 Go.

Pourquoi cette limite ? Si un nœud tombe en panne, Elasticsearch doit réallouer (relocaliser ou répliquer) les shards stockés sur ce nœud. Les grands shards augmentent considérablement le temps nécessaire à la récupération, ce qui accroît la fenêtre de résilience réduite. De plus, Lucene fonctionne mieux lorsqu'il gère des segments de taille moyenne.

2. Seuil de nombre de documents

Bien que la taille soit primordiale, le nombre de documents est également pertinent, surtout pour les très petits documents.

Il n'existe pas de nombre de documents sûr universel par shard. Un shard contenant des millions de petits documents de logs peut bien se comporter, tandis qu'un shard avec moins de documents volumineux et fortement analysés peut être coûteux. Suivez à la fois la taille de stockage du shard et le comportement de la charge de travail plutôt que de vous fier uniquement au nombre de documents.

3. Surcharge du cluster et nombre de shards

Limitez le nombre total de shards par nœud pour gérer efficacement la consommation des ressources.

Les anciennes directives utilisaient souvent des règles de shard par Go de heap. Traitez-les comme des signes d'alerte approximatifs, pas comme des limites strictes. Elasticsearch moderne a une surcharge de heap par shard plus faible que les anciennes versions, mais trop de shards augmentent encore le travail lié à l'état du cluster, les descripteurs de fichiers, la surcharge des segments et la complexité de la récupération.

Méthodologie pratique de dimensionnement des shards

Utilisez les étapes suivantes pour calculer le nombre approprié de shards primaires pour un nouvel index en fonction de la taille totale attendue des données.

Étape 1 : Estimer la taille totale de l'index

Déterminez la quantité totale de données que vous prévoyez de stocker dans cet index sur sa durée de vie opérationnelle (par exemple, 6 mois ou 1 an).

Exemple : Nous prévoyons de stocker 2 To de données pour notre index logs-2024.

Étape 2 : Définir la taille cible du shard

Sélectionnez une taille cible sûre basée sur les directives (par exemple, 40 Go).

Exemple : Taille cible du shard = 40 Go.

Étape 3 : Calculer les shards primaires requis

Divisez la taille totale estimée par la taille cible du shard. Arrondissez toujours au nombre entier supérieur.

$$\text{Shards primaires} = \text{Plafond} \left( \frac{\text{Taille totale de l'index}}{\text{Taille cible du shard}} \right)$$

Exemple de calcul (2 To = 2048 Go) : $$\text{Shards primaires} = \text{Plafond} \left( \frac{2048 \text{ Go}}{40 \text{ Go}} \right) = \text{Plafond}(51,2) = 52$$

Dans ce scénario, vous devez créer l'index avec 52 shards primaires.

Étape 4 : Déterminer le nombre de répliques

Décidez du nombre de répliques en fonction de vos besoins de résilience et de volume de recherche.

Résilience : Définissez number_of_replicas à au moins 1 (pour une haute disponibilité).
Performance de recherche : Si le trafic de recherche est élevé, utilisez 2 répliques ou plus.
Exemple : Nous choisissons 1 réplique pour une tolérance aux pannes standard.

Paramètres finaux de l'index : 52 shards primaires et 1 réplique (104 shards au total).

Étape 5 : Distribuer sur les nœuds

Assurez-vous que votre cluster dispose de suffisamment de nœuds, de heap, de disque et de capacité d'E/S pour héberger efficacement ces shards. Avec les répliques, Elasticsearch doit pouvoir placer chaque réplique sur un nœud différent de son primaire.

Gestion du cycle de vie des index et redimensionnement

Elasticsearch ne permet pas de modifier index.number_of_shards directement sur un index existant. Vous pouvez utiliser les workflows split, shrink ou reindex, mais chacun a des exigences et un coût opérationnel.

Le rôle de l'Index Lifecycle Management (ILM)

Pour les données de séries temporelles (logs, métriques), la meilleure pratique est d'utiliser l'Index Lifecycle Management (ILM) et la fonctionnalité Rollover.

Au lieu de créer un index massif et difficile à gérer, vous créez un alias de rollover pointant vers un modèle.

Phase chaude : Les données sont écrites dans l'index actif courant. ILM surveille cet index en fonction de la taille ou de l'âge (par exemple, rollover lorsqu'il atteint 40 Go).
Rollover : Lorsque le seuil est atteint, Elasticsearch crée automatiquement un nouvel index basé sur le modèle (avec le nombre calculé de shards primaires) et bascule l'alias pour pointer vers le nouvel index. L'ancien index passe à une phase différente (Warm/Cold).

Cette approche vous permet de maintenir des shards de taille constante et aux performances optimales tout au long du cycle de vie de vos données.

Quand le re-sharding est nécessaire (Avancé)

Si un index existant dépasse largement la recommandation de 50 Go en raison de schémas de données imprévus, vous devez utiliser l'API Reindex pour corriger la distribution des shards :

Créez un nouvel index avec la configuration de shards corrigée (optimale).
Utilisez l'API Reindex pour copier toutes les données de l'ancien index mal dimensionné vers le nouveau.
Mettez à jour les alias pour pointer vers le nouvel index.
Supprimez l'ancien index.

Avertissement sur la réindexation : La réindexation est une opération gourmande en ressources. Elle doit être planifiée pendant les périodes de faible trafic et nécessite des ressources cluster suffisantes pour gérer la charge simultanée d'indexation et de copie.

Résumé des meilleures pratiques

Domaine	Meilleure pratique / Directive
Taille individuelle du shard	Maintenez les shards primaires entre 10 Go et 50 Go (max 100 Go).
Nombre de documents	Surveillez le nombre de documents comme signal secondaire, mais validez avec les métriques de requêtes et d'indexation.
Surcharge du cluster	Gardez le nombre de shards suffisamment bas pour que la pression sur le heap, les mises à jour de l'état du cluster et la récupération restent saines.
Gestion des index	Utilisez l'Index Lifecycle Management (ILM) et le Rollover pour les données de séries temporelles afin d'assurer un dimensionnement optimal continu.
Redimensionnement	N'essayez pas de modifier le nombre de shards primaires sur des index en direct ; utilisez l'API Reindex pour migrer les données vers un nouvel index correctement dimensionné.

Commencez avec une taille cible de shard, calculez les shards primaires à partir du volume de données attendu, puis validez avec des tests de charge et des métriques de production. Pour les données de séries temporelles, le rollover ILM est généralement la manière la plus propre de maintenir des tailles de shards prévisibles sans intervention manuelle constante.