Dans Elastic Cloud Serverless, le nombre de répliques de vos index est automatiquement ajusté en fonction de la charge de recherche, garantissant ainsi des performances optimales pour vos requêtes, sans aucune configuration manuelle. Dans cet article, nous expliquons comment les répliques sont mises à l'échelle, à quel moment le système en ajoute ou en supprime, et quelles sont les conséquences pour vos index.
La soirée commence à s'animer
Vous organisez une fête de pizza. Vous avez quelques amis qui vous aident à servir, chacun posté à différents endroits dans la pièce. Vous offrez une pizza à chaque ami, et ils commencent à distribuer des tranches aux clients affamés à leur arrivée.
Au début, tout se passe bien. Les invités arrivent au compte-gouttes, vos amis servent des parts de pizza, tout le monde est content. Mais bientôt, la nouvelle de vos pizzas au levain se répand. On n'arrête pas de sonner à la porte. Les invités affluent. Très vite, une foule se forme autour de l'un de vos amis, celui qui tient la pizza pepperoni que tout le monde semble vouloir.
Votre ami avec la pizza au pepperoni est débordé. Les clients attendent, deviennent impatients et une longue file d'attente s'est formée. Pendant ce temps, votre ami avec la pizza margherita reste debout et presque personne ne lui demande une part.
Que faire ?
Vous commandez encore deux pizzas pepperoni et vous en distribuez à d'autres amis. Maintenant, trois amis ont de la pizza pepperoni au lieu d'un seul. La foule se disperse, et, tout à coup, vous pouvez servir trois fois plus d'invités à la fois.
Certains éléments deviennent clairs à mesure que vous organisez des fêtes :
- Les pizzas n'ont pas toutes le même succès. Certaines sont très demandées, d'autres moins. Inutile de prévoir des "exemplaires" supplémentaires de celles qui sont peu appréciées. Il vous faut davantage de celles qui attirent les foules.
- Commandez d'autres pizzas avant que la file d'attente ne devienne trop longue. Si vous attendez que votre ami soit complètement dépassé et que les invités partent mécontents, vous avez attendu trop longtemps. Mieux vaut commander une pizza supplémentaire quand vous voyez une foule se former.
- Ne jetez pas les pizzas trop vite. Ce n'est pas parce que la foule autour de la pizza pepperoni s'est clairsemée pendant cinq minutes que l'affluence est terminée. Peut-être sont-ils simplement en train de se resservir à boire, ou même de discuter entre eux (est-ce que ça se fait encore ?). Prévoyez des pizzas supplémentaires. Si l'accalmie se prolonge, vous pourrez les mettre de côté.
- Vous ne pouvez distribuer autant de pizzas que vous avez d'amis qui vous aident. Si vous n'avez que quatre amis pour vous aider, dix pizzas ne changeront rien au résultat. Seules quatre peuvent être servies à la fois. Adaptez le nombre de pizzas à vos serveurs disponibles.
- Quand un ami s'en va, prenez sa pizza. Si l'un de vos amis doit partir, prenez sa pizza immédiatement. Vous ne pouvez pas laisser les pizzas sans surveillance. Donnez-la à quelqu'un d'autre, ou mettez-la de côté.
Des pizzas aux répliques
Faisons le lien avec Elasticsearch.
Dans notre analogie, les pizzas sont des répliques (copies de vos shards d'index), vos amis qui aident à servir sont des nœuds de recherche, les invités affamés sont des requêtes de recherche, et cette pizza très prisée autour de laquelle se presse la foule correspond à un index très sollicité (hot) avec une charge de recherche élevée.
Lorsque le trafic de recherche augmente sur un indice donné, nous créons des répliques supplémentaires et les distribuons sur vos nœuds de recherche. Toute réplique peut traiter n'importe quelle requête pour cet index, tout comme un ami tenant une pizza pepperoni peut en distribuer des parts. Plus de répliques signifie un débit plus élevé : trois répliques peuvent traiter trois fois plus de requêtes par seconde qu'une seule réplique.
Mesurer la faim
Avant de décider du nombre de pizzas à commander, nous devons connaître l'appétit de la foule.
Elasticsearch suit la charge de recherche pour chaque partition. Cet indicateur mesure l'activité de recherche gérée par une partition. Nous agrégeons ces données pour l'ensemble des partitions d'un index afin d'appréhender la demande de recherche totale.
Ce qui importe le plus, c'est la charge de recherche relative : quelle proportion du trafic de recherche total de votre projet est allouée à chaque index ? Si un index reçoit 60 % des recherches tandis qu'un autre n'en reçoit que 5 %, nous savons où augmenter la capacité.
Les mathématiques derrière les pizzas
Nous calculons le nombre optimal de répliques en suivant cette formule :
Où :
- L = la charge de recherche relative de l'index (entre 0 et 1).
- N = le nombre de nœuds de recherche souhaités dans votre projet.
- S = le nombre de partitions dans l'index.
- X = un seuil pour éviter les points chauds (0,5 par défaut).
Un exemple : quatre nœuds de recherche, un index avec deux shards primaires recevant 80 % du trafic de recherche :
Cet index hot obtient quatre répliques réparties sur les nœuds de recherche.
Le seuil X (0,5 par défaut) est important. Nous n'attendons pas qu'une réplique soit complètement saturée ; nous augmentons la capacité lorsqu'elle en est à la moitié. Distribuez les pizzas supplémentaires dès que vous voyez le monde arriver, et non lorsque les clients sont déjà partis.
Augmenter la capacité rapidement, la réduire lentement
Lorsque la charge de recherche augmente, nous ajoutons immédiatement des répliques. Inutile de faire attendre les utilisateurs.
Lorsque la charge de recherche diminue, nous attendons un peu avant d'agir. Nous devons observer une faible demande stable pendant environ 30 minutes avant de réduire le nombre de répliques. (Ceci afin de gérer les pics de trafic, où une période d'accalmie ne signifie pas que la charge est terminée.)
C'est important, car l'ajout d'une réplique a un coût. La nouvelle réplique copie les données et initialise ses caches avant de traiter efficacement les requêtes. Supprimer des répliques trop rapidement signifie payer constamment ce coût initial, car le trafic fluctue naturellement.
Respecter les limites de la topologie
Le nombre de répliques ne peut jamais dépasser le nombre de nœuds de recherche. Avoir plus de répliques que de nœuds n'apporte aucun avantage (vous ne pouvez servir qu'autant de pizzas que vous avez d'amis qui vous aident à en servir des parts).
Lorsque des nœuds sont retirés de votre projet, nous réduisons immédiatement le nombre de répliques en conséquence. Pas besoin d'attendre la fin du cooldown, car il ne peut y avoir de répliques non attribuées. Dès qu'un ami s'en va, nous retirons sa part.
Une vision plus globale du Serverless
Les répliques pour l'équilibrage de charge de recherche fonctionnent de pair avec d'autres systèmes d'autoscaling :
- L'autoscaling de la recherche ajuste le nombre de nœuds de recherche (combien d'amis aident).
- Les répliques pour l'équilibrage de la charge de recherche distribuent le trafic en ajustant le nombre de répliques par index (le nombre de pizzas de chaque type dont nous avons besoin).
- Le partitionnement automatique du flux de données optimise le nombre de partitions pour les écritures (comment découper chaque pizza, abordé dans l'article précédent).
Un principe de conception important : les répliques pour l'équilibrage de charge ne déclenchent pas directement l'autoscaling de la recherche. En répartissant les requêtes de recherche sur un plus grand nombre de répliques, nous pouvons augmenter l'utilisation des ressources sur l'ensemble de vos nœuds de recherche. Cette utilisation accrue active ensuite notre logique d'autoscaling existante afin d'ajouter de la capacité si nécessaire. Les répliques pour l'équilibrage de charge permettent à l'autoscaling de remplir sa fonction, en garantissant que vos nœuds de recherche sont effectivement utilisés, au lieu de voir tout le trafic se concentrer sur une seule réplique tandis que les autres nœuds restent inactifs.
Ce que cela signifie pour vous
Vous n'avez pas besoin de prédire quels index seront les plus sollicités. Vous n'avez pas besoin d'ajuster manuellement les répliques lorsque les schémas de trafic changent. Vous n'avez pas besoin de vous réveiller à 3 heures du matin parce qu'un pic de trafic a saturé votre index le plus sollicité.
Le système surveille les zones d'affluence et commande des pizzas supplémentaires pour ces zones. Les index peu sollicités ne gaspillent pas de ressources en répliques inutiles. Les index très sollicités obtiennent la capacité dont ils ont besoin. Votre budget est ainsi investi là où c'est le plus important.
Conclusion
Dans l'article sur le partitionnement automatique, nous avons veillé à ce que vos pizzas soient découpées correctement. Désormais, grâce aux répliques pour l'équilibrage de charge de recherche, nous nous assurons que vous ayez suffisamment de pizzas, entre de bonnes mains, lorsque la foule affamée arrive.
Essayez Elastic Cloud Serverless et laissez-nous nous occuper la logistique des pizzas.




