Configuration du dimensionnement sans serveur Amazon DocumentDB

Choix de la plage de capacité de dimensionnement pour un cluster sans serveur DocumentDB

Avant d'ajouter des instances sans serveur DocumentDB à un cluster Amazon DocumentDB, les paramètres du cluster doivent également être définis. ServerlessV2ScalingConfiguration

Le ServerlessV2ScalingConfiguration paramètre se compose de deux valeurs qui définissent la plage de capacité de dimensionnement sans serveur de toute instance sans serveur du cluster :

• 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.

Choix du MinCapacity paramètre pour un cluster sans serveur DocumentDB

Il est tentant de toujours choisir 0,5 pourMinCapacity. Cette valeur permet à l'instance de réduire sa capacité au minimum lorsqu'elle est complètement inactive, tout en restant active. Toutefois, selon la façon dont vous utilisez ce cluster et les autres paramètres que vous configurez, une capacité minimale différente peut être la plus efficace. Tenez compte des facteurs suivants lors du choix de la valeur minimale de capacité :

• Le taux de dimensionnement 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 atteigne rapidement une capacité très élevée, pensez à définir la capacité minimale à une valeur correspondant au taux de mise à l'échelle correspondant à 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é équivalente sans serveur de DocumentDB. Pour déterminer la taille de mémoire d'un type d'instance Amazon DocumentDB provisionné, consultez. Limites d’instance

  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 dispose de 32 GiB 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 davantage l'instance au cas où votre db.r6g.xlarge instance serait parfois sous-utilisée.

• Si votre application fonctionne de manière optimale lorsque les instances ont une certaine quantité de données dans le cache tampon, pensez à spécifier un paramètre DCU minimum dans lequel la mémoire est suffisamment grande pour contenir les données fréquemment consultées. Dans le cas contraire, certaines données sont expulsées du cache tampon lorsque les instances sans serveur réduisent leur taille de mémoire. Ensuite, lorsque les instances redimensionnent, les informations sont relues dans le cache tampon au fil du temps. Si la quantité de données I/O à remettre dans le cache 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 DocumentDB sans serveur s'exécutent la plupart du temps à une capacité particulière, pensez à spécifier un paramètre de capacité minimale inférieur à cette ligne de base, mais pas trop bas. Les instances sans serveur peuvent estimer le plus efficacement la quantité et la rapidité de mise à l'échelle 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 minimum fournissant une mémoire comparable à celle d'une instance R5 ou R6g.

• En particulier, nous recommandons le minimum suivant MinCapacity pour une utilisation avec les fonctionnalités spécifiées (ces recommandations sont sujettes à modification) :

  • Informations sur les Performances — 2 DCUs

• 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 lecteur des niveaux de promotion 2 à 15 rencontrent des problèmes de performances, envisagez d'augmenter la capacité minimale du cluster. Pour plus de détails sur la modification de l'évolutivité des instances du lecteur en fonction du rédacteur ou indépendamment, voirAffichage et modification du niveau de promotion des lecteurs sans serveur.

  Si vous avez un cluster avec des instances de lecteur sans serveur DocumentDB, les lecteurs ne s'adaptent pas à l'instance de rédacteur 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. Nous vous recommandons de définir la capacité minimale sur une valeur représentant 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 sans serveur augmente par incréments plus importants que lorsque l'instance démarre à partir d'une faible capacité. Ainsi, si vous spécifiez une capacité maximale relativement élevée et que l'instance passe le plus clair de son temps à proximité de cette capacité, envisagez d'augmenter le paramètre DCU minimum. 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 passer MinCapacity à une valeur supérieure. Pour de plus amples informations, veuillez consulter Limites des instances sans serveur Amazon DocumentDB.

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

Pour obtenir des instructions sur la façon de modifier la configuration de dimensionnement d'un cluster, consultezGestion d'Amazon DocumentDB sans serveur.

Choix du MaxCapacity paramètre pour un cluster sans serveur DocumentDB

Il est tentant de toujours choisir une valeur élevée pour le paramètre de capacité maximale sans serveur de DocumentDB. Une capacité maximale élevée permet à l'instance d'augmenter au maximum lorsqu'elle exécute une charge de travail intensive. Une valeur faible évite la possibilité de frais inattendus. Selon votre utilisation de ce cluster et des autres paramètres que vous configurez, la valeur la plus efficace peut être supérieure ou inférieure à celle à laquelle vous pensiez initialement. Tenez compte des facteurs suivants lors du choix de la valeur maximale de capacité :

• 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 DCUs et d'au plus 256 DCUs.

