A l'aide deAWS Lambdafonctions dans 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.

A l'aide deAWS Lambdafonctions dans Amazon Neptune

AWS Lambdales fonctions ont de nombreuses utilisations dans les applications Amazon Neptune. Nous fournissons ici des conseils généraux sur l'utilisation des fonctions Lambda avec n'importe lequel des pilotes et variantes de langue Gremlin populaires, ainsi que des exemples spécifiques de fonctions Lambda écrites en Java, JavaScript et Python.

Note

La meilleure façon d'utiliser les fonctions Lambda avec Neptune a changé avec les versions récentes du moteur. Neptune avait l'habitude de laisser les connexions inactives ouvertes longtemps après le recyclage d'un contexte d'exécution Lambda, ce qui entraînait potentiellement une fuite de ressources sur le serveur. Pour atténuer ce problème, nous recommandons d'ouvrir et de fermer une connexion à chaque appel Lambda. Toutefois, à partir de la version 1.0.3.0 du moteur, le délai d'attente de connexion inactif a été réduit, de sorte que les connexions ne fuient plus après le recyclage d'un contexte d'exécution Lambda inactif. Nous recommandons donc maintenant d'utiliser une seule connexion pendant toute la durée du contexte d'exécution. Cela devrait inclure une gestion des erreurs et un code de plaque de chaudière arrière et réessayer pour gérer les connexions fermées de façon inattendue.

Gestion des connexions WebSocket Gremlin dansAWS Lambdafonctions

Si vous utilisez une variante de langue Gremlin pour interroger Neptune, le pilote se connecte à la base de données à l'aide d'une connexion WebSocket. Les WebSockets sont conçus pour prendre en charge des scénarios de connexion client-serveur à longue durée de vie.AWS Lambda, d'autre part, est conçu pour soutenir des exécutions relativement brèves et apatrides. Cette incompatibilité dans la philosophie de conception peut entraîner des problèmes inattendus lors de l'utilisation de Lambda pour interroger Neptune.

UnAWS Lambdas'exécute dans une fonctionContexte d'exécutionqui isole la fonction des autres fonctions. Le contexte d'exécution est créé la première fois que la fonction est appelée et peut être réutilisé pour les appels ultérieurs de la même fonction.

Cependant, aucun contexte d'exécution n'est utilisé pour gérer plusieurs appels simultanés de la fonction. Si votre fonction est appelée simultanément par plusieurs clients, Lambdagénère un contexte d'exécution supplémentairepour chaque instance de la fonction. Tous ces nouveaux contextes d'exécution peuvent à leur tour être réutilisés pour les appels suivants de la fonction.

À un moment donné, Lambda recycle les contextes d'exécution, surtout s'ils sont inactifs depuis un certain temps.AWS Lambdaexpose le cycle de vie du contexte d'exécution, y compris leInit,InvokeetShutdownphases, à traversExtensions Lambda. À l'aide de ces extensions, vous pouvez écrire du code qui nettoie des ressources externes telles que les connexions à la base de données lorsque le contexte d'exécution est recyclé.

Une bonne pratique courante consiste à :ouvrir la connexion à la base de données en dehors de la fonction de gestionnaire Lambdaafin qu'il puisse être réutilisé à chaque appel de gestionnaire. Si la connexion à la base de données tombe à un moment donné, vous pouvez vous reconnecter depuis l'intérieur du gestionnaire. Cependant, cette approche présente un risque de fuite de connexion. Si une connexion inactive reste ouverte longtemps après la destruction d'un contexte d'exécution, des scénarios d'appel Lambda intermittents ou éclatants peuvent progressivement fuir les connexions et épuiser les ressources de base de données.

Les limites de connexion et les délais d'expiration de connexion Neptune ont changé avec les nouvelles versions du moteur. Auparavant, chaque instance prenait en charge jusqu'à 60 000 connexions WebSocket. Désormais, le nombre maximal de connexions WebSocket simultanées par instance Neptunevarie selon le type d'instance.

