Redimensionnement de cluster en ligne

Le repartitionnement implique l'ajout de partitions ou de nœuds à votre cluster, ou leur suppression, et la redistribution des espaces clés. En conséquence, plusieurs aspects peuvent avoir un impact sur l'opération de repartitionnement, tels que la charge sur le cluster, l'utilisation de la mémoire et la taille globale des données. Pour bénéficier de la meilleure expérience possible, il est recommandé de suivre les bonnes pratiques générales relatives au cluster en vue d'une distribution uniforme des modèles de charge de travail. En outre, il est recommandé de respecter les étapes suivantes.

Avant de lancer le repartitionnement, procédez comme suit :

• Testez votre application – Testez le comportement de votre application lors du repartitionnement dans un environnement intermédiaire si possible.

• Obtenez une notification anticipée pour les problèmes de mise à l'échelle – Le repartitionnement est une opération gourmande en calculs. C'est pourquoi nous recommandons de maintenir le CPU taux d'utilisation à moins de 80 % sur les instances multicœurs et à moins de 50 % sur les instances monocœurs lors du repartage. Surveillez les métriques ElastiCache (RedisOSS) et initiez le repartage avant que votre application ne commence à détecter des problèmes de dimensionnement. Les métriques qu'il est utile de suivre sont CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections, FreeableMemory, SwapUsage et BytesUsedForCacheItems.

• Assurez-vous qu'une mémoire suffisante est disponible avant de procéder à une diminution d'échelle – Si vous procédez à une diminution d'échelle, assurez-vous que cette mémoire disponible sur les partitions à conserver est au moins égale à une fois et demi la mémoire utilisée sur les partitions que vous prévoyez de supprimer.

• Initiez le repartitionnement pendant les heures creuses – Cette pratique permet de réduire l'impact de la latence et du débit sur le client pendant l'opération de repartitionnement. Elle permet aussi d'exécuter le repartitionnement plus rapidement, car un plus grand nombre de ressources peut être utilisé pour la redistribution des emplacements.

• Vérifiez le comportement hors délai du client – Certains clients peuvent observer une latence plus élevée lors d'un redimensionnement des clusters en ligne. La configuration de votre bibliothèque client avec un délai d'expiration supérieur peut être une aide en offrant au système le temps de se connecter même en cas de conditions de charge plus importantes sur le serveur. Dans certains cas, vous pouvez ouvrir un grand nombre de connexions sur le serveur. Dans ces cas, pensez à ajouter un backoff exponentiel à la logique de reconnexion. Cela peut empêcher qu'une rafale de nouvelles connexions atteignent le serveur simultanément.

• Chargez vos fonctions sur chaque partition : lorsque vous agrandissez votre cluster, les fonctions chargées dans l'un des nœuds existants (sélectionnées au hasard) ElastiCache seront automatiquement répliquées sur le ou les nouveaux nœuds. Si votre cluster possède Valkey 7.2 ou version ultérieure, ou Redis OSS 7.0 ou version ultérieure, et que votre application utilise Functions, nous vous recommandons de charger toutes vos fonctions sur toutes les partitions avant de les redimensionner afin que votre cluster ne se retrouve pas avec des fonctions différentes sur différentes partitions.

Après le repartitionnement, notez ce qui suit :

• La diminution d'échelle peut être partiellement réussie si la mémoire sur les partitions cibles est insuffisante. Si un tel résultat se produit, vérifiez la mémoire disponible et réessayez l'opération, si nécessaire. Les données des partitions cibles ne seront pas supprimées.

• Il n'est pas procédé à la migration des emplacements ayant des éléments volumineux. En particulier, les emplacements avec des éléments supérieurs à une post-sérialisation de 256 Mo ne font pas l'objet d'une migration.

• Les commandes FLUSHALL et FLUSHDB ne sont pas prises en charge dans les scripts Lua lors d’une opération de repartitionnement. Avant Redis OSS 6, la BRPOPLPUSH commande n'est pas prise en charge si elle fonctionne sur le slot en cours de migration.