• Nous vous recommandons de surveiller le dimensionnement et l'utilisation des ressources de vos instances sans serveur. Si votre instance sans serveur évolue fréquemment pour atteindre sa capacité maximale et se heurte à des contraintes de ressources (par exemple lorsque la DCUUtilization métrique est de 100,0), nous vous recommandons de sélectionner 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é équivalente sans serveur de DocumentDB. Pour déterminer la taille de mémoire des instances Amazon DocumentDB provisionnées, consultez. Limites d’instance

  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 dispose de 128 GiB de mémoire. Ainsi, vous pouvez spécifier un paramètre DCU maximal de 64 pour configurer une instance sans serveur pouvant atteindre 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 de s'étendre davantage au cas où votre db.r6g.4xlarge instance ne disposerait pas de la capacité suffisante pour gérer efficacement la charge de travail.

• Si votre budget limite l'utilisation de votre base de données, 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 lecteur sans serveur pour décharger une partie de la charge de travail en lecture seule de l'instance de rédacteur, vous pouvez peut-être choisir un paramètre de capacité maximale inférieur. Vous procédez ainsi pour tenir compte du fait que chaque instance de lecteur n'a pas besoin d'être redimensionnée 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 déterminez la valeur maximale du DCU. Ces paramètres incluent ceux de Performance Insights. Assurez-vous que la valeur DCU maximale permet aux instances sans serveur d'augmenter suffisamment leur capacité 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 liés à la combinaison d'un paramètre DCU maximal faible et des fonctionnalités Amazon DocumentDB qui entraînent une surcharge de mémoire, Éviter les out-of-memory erreurs consultez (ci-dessous).

• En particulier, nous recommandons le minimum suivant MaxCapacity pour une utilisation avec les fonctionnalités spécifiées (ces recommandations sont sujettes à modification) :

  • Création d'instances sans serveur sur un cluster contenant un volume de données important : 2 DCUs (cela inclut la création d'instances sans serveur dans le cadre d'une restauration de cluster.)

• 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'instance afin d'éviter de vous retrouver bloqué par l'une de ces limites. Pour de plus amples informations, veuillez consulter Limites des instances sans serveur Amazon DocumentDB.

Pour obtenir des instructions sur la façon de modifier la configuration de dimensionnement d'un cluster, consultezGestion d'Amazon DocumentDB sans serveur.

Éviter les out-of-memory erreurs

Si l'une de vos instances sans serveur DocumentDB atteint régulièrement la limite de sa capacité maximale, Amazon DocumentDB indique cette condition en définissant l'instance sur le statut de paramètres incompatibles. Bien que le statut des paramètres de l'instance soit incompatible, certaines opérations sont bloquées. Par exemple, vous ne pouvez pas mettre à niveau la version du moteur. Pour plus d'informations sur le statut d'une instance Amazon DocumentDB, consultez Surveillance du statut d'une instance Amazon DocumentDB.

Généralement, votre instance passe dans cet état lorsqu'elle redémarre fréquemment en raison d' out-of-memoryerreurs. Amazon DocumentDB enregistre un événement lorsque ce type de redémarrage se produit. Pour consulter les événements relatifs aux ressources, voirAffichage des événements Amazon DocumentDB. L'utilisation de la mémoire peut être anormalement élevée en raison de la surcharge liée à l'activation de paramètres tels que Performance Insights. Cela peut également être dû à une charge de travail importante sur votre instance ou à la gestion des métadonnées associées à un grand nombre d'objets de schéma.

Si la pression de la mémoire diminue et que l'instance n'atteint pas souvent sa capacité maximale, Amazon DocumentDB redéfinit automatiquement le statut de l'instance pour qu'il soit de nouveau disponible.

Pour vous remettre de cet état, vous pouvez prendre tout ou partie des mesures suivantes :

• Augmentez la limite inférieure de capacité pour les instances sans serveur en modifiant la valeur minimale de l'unité de capacité DocumentDB (DCU) 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 remettre le statut sur 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 remettre le statut sur 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'utilisez pas. Si c'est le cas, vous pouvez le désactiver. Vous pouvez également ajuster les valeurs de capacité minimale et maximale du cluster à une valeur supérieure 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 dimensionnement pour un cluster sans serveur DocumentDB.

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

Pourquoi mon instance sans serveur n'est-elle pas réduite ?

Dans certains cas, DocumentDB serverless ne réduit pas sa capacité minimale, même si la base de données n'est pas chargée. Plusieurs raisons sont possibles :

• 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. Les principales fonctions sont notamment :

• Si une instance de lecteur n'est pas réduite au minimum et conserve une capacité égale ou 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 celle de l'instance d'écriture. 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 Dimensionnement 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 les clusters dotés de 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.

Si la base de données n'est toujours pas réduite à la capacité minimale configurée, arrêtez et redémarrez la base de données pour récupérer les fragments de mémoire qui ont pu s'accumuler au fil du temps. L'arrêt et le démarrage d'une base de données entraînent un temps d'arrêt, il est donc recommandé de le faire avec parcimonie.