Directives opérationnelles de base Amazon Neptune

Vous trouverez ci-dessous les directives opérationnelles de base que vous devez suivre lorsque vous utilisez Neptune.

• Familiarisez-vous avec les instances de base de données Neptune afin de pouvoir les dimensionner de manière appropriée en fonction de vos exigences en matière de performances et de cas d'utilisation. Consultez Clusters de bases de données et instances de base de données Amazon Neptune.

• Surveillez votre utilisation de CPU et de la mémoire. Ceci vous permet de savoir quand migrer vers une classe d'instances de base de données avec une plus grande capacité de CPU ou de la mémoire pour atteindre les performances des requêtes dont vous avez besoin. Vous pouvez configurer Amazon CloudWatch pour être informé quand les habitudes d'utilisation changent ou quand vous arrivez au bout de votre capacité de déploiement. Ceci peut vous aider à maintenir les performances et la disponibilité du système. Consultez Surveillance des instances et Surveillance de Neptune pour en savoir plus.

  Comme Neptune dispose de son propre gestionnaire de mémoire, il est normal d'observer une utilisation de mémoire relativement faible, et ce même en cas de forte utilisation de CPU. Les exceptions de mémoire insuffisante qui se produisent pendant l'exécution des requêtes sont le meilleur indicateur que vous avez besoin d'accroître la quantité mémoire libérable.

• Activez les sauvegardes automatiques et définissez la fenêtre de sauvegarde pour qu'elles se produisent à un moment opportun.

• Testez le basculement pour votre instance de base de données afin de connaître la durée du processus pour votre cas d'utilisation. Il permet également de veiller à ce que l'application qui accède à votre instance DB puisse automatiquement se connecter à la nouvelle instance DB suite au basculement.

• Si possible, exécutez votre client et votre cluster Neptune dans la même région et le même VPC, car les connexions entre régions avec l'appairage de VPC peuvent entraîner des délais dans les temps de réponse des requêtes. Pour obtenir des réponses aux requêtes en moins de 10 millisecondes, il est nécessaire de conserver le client et le cluster Neptune dans la même région et le même VPC.

• Lorsque vous créez une instance de réplica en lecture, elle doit être au moins aussi volumineuse que l'instance d'enregistreur principale. Cela permet de contrôler le retard de réplication et d'éviter les redémarrages du réplica. Consultez Éviter différentes classes d'instances dans un cluster.

• Avant de procéder à une mise à niveau vers une nouvelle version majeure du moteur, assurez-vous de tester votre application sur cette dernière. Pour ce faire, clonez le cluster de bases de données afin qu'il exécute la nouvelle version du moteur, puis testez votre application sur ce clone.

• Pour faciliter les basculements, toutes les instances devraient idéalement avoir la même taille.

Bonnes pratiques de sécurité pour Amazon Neptune

Utilisez les comptes AWS Identity and Access Management (IAM) pour contrôler l'accès aux actions d'API Neptune. Contrôlez les actions qui créent, modifient ou suppriment les ressources Neptune (comme les instances de base de données, les groupes de sécurité, les groupes d'options ou les groupes de paramètres), et celles qui effectuent des tâches administratives courantes (comme la sauvegarde et la restauration d'instances de base de données).

• Utilisez des informations d'identification temporaires plutôt que persistantes dans la mesure du possible.

• Attribuez un compte IAM individuel à chaque personne qui gère les ressources Amazon Relational Database Service (Amazon RDS). N'utilisez jamais les utilisateurs root du compte AWS pour gérer les ressources Neptune. Créez un utilisateur IAM pour chaque personne, y compris vous-même.

• Accordez à chaque utilisateur un ensemble minimum d'autorisations requises pour exécuter ses tâches.

• Utilisez des groupes IAM pour gérer efficacement des autorisations pour plusieurs utilisateurs.

• Effectuer une rotation régulière des informations d'identification IAM.

