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.
# Amazon Neptune sans serveur
Amazon Neptune sans serveur est une configuration de mise à l'échelle automatique à la demande conçue pour mettre à l'échelle la capacité de votre cluster de bases de données en fonction des besoins, afin de répondre à des augmentations même très importantes des besoins de traitement, puis de la réduire à nouveau lorsque les besoins diminuent. Il contribue à automatiser les processus de surveillance de la charge de travail et d'ajustement de la capacité de la base de données Neptune. La capacité est automatiquement ajustée en fonction des besoins de l'application, et seules les ressources consommées par votre application vous sont facturées.
## Cas d'utilisation de Neptune sans serveur
Neptune sans serveur prend en charge de nombreux types de charges de travail. Il convient aux charges de travail exigeantes et très variables et peut être très utile si l'utilisation de votre base de données est généralement intensive pendant de courtes périodes, suivies de longues périodes avec une activité légère, voire pas d'activité du tout. Neptune sans serveur est particulièrement utile pour les cas d'utilisation suivants :
+ **Charges de travail variables** : charges de travail présentant des hausses soudaines et imprévisibles de l'activité du CPU. Avec Neptune sans serveur, la capacité de votre base de données orientée graphe est automatiquement augmentée pour répondre aux besoins de la charge de travail, puis elle est réduite à nouveau lorsque le pic d'activité est terminé. Vous n'avez plus besoin de provisionner pour un pic de capacité ou une capacité moyenne. Vous pouvez spécifier une limite de capacité supérieure pour faire face aux pics d'utilisation des charges de travail. Cette capacité n'est utilisée que si elle est nécessaire.
La précision de la mise à l'échelle fournie par Neptune sans serveur vous permet de faire correspondre étroitement la capacité aux besoins de votre charge de travail. Neptune sans serveur peut ajouter ou supprimer de la capacité par paliers précis en fonction des besoins. Il peut n'ajouter que la moitié d'une [unité de capacité Neptune (NCU)](neptune-serverless-capacity-scaling.md) lorsque vous n'avez besoin que d'un peu plus de capacité.
+ **Applications mutualisées** : en tirant parti de Neptune sans serveur, vous pouvez créer un cluster de bases de données distinct pour chacune des applications que vous devez exécuter sans avoir à gérer les clusters locataires individuellement. Chacun des clusters locataires peut avoir des périodes d'activité et d'inactivité différentes en fonction de plusieurs facteurs, mais Neptune sans serveur peut les mettre à l'échelle efficacement sans votre intervention.
+ **Nouvelles applications** : lorsque vous déployez une nouvelle application, vous n'êtes souvent pas certain de la capacité de base de données dont elle aura besoin. Neptune sans serveur vous permet de configurer un cluster de bases de données capable de se mettre à l'échelle automatiquement pour répondre aux exigences de capacité des nouvelles applications au fur et à mesure de leur développement.
+ **Planification de la capacité** : supposons que vous ajustiez généralement la capacité de votre base de données (ou que vous vérifiiez la capacité de base de données optimale pour votre charge de travail) en modifiant les classes de toutes les instances de base de données d'un cluster. Avec Neptune sans serveur, vous pouvez éviter cette surcharge administrative. Au lieu de cela, vous pouvez remplacer les instances de base de données provisionnées par des instances sans serveur ou inversement, sans avoir à créer un nouveau cluster de bases de données ou une nouvelle instance de base de données.
+ **Développement et tests** : Neptune sans serveur convient également parfaitement aux environnements de développement et de test. Avec Neptune sans serveur, vous pouvez créer des instances de base de données avec une capacité maximale suffisamment élevée pour tester l'application la plus exigeante, et une faible capacité minimale pour tous les autres cas où le système peut être inactif entre les tests.
Neptune sans serveur met uniquement à l'échelle la capacité de calcul. Votre volume de stockage reste le même et n'est pas affecté par la mise à l'échelle sans serveur.
**Note**
Vous pouvez également [utiliser l'auto-scaling Neptune avec Neptune sans serveur](manage-console-autoscaling.md#autoscaling-with-serverless) pour gérer différents types de variantes de charge de travail.
## Contraintes d'Amazon Neptune sans serveur
+ Neptune Serverless est uniquement disponible dans les régions suivantes :
+ USA Est (Virginie du Nord) : `us-east-1`
+ USA Est (Ohio) : `us-east-2`
+ USA Ouest (Californie du Nord) : `us-west-1`
+ USA Ouest (Oregon) : `us-west-2`
+ Canada (Centre) : `ca-central-1`
+ Europe (Stockholm) : `eu-north-1`
+ Europe (Espagne) : `eu-south-2`
+ Europe (Irlande) : `eu-west-1`
+ Europe (Londres) : `eu-west-2`
+ Europe (Paris) : `eu-west-3`
+ Europe (Francfort) : `eu-central-1`
+ Asie-Pacifique (Tokyo) : `ap-northeast-1`
+ Asie-Pacifique (Séoul) : `ap-northeast-2`
+ Asie-Pacifique (Singapour) : `ap-southeast-1`
+ Asie-Pacifique (Sydney) : `ap-southeast-2`
+ Asie-Pacifique (Jakarta) : `ap-southeast-3`
+ Asie-Pacifique (Hong Kong) : `ap-east-1`
+ Asie-Pacifique (Mumbai) : `ap-south-1`
+ Amérique du Sud (São Paulo) : `sa-east-1`
+ **Pas disponible dans les premières versions du moteur** : Neptune sans serveur n'est disponible que dans les versions 1.2.0.1 ou ultérieures du moteur.
+ **Pas compatible avec le cache de recherche Neptune :** le [cache de recherche](feature-overview-lookup-cache.md) ne fonctionne pas avec les instances de base de données sans serveur.
+ **La mémoire maximale d'une instance sans serveur est de 256 Go**. Le réglage `MaxCapacity` sur 128 NCUs (le paramètre le plus élevé pris en charge) permet à une instance Neptune Serverless de passer à 256 Go de mémoire, ce qui est équivalent à celui d'`R6g.8XL`un type d'instance provisionnée.
# 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 (RAM) ainsi que la capacité du processeur virtuel (vCPU) et le réseau associés. Elle est définie en tant que partie d'un objet `ServerlessV2ScalingConfiguration`, représenté en JSON comme ceci :
```
"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 [ServerlessDatabaseCapacity](neptune-serverless-using.md#neptune-serverless-monitoring)métrique au niveau de l'instance pour savoir combien NCUs une instance de base de données donnée utilise actuellement, et la [NCUUtilization](neptune-serverless-using.md#neptune-serverless-monitoring)mé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 valeur NCU minimale que vous spécifiez définit la plus petite taille possible d'une instance sans serveur du cluster de bases de données. De même, la valeur NCU maximale définit la plus grande taille possible d'une instance sans serveur. La valeur NCU maximale la plus élevée 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 sans serveur en surveillant son utilisation de ressources telles que le 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 baisse, la capacité diminue pour atteindre les unités de capacité minimale configurées: La capacité du CPU est 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 trois AZs, 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.0` NCUs.
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.0` NCUs, et la plus petite valeur que vous pouvez définir pour la capacité maximale est `2.5` NCUs. 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 votre charge de travail provisionnée présente des exigences en mémoire trop élevées pour les petites classes d'instances de base de données telles que `T3` ou `T4g`, choisissez un nombre minimal de NCU qui fournit une quantité de mémoire comparable à une instance de base de données `R5` ou `R6g`.
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'instances de base de données dispose de 32 Gio de mémoire. Vous pouvez donc spécifier 16 NCU comme paramètre de capacité minimale pour créer des instances sans serveur pouvant réduire leur capacité en conséquence (chaque NCU correspond à environ 2 Gio de mémoire environ). 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 le plus efficacement lorsque vos instances de base de données peuvent contenir une quantité spécifique de données en mémoire ou dans le cache de mémoire tampon, envisagez de spécifier un nombre minimal de NCU 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é de données I/O à ramener dans le cache tampon est importante, il peut être intéressant de choisir une valeur NCU 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](neptune-serverless-configuration.md#neptune-serverless-mixed-configuration) 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'instances de base de données dispose de 128 Gio de mémoire. Vous pouvez donc spécifier 64 NCU comme paramètre maximal pour configurer des instances Neptune sans serveur équivalentes (chaque NCU correspond à environ 2 Gio 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.
# Configuration supplémentaire pour les instances et les clusters de bases de données Neptune sans serveur
Outre la [définition de la capacité minimale et maximale](neptune-serverless-capacity-scaling.md) du cluster de bases de données Neptune sans serveur, vous devez prendre en compte quelques autres choix de configuration.
## Combinaison d'instances sans serveur et d'instances provisionnées dans un cluster de bases de données
Un cluster de bases de données ne doit pas nécessairement être uniquement sans serveur : vous pouvez créer une combinaison d'instances sans serveur et d'instances provisionnées (configuration mixte).
Supposons, par exemple, que vous ayez besoin d'une capacité d'écriture supérieure à celle disponible pour une instance sans serveur. Dans ce cas, vous pouvez configurer le cluster avec un enregistreur provisionné de très grande taille tout en utilisant des instances sans serveur pour les lecteurs.
Supposons également que la charge de travail d'écriture de votre cluster varie, mais que la charge de travail de lecture soit stable. Dans ce cas, vous pouvez configurer le cluster avec un enregistreur sans serveur et un ou plusieurs lecteurs provisionnés.
Pour plus d'informations sur la création d'un cluster de bases de données à configuration mixte, consultez [Utilisation d'Amazon Neptune sans serveur](neptune-serverless-using.md).
## Définition des niveaux de promotion des instances Neptune sans serveur
Pour les clusters contenant plusieurs instances sans serveur ou une combinaison d'instances sans serveur et d'instances provisionnées, prêtez attention au paramètre de niveau de promotion pour chaque instance sans serveur. Ce paramètre contrôle davantage le comportement des instances sans serveur que celui des instances de base de données provisionnées.
Dans le AWS Management Console, vous spécifiez ce paramètre en utilisant la **priorité Failover** sous **Configuration supplémentaire** sur les pages **Créer une base de données**, **Modifier une instance** et **Ajouter un lecteur**. Cette propriété s'affiche pour les instances de base de données existantes dans la colonne facultative **Niveau de priorité** sur la page **Bases de données**. Cette propriété est également disponible sur la page de détails d'un cluster de bases de données ou d'une instance.
Pour les instances provisionnées, le choix du niveau 0 à 15 détermine uniquement l'ordre dans lequel Neptune choisit l'instance de lecteur à promouvoir en enregistreur lors d'une opération de basculement. Pour les instances de lecteur Neptune sans serveur, le numéro de niveau détermine également si la capacité de l'instance augmente pour correspondre à celle de l'instance d'enregistreur ou si elle se met à l'échelle indépendamment de celle-ci en fonction uniquement de sa propre charge de travail.
Les instances de lecteur Neptune sans serveur de niveau 0 ou 1 sont maintenues à une capacité minimale au moins égale à celle de l'instance d'enregistreur afin d'être prêtes à prendre le relais de l'enregistreur en cas de basculement. Si l'enregistreur est une instance provisionnée, Neptune estime la capacité sans serveur équivalente et utilise cette estimation comme capacité minimale pour l'instance de lecteur sans serveur.
Les instances de lecteur Neptune sans serveur des niveaux 2 à 15 n'ont pas la même contrainte de capacité minimale et peuvent faire l'objet d'une mise à l'échelle indépendamment de l'enregistreur. Lorsqu'elles sont inactives, leur capacité est réduite à la valeur NCU minimale spécifiée dans la [plage de capacité](neptune-serverless-capacity-scaling.md) du cluster. Cela peut toutefois poser des problèmes si la charge de travail de lecture fait l'objet d'une hausse soudaine.
## Assurer l'alignement entre la capacité des lecteurs et la capacité de l'enregistreur
Il est important de vous assurer que les instances de lecteur peuvent suivre le rythme de l'instance d'enregistreur, afin d'éviter un retard de réplication excessif. Cela est particulièrement préoccupant dans deux situations, où les instances de lecteur sans serveur ne sont pas automatiquement mises à l'échelle en synchronisation avec l'instance d'enregistreur :
+ Lorsque l'enregistreur est provisionné et que les lecteurs sont sans serveur.
+ Lorsque l'enregistreur est sans serveur et que les lecteurs sans serveur sont aux niveaux de promotion 2 à 15.
Dans les deux cas, définissez la capacité minimale sans serveur pour qu'elle corresponde à la capacité d'enregistreur attendue, afin de garantir que les opérations de lecture n'expirent pas et ne provoquent pas de redémarrages potentiels. Dans le cas d'une instance d'enregistreur provisionnée, définissez la capacité minimale pour qu'elle corresponde à celle de l'instance provisionnée. Dans le cas d'un enregistreur sans serveur, le paramètre optimal peut être plus difficile à prévoir.
Comme la plage de capacité des instances est définie au niveau du cluster, toutes les instances sans serveur sont contrôlées par les mêmes paramètres de capacité minimale et maximale. Les instances de lecteur des niveaux 0 et 1 se mettent à l'échelle en synchronisation avec l'instance d'enregistreur, mais les instances des niveaux de promotion 2 à 15 se mettent à l'échelle indépendamment les unes des autres et de l'instance d'enregistreur, en fonction de leur charge de travail. Si vous définissez une capacité minimale trop faible, la capacité des instances inactives des niveaux 2 à 15 risque d'être trop réduite pour pouvoir être réaugmentée assez rapidement afin de faire face à une augmentation soudaine de l'activité de l'enregistreur.
## Éviter de définir une valeur de délai d'expiration trop élevée
Il est possible que vous encouriez des coûts inattendus si vous définissez une valeur trop élevée pour le délai d'expiration des requêtes sur une instance sans serveur.
Sans paramètre de délai d'expiration raisonnable, vous risquez d'émettre par inadvertance une requête qui nécessite un type d'instance puissant et coûteux et qui continue de s'exécuter pendant très longtemps, entraînant ainsi des coûts que vous n'auriez jamais anticipés. Pour éviter cette situation, utilisez une valeur de délai d'expiration qui convient à la plupart des requêtes et qui n'implique que l'expiration de celles dont le délai est étonnamment long.
Ce principe est valable à la fois pour les valeurs de délai d'expiration générales définies à l'aide de paramètres et pour les valeurs de délai d'expiration par requête définies à l'aide d'indicateurs de requête.
## Optimisation de la configuration de Neptune sans serveur
Si le cluster de bases de données Neptune sans serveur n'est pas adapté à la charge de travail qu'il exécute, vous remarquerez peut-être qu'il ne fonctionne pas de manière optimale. Vous pouvez ajuster le paramètre de capacité and/or maximale minimale afin qu'il puisse évoluer sans rencontrer de problèmes de mémoire.
+ Augmentez la valeur du paramètre de capacité minimale du cluster. Cette action peut remédier à la situation dans laquelle une instance inactive revient à une capacité qui dispose de moins de mémoire que ce dont votre application et les fonctionnalités activées ont besoin.
+ Augmentez la valeur du paramètre de capacité maximale du cluster. Cette action peut remédier à la situation dans laquelle la capacité d'une base de données occupée ne parvient pas à augmenter au point d'atteindre une capacité où la mémoire serait suffisante pour gérer la charge de travail ainsi que les fonctionnalités qui ont été activées et qui nécessitent beaucoup de mémoire.
+ Modifiez la charge de travail sur l'instance en question. Par exemple, vous pouvez ajouter des instances de lecteur au cluster afin de répartir la charge sur d'autres instances.
+ Ajustez les requêtes de votre application afin qu'elles utilisent moins de ressources.
+ Essayez d'utiliser une instance provisionnée dont la taille est supérieure au maximum NCUs disponible dans Neptune Serverless, pour voir si elle correspond mieux aux exigences de mémoire et de processeur de la charge de travail.
# Utilisation d'Amazon Neptune sans serveur
Vous pouvez créer un cluster de bases de données Neptune en tant que cluster sans serveur ou, dans certains cas, vous pouvez convertir un cluster de bases de données existant en cluster sans serveur. Vous pouvez également convertir les instances de base de données d'un cluster de bases de données sans serveur en instances sans serveur, et inversement. Vous ne pouvez utiliser Neptune Serverless que dans les pays Régions AWS où il est pris en charge, avec quelques autres limitations (voir). [Contraintes d'Amazon Neptune sans serveur](neptune-serverless.md#neptune-serverless-limitations)
Vous pouvez également utiliser la [pile Neptune CloudFormation](get-started-cfn-create.md) pour créer un cluster de bases de données Neptune sans serveur.
## Création d'un cluster de bases de données utilisant le mode sans serveur
Pour créer un cluster de bases de données Neptune utilisant le mode sans serveur, vous pouvez le faire [en utilisant la AWS Management Console](manage-console-launch-console.md) de la même manière que pour créer un cluster provisionné. La différence est que sous **Taille de l'instance de base de données**, vous devez définir la **classe d'instances de base de données** en mode **sans serveur**. Lorsque vous effectuez cette opération, vous devez [définir la plage de capacité sans serveur](neptune-serverless-capacity-scaling.md) du cluster.
Vous pouvez également créer un cluster de base de données sans serveur à l'aide des commandes AWS CLI with comme celle-ci (sous Windows, remplacez « \$1 » par « ^ ») :
```
aws neptune create-db-cluster \
--region (an Région AWS region that supports serverless) \
--db-cluster-identifier (ID for the new serverless DB cluster) \
--engine neptune \
--engine-version (optional: 1.2.0.1 or above) \
--serverless-v2-scaling-configuration "MinCapacity=1.0, MaxCapacity=128.0"
```
Vous pouvez également spécifier le paramètre `serverless-v2-scaling-configuration` comme suit :
```
--serverless-v2-scaling-configuration '{"MinCapacity":1.0, "MaxCapacity":128.0}'
```
Vous pouvez ensuite exécuter la commande `describe-db-clusters` pour l'attribut `ServerlessV2ScalingConfiguration`, qui devrait renvoyer les paramètres de plage de capacité que vous avez spécifiés :
```
"ServerlessV2ScalingConfiguration": {
"MinCapacity": (the specified minimum number of NCUs),
"MaxCapacity": (the specified maximum number of NCUs)
}
```
## Conversion d'un cluster de bases de données ou d'une instance de base de données existant en mode sans serveur
Si vous avez un cluster de bases de données Neptune qui utilise la version 1.2.0.1 ou supérieure du moteur, vous pouvez le convertir en cluster sans serveur. Ce processus entraîne des temps d'arrêt.
La première étape consiste à ajouter une plage de capacité au cluster existant. Vous pouvez le faire en utilisant AWS Management Console le ou en utilisant une AWS CLI commande comme celle-ci (sous Windows, remplacez « \$1 » par « ^ ») :
```
aws neptune modify-db-cluster \
--db-cluster-identifier (your DB cluster ID) \
--serverless-v2-scaling-configuration \
MinCapacity=(minimum number of NCUs, such as 2.0), \
MaxCapacity=(maximum number of NCUs, such as 24.0)
```
L'étape suivante consiste à créer une instance de base de données sans serveur pour remplacer l'instance principale existante (enregistreur) dans le cluster. Encore une fois, vous pouvez effectuer cette opération et toutes les étapes suivantes en utilisant le AWS Management Console ou le AWS CLI. Dans les deux cas, spécifiez la classe d'instances de base de données comme étant sans serveur. La AWS CLI commande ressemblerait à ceci (sous Windows, remplacez « \$1 » par « ^ ») :
```
aws neptune create-db-instance \
--db-instance-identifier (an instance ID for the new writer instance) \
--db-cluster-identifier (ID of the DB cluster) \
--db-instance-class db.serverless \
--engine neptune
```
Lorsque la nouvelle instance d'enregistreur est disponible, effectuez un basculement pour en faire l'instance d'enregistreur du cluster :
```
aws neptune failover-db-cluster \
--db-cluster-identifier (ID of the DB cluster) \
--target-db-instance-identifier (instance ID of the new serverless instance)
```
Supprimez ensuite l'ancienne instance d'enregistreur :
```
aws neptune delete-db-instance \
--db-instance-identifier (instance ID of the old writer instance) \
--skip-final-snapshot
```
Enfin, faites de même pour créer une instance sans serveur qui remplacera chaque instance de lecteur provisionnée que vous souhaitez convertir en instance sans serveur, et supprimez les instances provisionnées existantes (aucun basculement n'est nécessaire pour les instances de lecteur).
## Modification de la plage de capacité d'un cluster de bases de données sans serveur
Vous pouvez modifier la plage de capacité d'un cluster de bases de données Neptune sans serveur en utilisant l' AWS CLI comme suit (sous Windows, remplacez « \$1 » par « ^ ») :
```
aws neptune modify-db-cluster \
--region (an AWS region that supports serverless) \
--db-cluster-identifier (ID of the serverless DB cluster) \
--apply-immediately \
--serverless-v2-scaling-configuration MinCapacity=4.0, MaxCapacity=32
```
La modification de la plage de capacité 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. Le statut `pending-reboot` indique qu'un redémarrage est nécessaire pour appliquer certaines modifications de paramètre.
## Conversion d'une instance de base de données sans serveur en instance provisionnée
Pour convertir une instance Neptune sans serveur en instance provisionnée, il vous suffit de remplacer sa classe d'instances par l'une des classes d'instances provisionnées. Consultez [Modification d'une instance de base de données Neptune (et application immédiate)](manage-console-instances-modify.md).
## Configuration des clients G705 pour Serverless
Lorsque vous utilisez des WebSocket clients Gremlin avec Neptune Serverless, vous devez configurer l'intervalle de pulsation du client de manière appropriée afin de maintenir des connexions stables pendant les événements de dimensionnement. Pour obtenir des instructions de configuration détaillées pour les clients Java, Go, JavaScript /Node.js et Python, consultez[Configuration Heartbeat pour Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md).
## Surveillance de la capacité sans serveur avec Amazon CloudWatch
Vous pouvez l'utiliser CloudWatch pour surveiller la capacité et l'utilisation des instances sans serveur Neptune dans votre cluster de base de données. Deux CloudWatch mesures vous permettent de suivre la capacité sans serveur actuelle à la fois au niveau du cluster et au niveau de l'instance :
+ **`ServerlessDatabaseCapacity`**— En tant que métrique au niveau de l'instance, `ServerlessDatabaseCapacity` indique la capacité actuelle de l'instance, en. NCUs En tant que métrique au niveau du cluster, elle représente la moyenne de toutes valeurs `ServerlessDatabaseCapacity` de toutes les instances de base de données du cluster.
+ **`NCUUtilization`** : cette métrique indique le pourcentage de capacité possible utilisée. Elle est calculée en utilisant la valeur `ServerlessDatabaseCapacity` actuelle (au niveau de l'instance ou du cluster) divisée par le paramètre de capacité maximale du cluster de bases de données.
Si cette métrique approche les 100 % au niveau d'un cluster, ce qui signifie que la capacité du cluster est aussi élevée qu'elle peut l'être, envisagez d'augmenter le paramètre de capacité maximale.
Si elle approche les 100 % pour une instance de lecteur alors que l'instance d'enregistreur n'est pas proche de sa capacité maximale, envisagez d'ajouter d'autres instances de lecteur pour répartir la charge de travail de lecture.
Notez que les métriques `CPUUtilization` et `FreeableMemory` ont des significations légèrement différentes pour les instances sans serveur et pour les instances provisionnées. Dans un contexte sans serveur, `CPUUtilization` est un pourcentage calculé comme la quantité de CPU actuellement utilisée, divisée par la quantité de CPU disponible à la capacité maximale. De même, `FreeableMemory` indique la quantité de mémoire libérable qui serait disponible si une instance était à sa capacité maximale.
L'exemple suivant montre comment utiliser AWS CLI le sous Linux pour récupérer les valeurs de capacité minimale, maximale et moyenne pour une instance de base de données donnée, mesurées toutes les 10 minutes pendant une heure. La commande Linux `date` indique les heures de début et de fin par rapport à la date et à l’heure actuelles. La fonction `sort_by` du paramètre `--query` trie les résultats par ordre chronologique en fonction du champ `Timestamp` :
```
aws cloudwatch get-metric-statistics \
--metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d '1 hour ago')" \
--end-time "$(date -d 'now')" \
--period 600 \
--namespace "AWS/Neptune"
--statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=(instance ID) \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' \
--output table
```