Configuration de mise à l'échelle sans serveur Amazon DocumentDB

MinCapacity— La capacité de mise à l'échelle minimale de toutes les instances sans serveur DocumentDB du cluster.

MaxCapacity— La capacité de mise à l'échelle maximale de toutes les instances sans serveur DocumentDB du cluster.

Le taux de mise à l'échelle d'une instance sans serveur DocumentDB dépend de sa capacité actuelle. Plus sa capacité actuelle est élevée, plus son augmentation d’échelle est rapide. Si vous avez besoin que l'instance passe rapidement à une capacité très élevée, pensez à définir la capacité minimale à une valeur dont le taux de mise à l'échelle répond à vos besoins.

Si vous modifiez généralement la classe d'instance de vos instances en prévision d'une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour faire une estimation approximative de la plage de capacité sans serveur DocumentDB équivalente. Pour déterminer la taille de la mémoire d'un type d'instance Amazon DocumentDB provisionné, consultez. Quotas d'instances

Supposons, par exemple, que vous utilisiez la classe d'db.r6g.xlargeinstance lorsque la charge de travail de votre cluster est faible. Cette classe d'instance possède 32 Go de mémoire. Ainsi, vous pouvez spécifier une valeur MinCapacity de 16 pour configurer une instance sans serveur qui peut être réduite à peu près à la même capacité. En effet, chaque DCU correspond à environ 2 GiB de mémoire. Vous pouvez spécifier une valeur légèrement inférieure pour réduire encore la taille de l'instance au cas où celle-ci db.r6g.xlarge serait parfois sous-utilisée.

Si votre application fonctionne plus efficacement lorsque les instances contiennent une certaine quantité de données dans le cache de la mémoire tampon, pensez à spécifier un paramètre DCU minimum dans lequel la mémoire est suffisamment grande pour contenir les données fréquemment utilisées. Dans le cas contraire, certaines données sont expulsées du cache tampon lorsque la taille de mémoire des instances sans serveur est réduite. Ensuite, lorsque les instances sont redimensionnées, les informations sont relues dans le cache de la mémoire tampon au fil du temps. Si la quantité de données I/O à ramener dans le cache de la mémoire tampon est importante, il peut être plus efficace de choisir une valeur DCU minimale plus élevée. Pour de plus amples informations, veuillez consulter Dimensionnement de l'instance.

Si vos instances sans serveur DocumentDB s'exécutent la plupart du temps à une capacité particulière, pensez à spécifier un paramètre de capacité minimale inférieur à cette base de référence, mais pas trop inférieur. Les instances sans serveur peuvent estimer le plus efficacement le niveau d'évolutivité et la rapidité de leur mise à niveau lorsque la capacité actuelle n'est pas nettement inférieure à la capacité requise.

Si les besoins en mémoire de votre charge de travail provisionnée sont trop élevés pour les petites classes d'instances telles que T3 ou T4g, choisissez un paramètre DCU minimal qui fournit une mémoire comparable à celle d'une instance R5 ou R6g.

Utilisez le minimum suivant MinCapacity pour les fonctionnalités spécifiées (sous réserve de modifications) :

Dans Amazon DocumentDB, la réplication s'effectue au niveau de la couche de stockage, de sorte que la capacité du lecteur n'affecte pas directement la réplication. Toutefois, pour les instances de lecteur sans serveur DocumentDB qui évoluent indépendamment, assurez-vous que la capacité minimale est suffisante pour gérer les charges de travail pendant les périodes d'écriture intensive afin d'éviter la latence des requêtes. Si les instances de lecture des niveaux de promotion 2 à 15 rencontrent des problèmes de performances, envisagez d'augmenter la capacité minimale du cluster. Pour plus d'informations sur la manière de modifier si les instances de lecteur évoluent en même temps que l'auteur ou indépendamment, consultezAfficher et modifier le niveau de promotion des lecteurs sans serveur.

Si vous disposez d'un cluster avec des instances de lecture sans serveur DocumentDB, les lecteurs ne sont pas adaptés à l'évolution de l'instance Writer lorsque le niveau de promotion des lecteurs n'est pas 0 ou 1. Dans ce cas, la définition d’une valeur minimale de capacité faible peut entraîner un retard de réplication excessif. En effet, la capacité des lecteurs peut ne pas être suffisante pour appliquer les modifications depuis l’enregistreur lorsque la base de données est occupée. Définissez la capacité minimale sur une valeur qui représente une quantité de mémoire et de processeur comparable à celle de l'instance d'écriture.

Le temps nécessaire à une instance sans serveur DocumentDB pour passer de sa capacité minimale à sa capacité maximale dépend de la différence entre ses valeurs DCU minimale et maximale. Lorsque la capacité actuelle de l'instance est importante, DocumentDB serverless évolue par incréments plus importants que lorsque l'instance démarre à partir d'une petite capacité. Ainsi, si vous spécifiez une capacité maximale relativement importante et que l'instance passe le plus clair de son temps à proximité de cette capacité, envisagez d'augmenter le paramètre DCU minimal. Ainsi, une instance inactive peut revenir à sa capacité maximale plus rapidement.