Pour plus d'informations sur l'utilisation d'IAM afin d'accéder aux ressources Neptune, consultez Sécurité dans Amazon Neptune. Pour obtenir des informations générales sur l'utilisation d'IAM, consultez AWS Identity and Access Management et Bonnes pratiques IAM dans le Guide de l'utilisateur IAM.

Éviter différentes classes d'instances dans un cluster

Lorsque votre cluster de bases de données contient des instances de différentes classes, des problèmes peuvent survenir au fil du temps. Le problème le plus courant est qu'une petite instance de lecteur peut entrer dans un cycle de redémarrages répétés en raison d'un retard de réplication. Si la configuration de la classe d'instances de base de données d'un nœud de lecture est plus faible que celle d'une instance de base de données d'enregistreur, le volume de modifications peut être trop vaste pour que le lecteur puisse tout gérer.

Important

Pour éviter les redémarrages répétés provoqués par un retard de réplication, configurez le cluster de bases de données de manière à ce que toutes les instances aient la même classe (taille) d'instance.

Pour voir le retard de réplication entre l'instance d'enregistreur (le principal) et les lecteurs dans votre cluster de bases de données, reportez-vous à la métrique ClusterReplicaLag dans Amazon CloudWatch. La métrique VolumeWriteIOPs vous permet également de détecter les pics d'activité d'écriture du cluster susceptibles de provoquer un retard de réplication.

Éviter les redémarrages répétés pendant le chargement en bloc

Si vous êtes confronté à un cycle de redémarrages répétés des réplicas en lecture en raison d'un retard de réplication lors d'un chargement en bloc, les réplicas ne parviendront probablement pas à suivre le rythme de l'enregistreur du cluster de bases de données.

Vous pouvez soit mettre à l'échelle les lecteurs pour qu'ils soient plus grands que l'enregistreur, soit les supprimer temporairement pendant le chargement en bloc, puis les recréer une fois le chargement terminé.

Activation de l'index OSGP si le nombre de prédicats est élevé