De plus, à partir de la version 1.0.3.0 du moteur, Neptune a réduit le délai d'inactivité des connexions d'une heure à environ 20 minutes. Si un client ne ferme pas une connexion, elle se ferme automatiquement après un délai d'inactivité de 20 à 25 minutes.AWS Lambdane documente pas la durée de vie du contexte d'exécution, mais les expériences montrent que le nouveau délai d'expiration de connexion Neptune s'aligne bien avec les délais d'expiration inactifs du contexte d'exécution Lambda. Au moment où un contexte d'exécution inactif est recyclé, il y a de fortes chances que sa connexion ait déjà été fermée par Neptune, ou qu'elle soit fermée peu de temps après.

Recommandations pour l'utilisationAWS Lambdaavec Amazon Neptune Gremlin

Nous recommandons désormais d'utiliser une seule connexion et une source de traversée de graphe pendant toute la durée de vie d'un contexte d'exécution Lambda, plutôt qu'une seule pour chaque appel de fonction (chaque appel de fonction ne gère qu'une seule demande client). Étant donné que les demandes client simultanées sont gérées par différentes instances de fonctions exécutées dans des contextes d'exécution distincts, il n'est pas nécessaire de maintenir un pool de connexions pour gérer les demandes simultanées au sein d'une instance de fonction. Si le pilote Gremlin que vous utilisez possède un pool de connexions, configurez-le pour n'utiliser qu'une seule connexion.

Pour gérer les échecs de connexion, utilisez la logique de nouvelle tentative autour de chaque requête. Même si l'objectif est de maintenir une connexion unique pendant toute la durée de vie d'un contexte d'exécution, des événements réseau inattendus peuvent entraîner la fin brutale de cette connexion. Ces échecs de connexion se manifestent par des erreurs différentes selon le pilote que vous utilisez. Vous devez coder votre fonction Lambda pour gérer ces problèmes de connexion et tenter une reconnexion si nécessaire.

Certains pilotes Gremlin gèrent automatiquement les reconnexions. Le pilote Java, par exemple, tente automatiquement de rétablir la connectivité à Neptune au nom de votre code client. Avec ce pilote, votre code de fonction n'a qu'à annuler et à réessayer la requête. En revanche, les pilotes JavaScript et Python n'implémentent aucune logique de reconnexion automatique. Par conséquent, avec ces pilotes, votre code de fonction doit essayer de se reconnecter après avoir redémarré, et ne relancer la requête qu'une fois la connexion rétablie.

Les exemples de code ici incluent la logique de reconnexion plutôt que de supposer que le client s'en occupe.

Recommandations pour l'utilisation des demandes d'écriture Gremlin dans Lambda

Si votre fonction Lambda modifie les données du graphique, envisagez d'adopter une stratégie de répétition et de réessayer pour gérer les exceptions suivantes :

  • ConcurrentModificationException— La sémantique des transactions Neptune signifie que les demandes d'écriture échouent parfois avec unConcurrentModificationException. Dans ces situations, essayez un mécanisme de nouvelle tentative exponentiel basé sur le back-off.

  • ReadOnlyViolationException— Étant donné que la topologie du cluster peut changer à tout moment suite à des événements planifiés ou non planifiés, les responsabilités d'écriture peuvent migrer d'une instance du cluster à une autre. Si votre code de fonction tente d'envoyer une demande d'écriture à une instance qui n'est plus l'instance principale (écrivain), la demande échoue avec unReadOnlyViolationException. Lorsque cela se produit, fermez la connexion existante, reconnectez-vous au point de terminaison du cluster, puis réessayez la demande.

De plus, si vous utilisez une stratégie de sauvegarde et de nouvelle tentative pour gérer les problèmes de demandes d'écriture, envisagez d'implémenter des requêtes idempotentes pour les demandes de création et de mise à jour (par exemple, en utilisantfold () .coalesce () .unfold ().

Recommandations pour l'utilisation des requêtes de lecture Gremlin dans Lambda

Si vous avez un ou plusieurs réplicas en lecture dans votre cluster, il est judicieux d'équilibrer les demandes de lecture entre ces réplicas. L'une des options consiste à utiliser lepoint de terminaison du lecteur. Le point de terminaison du lecteur équilibre les connexions entre les réplicas même si la topologie du cluster change lorsque vous ajoutez ou supprimez des réplicas, ou promouvez qu'un réplica devienne la nouvelle instance principale.

Toutefois, l'utilisation du point de terminaison du lecteur peut entraîner une utilisation inégale des ressources de cluster dans certaines circonstances. Le point de terminaison du lecteur modifie périodiquement l'hôte vers lequel l'entrée DNS pointe. Si un client ouvre de nombreuses connexions avant que l'entrée DNS ne change, toutes les demandes de connexion sont envoyées à une seule instance Neptune. Cela peut être le cas avec un scénario Lambda à haut débit où un grand nombre de requêtes simultanées à votre fonction Lambda provoquent la création de plusieurs contextes d'exécution, chacun ayant sa propre connexion. Si ces connexions sont toutes créées presque simultanément, les connexions sont susceptibles de pointer toutes vers le même réplica dans le cluster et de continuer à pointer vers ce réplica jusqu'à ce que les contextes d'exécution soient recyclés.

Une façon de distribuer les demandes entre les instances consiste à configurer votre fonction Lambda pour qu'elle se connecte à un point de terminaison d'instance, choisi au hasard à partir d'une liste de points de terminaison d'instance de réplica plutôt que du point de terminaison du lecteur. L'inconvénient de cette approche est qu'elle nécessite le code Lambda pour gérer les modifications de la topologie du cluster en surveillant le cluster et en mettant à jour la liste des points de terminaison chaque fois que l'appartenance au cluster change.

Si vous écrivez une fonction Java Lambda qui doit équilibrer les demandes de lecture entre les instances de votre cluster, vous pouvez utiliser leClient Gremlin pour Amazon Neptune, un client Java Gremlin qui connaît la topologie de votre cluster et qui distribue équitablement les connexions et les requêtes sur un ensemble d'instances d'un cluster Neptune. Cet article de bloginclut un exemple de fonction Java Lambda qui utilise le client Gremlin pour Amazon Neptune.

Facteurs susceptibles de ralentir les démarrages à froid des fonctions Neptune Gremlin Lambda

La première fois qu'unAWS Lambdaest appelé est appelé un démarrage à froid. Plusieurs facteurs peuvent augmenter la latence d'un démarrage à froid :

  • Assurez-vous d'affecter suffisamment de mémoire à votre fonction Lambda.   — La compilation lors d'un démarrage à froid peut être significativement plus lente pour une fonction Lambda qu'elle ne le serait sur EC2 carAWS Lambdaalloue les cycles CPUlinéairement proportionnellement à la mémoireque vous attribuez à la fonction. Avec 1 792 Mo de mémoire, une fonction reçoit l'équivalent d'un vCPU entier (un vCPU-seconde de crédits par seconde). L'impact de l'absence de mémoire suffisante pour recevoir des cycles CPU adéquats est particulièrement prononcé pour les grandes fonctions Lambda écrites en Java.

  • Sachez queactiver l'authentification de base de données IAMpeut ralentir un démarrage à froid–AWS Identity and Access ManagementL'authentification de base de données (IAM) peut également ralentir les démarrages à froid, en particulier si la fonction Lambda doit générer une nouvelle clé de signature. Cette latence n'affecte que le démarrage à froid et non les demandes suivantes, car une fois que l'authentification IAM DB a établi les informations d'identification de connexion, Neptune ne vérifie que périodiquement qu'elles sont toujours valides.