Certaines limites d'instance sont déterminées par la capacité actuelle de l'instance sans serveur, comme la limite de connexions, la limite de curseur et la limite de transactions ouvertes. Si la capacité actuelle de l'instance est faible, les limites seront également faibles en conséquence. Si ces limites posent problème lorsque votre instance sans serveur est réduite à sa MinCapacity valeur, envisagez de les augmenter MinCapacity à une valeur plus élevée. Pour de plus amples informations, veuillez consulter Limites relatives aux instances sans serveur Amazon DocumentDB.

En outre, certaines limites d'instances sont plafonnées à une valeur maximale inférieure si elles MinCapacity sont définies sur une valeur inférieure ou égale à 1,0 DCU, comme la limite des connexions actives, la limite du curseur et la limite des transactions ouvertes. Si ces limites plafonnées ne sont pas suffisantes pour votre charge de travail, utilisez une MinCapacity valeur d'au moins 1,5 DCU. Pour de plus amples informations, veuillez consulter Limites relatives aux instances sans serveur Amazon DocumentDB.

La capacité maximale doit être au moins aussi élevée que la capacité minimale. Vous pouvez définir la capacité minimale et la capacité maximale pour qu’elles soient identiques. Cependant, dans ce cas, la capacité ne fait jamais l’objet d’une augmentation ou d’une réduction d’échelle. Par conséquent, l’utilisation de valeurs identiques pour les capacités minimale et maximale n’est pas appropriée en dehors des situations de test.

La capacité maximale doit être d'au moins 1,0 DCU et d'au plus 256 DCU.

Surveillez l'évolutivité et l'utilisation des ressources de vos instances sans serveur. Si votre instance sans serveur atteint fréquemment sa capacité maximale et rencontre des contraintes de ressources (par exemple, lorsque la DCUUtilization métrique est de 100,0), sélectionnez une valeur plus élevéeMaxCapacity. Pour de plus amples informations, veuillez consulter Surveillance d'Amazon DocumentDB sans serveur.

Si vous modifiez généralement la classe d'instance de vos instances provisionnées en prévision d'une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour estimer la plage de capacité sans serveur DocumentDB équivalente. Pour déterminer la taille de la mémoire des instances Amazon DocumentDB provisionnées, consultez. Quotas d'instances

Supposons, par exemple, que vous utilisiez la classe d'db.r6g.4xlargeinstance lorsque la charge de travail de votre cluster est élevée. Cette classe d'instance possède 128 Go de mémoire. Ainsi, vous pouvez spécifier un paramètre DCU maximum de 64 pour configurer une instance sans serveur pouvant évoluer jusqu'à approximativement la même capacité. En effet, chaque DCU correspond à environ 2 GiB de mémoire. Vous pouvez spécifier une valeur légèrement plus élevée pour permettre à l'instance d'évoluer davantage au cas où votre db.r6g.4xlarge instance ne disposerait parfois pas d'une capacité suffisante pour gérer efficacement la charge de travail.

Si votre budget d'utilisation de votre base de données est limité, choisissez une valeur qui reste dans les limites de ce plafond, même si toutes vos instances sans serveur fonctionnent à leur capacité maximale en permanence. N'oubliez pas que lorsque vous avez n instances sans serveur dans votre cluster, la capacité maximale théorique sans serveur que le cluster peut consommer à tout moment est n fois le paramètre DCU maximal pour le cluster. (La quantité réelle consommée peut être inférieure, par exemple si certains lecteurs sont mis à l’échelle indépendamment de l’enregistreur.)

Si vous utilisez des instances de lecture sans serveur pour décharger une partie de la charge de travail en lecture seule de l'instance de rédaction, vous pourrez peut-être choisir un paramètre de capacité maximale inférieur. Vous faites cela pour refléter le fait que chaque instance de lecteur n'a pas besoin d'évoluer aussi haut que si le cluster ne contenait qu'une seule instance.

Supposons que vous souhaitiez vous protéger contre une utilisation excessive due à une mauvaise configuration des paramètres de base de données ou à l’inefficacité des requêtes de votre application. Dans ce cas, vous pouvez éviter une surutilisation accidentelle en choisissant une valeur maximale de capacité inférieure à la valeur absolue la plus élevée que vous pourriez définir.

Si les pics dus à l’activité réelle de l’utilisateur sont rares mais existent, vous pouvez les prendre en compte lorsque vous choisissez la valeur maximale de capacité. Si la priorité est que l’application continue de s’exécuter à des performances et une capacité de mise à l’échelle optimales, vous pouvez spécifier une valeur maximale de capacité supérieure à celle que vous constatez dans le cas d’une utilisation normale. S’il est admis que l’application s’exécute à un débit réduit pendant les pics d’activité très élevés, vous pouvez choisir une valeur maximale de capacité légèrement inférieure. Assurez-vous de choisir une valeur dont les ressources de mémoire et de processeur sont suffisantes pour maintenir l’application en cours d’exécution.

