Directives opérationnelles de base Amazon Neptune - Amazon Neptune

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.

Directives opérationnelles de base Amazon Neptune

Voici les directives opérationnelles de base que vous devez suivre lorsque vous utilisez Neptune.

  • Comprenez les instances DB 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 et instances de base de données Amazon Neptune.

  • Surveillez votre utilisation de l'UC et de la mémoire. Ceci vous permet de savoir quand migrer vers une classe d'instance de base de données avec une plus grande capacité de l'UC 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 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 l'UC. Rencontrer out-of-memory exceptions lors de l'exécution des requêtes sont le meilleur indicateur que vous avez besoin d'augmenter 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'écriture principale. Cela permet de contrôler le retard de réplication et d'éviter les redémarrages du réplica. Consultez Évitez les différentes classes d'instance dans un cluster.

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

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

Bonnes pratiques de sécurité Amazon Neptune

UtiliserAWS 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 la suppression des 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).

  • Assignez un compte IAM individuel à chaque personne qui gère les ressources Amazon Relational Database Service (Amazon RDS). N'utilisez pasAWSles utilisateurs racine du compte 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 pour accéder aux ressources Neptune, consultezSécurité dans Amazon Neptune. Pour obtenir des informations générales sur l'utilisation d'IAM, consultezAWS Identity and Access ManagementetBonnes pratiques IAMdans leIAM User Guide.

Activez l'index OSPG si vous avez un grand nombre de prédicats

Si votre 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 améliorer les performances en activant leIndice OSPG. Consultez L'indice OSGP.

Si possible, évitez les transactions de longue durée

Les transactions de longue durée, qu'elles soient en lecture seule ou en lecture-écriture, peuvent entraîner des problèmes inattendus des types suivants :

Une transaction de longue durée sur une instance de lecteur ou sur une instance d'écriture avec des écritures simultanées peut entraîner une accumulation importante de différentes versions de données. Cela peut entraîner des latences plus élevées 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 comportant de nombreuses écritures peut également entraîner des problèmes si l'instance redémarre. Si une instance redémarre à la suite d'un événement de maintenance ou d'une panne, toutes les écritures non validées sont 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 revenir, mais toute nouvelle écriture qui entre en conflit avec les opérations annulées échoue.

Par exemple, si la même requête est retentée après la rupture de la connexion lors de l'exécution précédente, cela risque d'échouer lors du 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 base 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. À l'aide de ces données, vous pouvez configurer Amazon CloudWatch des alarmes pour des seuils de métriques spécifiques pour être alerté lorsqu'ils 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.

VoirSurveillance de Neptune à l'aide d'Amazon CloudWatchpour plus d'informations sur la façon d'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 tampons. Les échecs de 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 pose un problème pour votre application, envisagez de mettre à niveau le type d'instance pour mettre en cache davantage de données en mémoire.

  • Utilisation de l'UC— Pourcentage de capacité de traitement informatique utilisée. Selon vos objectifs en matière de performance des requêtes, des valeurs de consommation d'UC é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 dispose de son propre gestionnaire de mémoire, cette métrique peut afficher des valeurs plus petites que prévu. Si les requêtes lancent souvent des requêtes, c'est certainement le signe que vous devriez envisager de mettre à niveau votre classe d'instance vers une classe d'instance qui offre out-of-memory exceptions.

La ligne rouge sous l'onglet Monitoring (Surveillance) indique 75 % pour les métriques d'UC 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 régler les requêtes Neptune

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

Pour plus d'informations sur la façon d'ajuster les requêtes Gremlin, consultezIndicateurs relatifs à la requête GremlinetRéglage des requêtes Gremlin. Pour plus d'informations sur la façon d'ajuster les requêtes SPARQL, consultez Indicateurs d'une requête.

Équilibrage de charge sur 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 connexion et résoudre l'enregistrement DNS pour obtenir une connexion vers un nouveau réplica en lecture, car WebSocket les connexions restent souvent actives pendant une période prolongée.

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 grâce à une instance temporaire plus importante

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 la même taille (r5.12xlarge).

    Vous pouvez créer les réplicas en lecture dans une taille plus petite, mais s'ils ne sont pas suffisamment grands pour suivre le rythme des écritures effectuées par l'instance principale, ils devront peut-être redémarrer fréquemment. Les temps d'arrêt qui en résultent réduisent considérablement les performances.

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

  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Évitez les différentes tailles d'instance).

Redimensionnez votre instance Writer 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'écriture, est de créer ou de 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 en lecture. Le temps d'arrêt observé par votre application correspond uniquement au temps nécessaire pour modifier l'adresse IP du rédacteur, qui devrait être d'environ 3 à 5 secondes.

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

Veillez à modifier toutes vos instances à la même taille afin d'éviter un cycle de redémarrages répétés, comme indiqué ci-dessous.

Évitez les différentes classes d'instance 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 du retard de réplication. Si un nœud de lecture a une configuration de classe d'instance DB plus faible que celle d'une instance DB d'écriture, le volume de modifications peut être trop important pour que le lecteur puisse rattraper catch.

Important

Pour éviter les redémarrages répétés causés par un retard de réplication, configurez votre cluster de bases de données de sorte que toutes les instances aient la même classe d'instance (taille).

Vous pouvez voir le décalage entre l'instance d'écriture (la principale) et les lecteurs de votre cluster de bases de données à l'aide de la commandeClusterReplicaLagMétrique dans Amazon CloudWatch. LeVolumeWriteIOPsvous permet également de détecter les rafales d'activité d'écriture dans votre cluster qui peuvent créer un retard de réplication.

Réessayer le chargement après l'interruption de la tâche de prélecture des données

Lorsque vous chargez des données dans Neptune à l'aide du chargeur en vrac, unLOAD_FAILEDle statut peut occasionnellement résulter, avec unPARSING_ERRORetData prefetch task interruptedmessage signalé en réponse à une demande d'informations détaillées, comme ceci :

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