Guide de dimensionnement des shards Elasticsearch : Équilibrer performance 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épendent de manière significative de la manière dont vous structurez la distribution de vos données — plus précisément, du dimensionnement des shards. Les shards sont les blocs de construction 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 incorrect des shards peut entraîner de graves goulots d'étranglement de performance, une surcharge opérationnelle accrue ou, inversement, des ressources sous-utilisées.

Ce guide fournit un cadre pratique pour déterminer la taille optimale des shards dans votre cluster Elasticsearch. Nous allons explorer les compromis critiques entre la performance des requêtes, le débit d'indexation, la résilience du cluster et la consommation de ressources afin de vous aider à trouver le parfait équilibre pour votre charge de travail spécifique.

Comprendre les Shards Elasticsearch

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

Shards Primaires vs. Shards 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 à travers le cluster.
Shards Répliques : Ce sont des copies des shards primaires. Ils offrent 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 les copies répliques.

L'Impact du Nombre de Shards

Le nombre total de shards (Primaire + Réplique) a un impact direct sur la surcharge du cluster. Chaque shard nécessite de la mémoire (espace heap) et des ressources CPU pour suivre son statut 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 du volume de vos données, du taux d'indexation et des modèles de requêtes. Cependant, la documentation Elasticsearch et les meilleures pratiques communautaires offrent plusieurs directives cruciales.

1. Seuil de Taille : La Taille Optimale du Shard

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

Taille Maximale Recommandée : Le consensus général et les meilleures pratiques suggèrent de maintenir les shards primaires individuels entre 10 Go et 50 Go.
Maximum Absolu : Bien que techniquement possible, dépasser 100 Go par shard est fortement déconseillé, car cela met à rude épreuve les opérations de récupération, les performances d'indexation et la stabilité du cluster.

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

2. Seuil du Nombre de Documents

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

Plage de Documents Recommandée : Visez des shards contenant entre 100 000 et 5 millions de documents.

Si vos documents sont extrêmement petits (par exemple, quelques centaines d'octets), vous pourriez atteindre la limite de taille (50 Go) avant d'atteindre la recommandation de nombre de documents. Inversement, si les documents sont très volumineux (par exemple, des blobs JSON de plusieurs mégaoctets), vous pourriez atteindre rapidement la limite de nombre de documents tout en restant sous la limite de taille.

3. Surcharge du Cluster et Nombre de Shards

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

Shard par Go de Heap : Une ligne directrice courante suggère de maintenir le nombre total de shards (primaire + répliques) de sorte que le cluster utilise environ 20 shards par 1 Go d'espace heap alloué aux nœuds de données.

Exemple de Calcul : Si vos nœuds de données disposent de 30 Go de heap alloués :

$$30 \text{ Go} \times 20 \text{ shards/Go} = 600 \text{ shards au total}$$

Si vous avez besoin de 100 shards primaires pour un index, vous devez vous assurer que le cluster dispose de suffisamment de nœuds pour maintenir la surcharge totale gérable selon ce ratio.

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 de données attendue.

Étape 1 : Estimer la Taille Totale de l'Index

Déterminez la quantité totale de données que vous prévoyez que cet index stockera au cours de 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 à l'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 en matière 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 (soit 104 shards au total).

Étape 5 : Distribuer sur les Nœuds

Assurez-vous que votre cluster dispose de suffisamment de nœuds (et d'un espace heap suffisant) pour héberger ces shards efficacement, tout en maintenant la règle de 20 shards/Go de heap.

Gestion du Cycle de Vie de l'Index et Redimensionnement

Elasticsearch ne prend pas en charge le redimensionnement du nombre de shards primaires sur un index existant et non vide. C'est une limitation critique à retenir lors de la conception initiale.

Le Rôle de la Gestion du Cycle de Vie des Index (ILM)

Pour les données de séries chronologiques (logs, métriques), la meilleure pratique consiste à tirer parti de la Gestion du Cycle de Vie des Index (ILM) et de la fonctionnalité Rollover.

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

Phase Chaude (Hot Phase) : Les données sont écrites dans l'index actif actuel. ILM surveille cet index en fonction de sa taille ou de son â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 autre phase (Tiède/Froid).

Cette approche vous permet de maintenir des shards de taille cohérente et de performance optimale 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 modèles 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 shard 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 qu'ils pointent vers le nouvel index.
Supprimez l'ancien index.

Avertissement sur le Re-indexage : Le re-indexage 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	Maintenir les shards primaires entre 10 Go et 50 Go (max 100 Go).
Nombre de Documents	Viser 100k à 5M de documents par shard (secondaire par rapport à la taille).
Surcharge du Cluster	Limiter le nombre total de shards (primaire + réplique) à environ 20 shards par 1 Go de heap sur les nœuds de données.
Gestion des Index	Utiliser la Gestion du Cycle de Vie des Index (ILM) et le Rollover pour les données de séries chronologiques afin d'assurer un dimensionnement optimal continu.
Redimensionnement	N'essayez pas de modifier le nombre de shards primaires sur des index actifs ; utilisez l'API Reindex pour migrer les données vers un nouvel index correctement dimensionné.

En respectant ces directives de taille et en utilisant ILM pour une gestion continue, vous pouvez garantir que votre cluster Elasticsearch reste performant, évolutif et résilient face aux défaillances opérationnelles.