Si vous activez dans votre cluster des paramètres qui augmentent l'utilisation de la mémoire pour chaque instance, tenez compte de cette mémoire lorsque vous choisissez la valeur DCU maximale. Ces paramètres incluent ceux pour Performance Insights et les clusters mondiaux. Assurez-vous que la valeur DCU maximale permet aux instances sans serveur d'évoluer suffisamment pour gérer la charge de travail lorsque ces fonctionnalités sont utilisées. Pour plus d'informations sur la résolution des problèmes causés par la combinaison d'un paramètre DCU maximal faible et des fonctionnalités d'Amazon DocumentDB qui imposent une surcharge de mémoire, voir Éviter les erreurs de mémoire insuffisante (ci-dessous).

Utilisez le minimum suivant MaxCapacity pour les fonctionnalités spécifiées (sous réserve de modifications) :

Certaines limites d'instance sont déterminées par la capacité actuelle de l'instance, comme la limite de connexions, la limite de curseur et la limite de transactions ouvertes. Lorsque vous choisissez la MaxCapacity valeur de votre charge de travail, veillez à tenir compte de ces limites d'instances afin d'éviter d'être bloqué par l'une de ces limites. Pour de plus amples informations, veuillez consulter Limites relatives aux instances sans serveur Amazon DocumentDB.

Augmentez la limite inférieure de capacité pour les instances sans serveur en modifiant la valeur minimale de l'unité de capacité (DCU) DocumentDB pour le cluster. Cela évite les situations problématiques où une base de données inactive fait l’objet d’une réduction d’échelle jusqu’à une capacité où la mémoire est inférieure à la mémoire nécessaire pour les fonctionnalités activées dans votre cluster. Après avoir modifié les paramètres DCU du cluster, redémarrez l'instance sans serveur. Cela permet d'évaluer si Amazon DocumentDB peut rétablir le statut disponible.

Augmentez la limite supérieure de capacité pour les instances sans serveur en modifiant la valeur DCU maximale pour le cluster. Cela évite les situations problématiques où une base de données occupée ne peut pas faire l’objet d’une augmentation d’échelle jusqu’à une capacité où la mémoire est suffisante pour les fonctionnalités activées dans votre cluster et pour la charge de travail de la base de données. Après avoir modifié les paramètres DCU du cluster, redémarrez l'instance sans serveur. Cela permet d'évaluer si Amazon DocumentDB peut rétablir le statut disponible.

Désactivez les paramètres de configuration exigeant une surcharge de mémoire. Supposons, par exemple, qu'une fonctionnalité telle que Performance Insights soit activée mais que vous ne l'utilisiez pas. Si c'est le cas, vous pouvez le désactiver. Vous pouvez également augmenter les valeurs de capacité minimale et maximale du cluster pour tenir compte de la mémoire utilisée par ces types de fonctionnalités. Pour obtenir des directives sur le choix des valeurs de capacité minimale et maximale, consultez Choix de la plage de capacité de mise à l'échelle pour un cluster sans serveur DocumentDB.

Réduisez la charge de travail de l'instance. Par exemple, vous pouvez ajouter des instances de lecture au cluster pour répartir la charge des requêtes en lecture seule sur un plus grand nombre d'instances.

Performance Insights peut augmenter l'utilisation des ressources et empêcher la réduction de la capacité de la base de données au minimum. Ces fonctionnalités sont les suivantes :

Si une instance de lecteur n'est pas réduite au minimum et reste à la même capacité ou à une capacité supérieure à celle de l'instance d'écriture, vérifiez le niveau de priorité de l'instance de lecteur. Les instances de lecteur sans serveur DocumentDB de niveau 0 ou 1 sont maintenues à une capacité minimale au moins aussi élevée que l'instance Writer. Changez le niveau de priorité du processus de lecture à 2 ou plus pour qu’il augmente et diminue indépendamment du processus d’écriture. Pour de plus amples informations, veuillez consulter Mise à l'échelle sans serveur Amazon DocumentDB.

De lourdes charges de travail de base de données peuvent augmenter l’utilisation des ressources.

D’importants volumes de base de données peuvent augmenter l’utilisation des ressources. Amazon DocumentDB utilise la mémoire et les ressources du processeur pour la gestion des clusters. Amazon DocumentDB nécessite davantage de processeur et de mémoire pour gérer des clusters contenant des volumes de base de données plus importants. Si la capacité minimale de votre cluster est inférieure à la capacité minimale requise pour la gestion du cluster, votre cluster ne sera pas réduit à la capacité minimale.

Les activités de maintenance en arrière-plan peuvent augmenter périodiquement l'utilisation des ressources.