Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Mise à l'échelle de la capacité dans un cluster de bases de données Neptune sans serveur
La configuration d'un cluster de bases de données Neptune sans serveur est similaire à la configuration d'un cluster standard provisionné, avec une configuration supplémentaire pour les unités minimales et maximales correspondant à la mise à l'échelle, et avec le type d'instance défini sur db.serverless. La configuration de dimensionnement est définie dans les unités de capacité Neptune (NCUs), dont chacune comprend 2 GiB (gibioctet) de mémoire () ainsi que la capacité du processeur virtuel (vRAM) et le réseau associés. CPU Il est défini en tant que partie d'un ServerlessV2ScalingConfiguration objet, représenté JSON comme suit :
"ServerlessV2ScalingConfiguration": { "MinCapacity":(minimum NCUs, a floating-point number such as 1.0), "MaxCapacity":(maximum NCUs, a floating-point number such as 128.0)}
À tout moment, chaque instance d'enregistreur ou de lecteur Neptune possède une capacité mesurée par un nombre à virgule flottante qui représente le nombre d'instances NCUs actuellement utilisées par cette instance. Vous pouvez utiliser la CloudWatch ServerlessDatabaseCapacitymétrique au niveau de l'instance pour savoir combien NCUs une instance de base de données donnée utilise actuellement, et la NCUUtilizationmétrique pour connaître le pourcentage de sa capacité maximale utilisée par l'instance. Ces deux métriques sont également disponibles au niveau d'un cluster de bases de données pour indiquer l'utilisation moyenne de ses ressources dans son ensemble.
Lorsque vous créez un cluster de base de données Neptune Serverless, vous définissez le nombre minimum et maximum d'unités de capacité Neptune (NCUs) pour toutes les instances sans serveur.
La NCU valeur minimale que vous spécifiez définit la plus petite taille à laquelle une instance sans serveur de votre cluster de base de données peut être réduite. De même, la NCU valeur maximale définit la taille maximale à laquelle une instance sans serveur peut atteindre une croissance. La NCU valeur maximale maximale que vous pouvez définir est de 128,0 NCUs et la valeur minimale la plus basse est de 1,0. NCUs
Neptune suit en permanence la charge de chaque instance Neptune Serverless en surveillant son utilisation des ressources telles que CPU la mémoire et le réseau. La charge est générée par les opérations de base de données de votre application, par le traitement en arrière-plan pour le serveur et par d'autres tâches administratives.
Lorsque la charge d'une instance sans serveur atteint la limite de capacité actuelle ou lorsque Neptune détecte d'autres problèmes de performance, la capacité de l'instance augmente automatiquement. Lorsque la charge de l'instance diminue, la capacité diminue pour atteindre les unités de capacité minimale configurées, la CPU capacité étant libérée avant la mémoire. Cette architecture permet de libérer les ressources de manière progressive et contrôlée et de gérer efficacement les fluctuations de la demande.
Vous pouvez faire en sorte qu'une instance de lecteur soit mise à l'échelle en même temps que l'instance d'enregistreur ou indépendamment en définissant son niveau de promotion. Les instances de lecteur des niveaux de promotion 0 et 1 sont mis à l'échelle en même temps que l'enregistreur. Cela assure un dimensionnement correct de la capacité permettant de prendre en charge la charge de travail de l'enregistreur rapidement en cas de basculement. Les lecteurs des niveaux de promotion 2 à 15 sont mis à l'échelle indépendamment de l'instance d'enregistreur et indépendamment des autres lecteurs.
Si vous avez créé votre cluster de base de données Neptune en tant que cluster multi-AZ pour garantir une haute disponibilité, Neptune Serverless adapte l'ensemble des instances à la AZs hausse ou à la baisse en fonction de la charge de votre base de données. Vous pouvez définir le niveau de promotion d'une instance de lecteur dans une zone de disponibilité secondaire sur 0 ou 1 afin que sa capacité augmente ou diminue en fonction de la capacité de l'instance d'enregistreur dans la zone de disponibilité principale et afin qu'elle puisse prendre en charge la charge de travail actuelle à tout moment.
Note
Le stockage d'un cluster de base de données Neptune consiste en six copies de toutes vos données, réparties sur troisAZs, que vous ayez créé le cluster en tant que cluster multi-AZ ou non. La réplication du stockage est gérée par le sous-système de stockage et n'est pas concernée par Neptune sans serveur.
Choix d'une valeur de capacité minimale pour un cluster de bases de données Neptune sans serveur
La plus petite valeur que vous pouvez définir pour la capacité minimale est 1.0NCUs.
Veillez à ne pas définir une valeur minimale inférieure à ce dont votre application a besoin pour fonctionner efficacement. Une valeur trop faible peut entraîner un taux d'expiration plus élevé pour certaines charges de travail gourmandes en mémoire.
En définissant une valeur minimale aussi basse que possible, vous réalisez des écononomies, car le cluster utilisera un minimum de ressources lorsque la demande sera faible. Toutefois, si votre charge de travail a tendance à fluctuer considérablement, en passant d'une capacité très faible à très élevée, vous pouvez fixer le minimum à un niveau plus élevé afin de pouvoir augmenter la capacité des instances Neptune sans serveur plus rapidement.
Cela est dû au fait que Neptune choisit les incréments de mise à l'échelle en fonction de la capacité actuelle. Si la capacité actuelle est faible, Neptune augmente lentement la capacité dans un premier temps. Si la capacité minimale est plus élevée, Neptune commence par un incrément de mise à l'échelle plus grand et peut donc augmenter plus rapidement la capacité pour faire face à une augmentation soudaine et importante de la charge de travail.
Choix d'une valeur de capacité maximale pour un cluster de bases de données Neptune sans serveur
La plus grande valeur que vous pouvez définir pour la capacité maximale est 128.0NCUs, et la plus petite valeur que vous pouvez définir pour la capacité maximale est 2.5NCUs. Quelle que soit la valeur de capacité maximale que vous définissez, elle doit être au moins aussi élevée que la valeur de capacité minimale que vous avez spécifiée.
En règle générale, définissez une valeur maximale suffisamment élevée pour gérer les pics de charge que votre application est susceptible de rencontrer. Une valeur trop faible peut entraîner un taux d'expiration plus élevé pour certaines charges de travail gourmandes en mémoire.
Définir une valeur maximale aussi élevée que possible présente l'avantage de permettre à votre application de gérer les charges de travail les plus inattendues. L'inconvénient est qu'il devient plus difficile de prévoir et de contrôler les coûts des ressources. Une hausse inattendue de la demande peut finir par coûter beaucoup plus cher que ce que votre budget avait prévu.
L'avantage d'une valeur maximale soigneusement ciblée est qu'elle vous permet de répondre à toute augmentation soudaine de la demande tout en plafonnant les coûts de calcul Neptune.
Note
La modification de la plage de capacité d'un cluster de bases de données Neptune sans serveur modifie les valeurs par défaut de certains paramètres de configuration. Neptune peut appliquer certaines de ces nouvelles valeurs par défaut immédiatement, mais certaines modifications de paramètre dynamiques ne prennent effet qu'après un redémarrage. Un statut pending-reboot indique qu'un redémarrage est nécessaire pour appliquer certaines modifications de paramètre.
Utilisation de votre configuration existante pour estimer les besoins sans serveur
En règle générale, si vous modifiez la classe de vos instances de base de données provisionnées pour gérer une charge de travail particulièrement élevée ou faible, vous pouvez utiliser cette expérience pour effectuer une estimation approximative de la plage de capacité Neptune sans serveur équivalente.
Estimation du paramètre de capacité minimale le plus approprié
Vous pouvez appliquer ce que vous savez de votre cluster de bases de données Neptune existant pour estimer le paramètre de capacité minimale sans serveur qui fonctionnera le mieux.
Par exemple, si les besoins en mémoire de votre charge de travail provisionnée sont trop élevés pour les petites classes d'instances de base de données, telles que T3 ouT4g, choisissez un NCU paramètre minimum fournissant une mémoire comparable à une classe d'R6ginstance de base de données R5 ou.
Supposons que vous utilisiez la classe d'instances de base de données db.r6g.xlarge lorsque la charge de travail de votre cluster est faible. Cette classe d'instance de base de données dispose de 32 Go de mémoire. Vous pouvez donc spécifier un NCU paramètre minimum de 16 pour créer des instances sans serveur pouvant être réduites à peu près à la même capacité (chacune NCU correspondant à environ 2 Go de mémoire). Si l'instance db.r6g.xlarge est parfois sous-exploitée, vous pourriez même spécifier une valeur inférieure.
Si votre application fonctionne plus efficacement lorsque vos instances de base de données peuvent contenir une quantité donnée de données en mémoire ou dans le cache tampon, pensez à spécifier un NCU paramètre minimum suffisamment grand pour fournir suffisamment de mémoire à cet effet. Dans le cas contraire, les données risquent d'être expulsées du cache tampon lorsque la capacité des instances sans serveur baissera, et devront être ramenées dans le cache de la mémoire tampon au fil du temps lorsque la capacité des instances augmentera. Si la quantité d'E/S nécessaire pour ramener les données dans le cache tampon est importante, il peut être intéressant de choisir une NCU valeur minimale plus élevée.
Si vous constatez que vos instances sans serveur fonctionnent la plupart du temps à une capacité spécifique, il est judicieux de définir une capacité minimale légèrement inférieure à celle-ci. Neptune sans serveur estime efficacement dans quelle mesure et avec quelle rapidité procéder à l'augmentation d'échelle lorsque la capacité actuelle n'est pas nettement inférieure à la capacité requise.
Si vous disposez d'un cluster à configuration mixte avec un enregistreur provisionné et des lecteurs Neptune sans serveur, les lecteurs ne sont pas mis à l'échelle avec l'enregistreur. Comme ils sont mis à l'échelle de façon indépendante, leur attribuer une valeur de capacité minimale faible peut entraîner un retard de réplication excessif. Ils ne disposeront peut-être pas de la capacité suffisante pour suivre les modifications apportées par l'enregistreur lorsque la charge de travail implique un très grand nombre d'écritures. Dans ce cas, définissez une capacité minimale comparable à la capacité de l'enregistreur. Si vous constatez un retard de réplica dans les lecteurs aux niveaux de promotion 2 à 15, augmentez la valeur de capacité minimale du cluster.
Estimation du paramètre de capacité maximale le plus approprié
Vous pouvez appliquer ce que vous savez de votre cluster de bases de données Neptune existant pour estimer le paramètre de capacité maximale sans serveur qui fonctionnera le mieux.
Par exemple, supposons que vous utilisiez la classe d'instances de base de données db.r6g.4xlarge lorsque la charge de travail de votre cluster est élevée. Cette classe d'instance de base de données dispose de 128 Go de mémoire. Vous pouvez donc spécifier un NCU paramètre maximum de 64 pour configurer des instances Neptune Serverless équivalentes (chacune correspondant NCU à environ 2 Go de mémoire). Vous pouvez spécifier une valeur plus élevée pour augmenter davantage la capacité de l'instance de base de données au cas où votre instance db.r6g.4xlarge ne pourrait pas toujours gérer la charge de travail.
Si les pics inattendus de votre charge de travail sont rares, il peut être judicieux de définir une capacité maximale suffisamment élevée pour maintenir les performances des applications même pendant ces pics. D'autre part, vous souhaiterez peut-être définir une capacité maximale inférieure qui peut réduire le débit lors des pics inhabituels, tout en permettant à Neptune de gérer les charges de travail habituelles sans problème et en limitant les coûts.