Si le modèle de données contient un grand nombre de prédicats distincts (plus d'un millier dans la plupart des cas), vous pouvez subir une baisse des performances et une augmentation des coûts d'exploitation.

Si tel est le cas, vous pouvez activer l'index OSGP pour améliorer les performances. Consultez Index OSGP.

Éviter les transactions de longue durée dans la mesure du possible

Les transactions de longue durée, qu'elles soient en lecture seule ou en lecture-écriture, peuvent causer des problèmes inattendus tels que les suivants :

Une transaction de longue durée sur une instance de lecteur ou d'enregistreur avec des écritures simultanées peut entraîner une accumulation importante de versions de données différentes. Les temps de latence peuvent être plus élevés pour les requêtes de lecture qui filtrent une grande partie de leurs résultats.

Dans certains cas, les versions accumulées au fil des heures peuvent entraîner la limitation des nouvelles écritures.

Une transaction de lecture-écriture de longue durée impliquant de nombreuses écritures peut également causer des problèmes si l'instance redémarre. Si une instance redémarre à la suite d'un événement de maintenance ou d'un blocage, toutes les écritures non validées seront annulées. Ces opérations d'annulation s'exécutent généralement en arrière-plan et n'empêchent pas l'instance de se rétablir, mais toute nouvelle écriture entrant en conflit avec les opérations en cours d'annulation échouera.

Par exemple, si la même requête fait l'objet d'une nouvelle tentative après une interruption de la connexion lors de l'exécution précédente, elle pourra échouer au redémarrage de l'instance.

Le temps nécessaire aux opérations d'annulation est proportionnel à l'ampleur des modifications impliquées.

Bonnes pratiques pour l'utilisation des métriques Neptune

Pour identifier les problèmes de performances causés par des ressources insuffisantes et d'autres goulots d'étranglement courants, vous pouvez surveiller les métriques disponibles pour votre cluster de bases de données Neptune.

Surveillez régulièrement les métriques de performances pour rassembler les données sur les valeurs moyennes, maximales et minimales pour différents intervalles de temps. Cela vous aide à déterminer quand les performances se dégradent. Ces données permettent de définir des alarmes Amazon CloudWatch pour des seuils de métriques spécifiques afin que vous soyez alerté dès que ces seuils sont atteints.

Lorsque vous configurez un nouveau cluster de base de données et l'exécutez avec une charge de travail classique, essayez de capturer les valeurs moyennes, maximales et minimales de toutes les métriques de performances à plusieurs intervalles différents (par exemple, une heure, 24 heures, une semaine, deux semaines). Cela vous permet de vous faire une idée de ce qui est normal. Cela permet de comparer l'activité pendant les heures pleines et les heures creuses. Vous pouvez alors utiliser ces informations pour identifier les périodes où les performances ont chuté en dessous des niveaux standard et définir des alarmes en conséquence.

Consultez Surveillance de Neptune à l'aide d'Amazon CloudWatch pour découvrir comment afficher les métriques Neptune.

Voici les métriques les plus importantes pour démarrer :

• BufferCacheHitRatio  : pourcentage de demandes traitées par le cache de tampon. Les échecs d'accès au cache ajoutent une latence importante à l'exécution des requêtes. Si le taux d'accès au cache est inférieur à 99,9 % et que la latence constitue un problème pour votre application, envisagez de mettre à niveau le type d'instance afin de mettre en cache davantage de données en mémoire.

• Utilisation de CPU : pourcentage de la capacité de traitement informatique utilisée. Selon vos objectifs en matière de performance des requêtes, des valeurs de consommation de CPU élevées peuvent être appropriées.

• Mémoire libérable : quantité de RAM disponible sur l'instance de base de données, en octets. Neptune possède son propre gestionnaire de mémoire. Cette métrique peut donc être inférieure à ce à quoi vous vous attendiez. Si les requêtes lèvent souvent des exceptions de mémoire insuffisante, c'est certainement le signe que le moment est venu de passer à une classe d'instance qui offre davantage de RAM.

La ligne rouge sous l'onglet Surveillance indique 75 % pour les métriques de CPU et de mémoire. Si la consommation de mémoire de l'instance franchit régulièrement cette ligne, vérifiez votre charge de travail et envisagez de mettre à niveau votre instance pour améliorer les performances des requêtes.

Bonnes pratiques pour le réglage des requêtes Neptune

L'un des meilleurs moyens d'améliorer les performances de Neptune consiste à ajuster les requêtes les plus communément utilisées et exigeantes en ressources pour les rendre moins onéreuses à exécuter.

Pour en savoir plus sur le réglage des requêtes Gremlin, consultez Indicateurs de requête Gremlin et Réglage des requêtes Gremlin. Pour plus d'informations sur la façon d'ajuster les requêtes SPARQL, consultez Indicateurs de requête SPARQL.

Équilibrage de charge entre les réplicas en lecture

Le routage en tourniquet du point de terminaison de lecteur modifie l'hôte vers lequel l'entrée DNS pointe. Le client doit créer une nouvelle connexion et résoudre l'enregistrement DNS pour obtenir une connexion à un nouveau réplica en lecture, car les connexions WebSocket sont souvent maintenues actives pendant de longues périodes.

Pour obtenir différents réplicas en lecture pour les requêtes successives, assurez-vous que votre client résout l'entrée DNS chaque fois qu'il se connecte. Cela peut demander la fermeture de la connexion et la reconnexion au point de terminaison du lecteur.

Vous pouvez également équilibrer la charge des requêtes entre des réplicas en lecture en vous connectant à des points de terminaison d'instance de manière explicite.

Chargement plus rapide à l'aide d'une instance temporaire de plus grande taille

Vos performances de chargement augmentent avec des tailles d'instance plus grandes. Si vous n'utilisez pas un grand type d'instance, mais que vous souhaitez accélérer le chargement, vous pouvez utiliser une instance plus grande pour le chargement, puis la supprimer.

Note

La procédure suivante est pour un nouveau cluster. Si vous disposez déjà d'un cluster existant, vous pouvez ajouter une nouvelle instance plus grande, puis la promouvoir en instance de base de données principale.

Pour charger des données à l'aide d'une taille d'instance plus grande

1. Créez un cluster avec une seule instance r5.12xlarge. Cette instance est l'instance de base de données principale.

2. Créez un ou plusieurs réplicas en lecture de même taille (r5.12xlarge).

   Vous pouvez créer des réplicas en lecture de plus petite taille, mais s'ils ne sont pas assez grands pour suivre le rythme des écritures effectuées par l'instance principale, ils nécessiteront peut-être des redémarrages fréquents. Les temps d'arrêt qui en résulteront réduiront considérablement les performances.

3. Dans la commande de chargement en bloc, incluez “parallelism” : “OVERSUBSCRIBE” pour indiquer à Neptune d'utiliser toutes les ressources de CPU disponibles pour le chargement (voir Paramètres de demande du chargeur Neptune). L'opération de chargement se déroule alors aussi rapidement que les E/S le permettent, ce qui nécessite généralement 60 à 70 % des ressources de CPU.

4. Chargez vos données à l'aide du chargeur Neptune. La tâche de chargement s'exécute sur l'instance de base de données principale.

5. Une fois le chargement des données terminé, veillez à réduire toutes les instances du cluster au même type d'instance afin d'éviter des frais supplémentaires et des problèmes de redémarrage répétés (voir Éviter différentes tailles d'instance).

Redimensionnement de l'instance d'enregistreur en basculant vers un réplica en lecture

La meilleure façon de redimensionner une instance de votre cluster de bases de données, y compris l'instance d'enregistreur, consiste à créer ou à modifier une instance de réplica en lecture afin qu'elle ait la taille souhaitée, puis de basculer délibérément vers ce réplica. Le temps d'arrêt observé par votre application correspond uniquement au temps nécessaire pour modifier l'adresse IP de l'enregistreur. Il devrait être d'environ trois à cinq secondes.

L'API de gestion Neptune que vous utilisez pour basculer délibérément de l'instance d'enregistreur actuelle vers une instance de réplica en lecture est FailoverDBCluster. Si vous utilisez le client Java Gremlin, vous devrez peut-être créer un objet client après le basculement pour relever la nouvelle adresse IP, comme indiqué ici.

Assurez-vous d'ajuster vos instances pour qu'elles aient toutes la même taille afin d'éviter un cycle de redémarrages répétés, comme indiqué ci-dessous.

Nouvelle tentative de chargement après une erreur d'interruption de tâche de lecture anticipée des données

Lorsque vous chargez des données dans Neptune à l'aide du chargeur en bloc, vous pouvez parfois obtenir le statut LOAD_FAILED avec une erreur PARSING_ERROR, tandis que le message Data prefetch task interrupted peut être indiqué en réponse à une demande d'informations détaillées, comme suit :

"errorLogs" : [
  {
    "errorCode" : "PARSING_ERROR",
    "errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
    "fileName" : "s3://some-source-bucket/some-source-file",
    "recordNum" : 0
  }
]

Si vous rencontrez cette erreur, essayez simplement de relancer la demande de téléchargement par lot.

L'erreur se produit en raison d'une interruption temporaire qui n'est généralement pas provoquée par votre demande ni vos données, et elle peut généralement être résolue en réexécutant la demande de chargement par lot.

Si vous utilisez les paramètres par défaut, à savoir "mode":"AUTO" et "failOnError":"TRUE", le chargeur ignore les fichiers qu'il a déjà chargés avec succès et reprend le chargement des fichiers qu'il n'avait pas encore chargés lorsque l'interruption s'est produite.