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.

# Recommandations d'utilisation AWS Lambda avec Amazon Neptune G705
<a name="lambda-functions-gremlin-recommendations"></a>

Nous recommandons désormais d'utiliser une seule source de connexion et de traversée de graphes pendant toute la durée de vie d'un contexte d'exécution Lambda, plutôt qu'une pour chaque invocation de fonction (chaque invocation de fonction ne gère qu'une seule demande client). Comme les demandes simultanées des clients sont traitées par différentes instances de fonction exécutées dans des contextes d'exécution distincts, il n'est pas nécessaire de gérer un pool de connexions pour traiter 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 une logique de nouvelle tentative pour 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 une interruption abrupte de cette connexion. Ces échecs de connexion se traduisent par des erreurs différentes selon le pilote que vous utilisez. Vous devez coder la 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 pour le compte du code client. Avec ce pilote, le code de la fonction n'a qu'à exécuter un backoff et une nouvelle tentative de la requête. Les pilotes Python JavaScript et Python, en revanche, n'implémentent aucune logique de reconnexion automatique. Ainsi, avec ces pilotes, votre code de fonction doit essayer de se reconnecter après avoir reculé, et ne réessayer la requête qu'une fois la connexion rétablie.

Les exemples de code présentés ici incluent la logique de reconnexion au lieu de supposer que le client s'en occupe.

# Recommandations pour l'utilisation des demandes d'écriture Gremlin dans Lambda
<a name="lambda-functions-gremlin-write-recommendations"></a>

Si votre fonction Lambda modifie les données du graphe, envisagez d'adopter une back-off-and-retry stratégie pour gérer les exceptions suivantes :
+ **`ConcurrentModificationException`** : la sémantique des transactions Neptune signifie que les demandes d'écriture échouent parfois avec une exception `ConcurrentModificationException`. Dans ces situations, essayez un mécanisme de back-off-based nouvelle tentative exponentielle.
+ **`ReadOnlyViolationException`** : comme la topologie du cluster peut changer à tout moment en raison d'événements planifiés ou imprévus, les responsabilités d'écriture peuvent être transférées d'une instance du cluster à une autre. Si le code de la fonction tente d'envoyer une demande d'écriture à une instance qui n'est plus l'instance principale (d'enregistreur), cette demande échouera avec une exception `ReadOnlyViolationException`. Dans ce cas, fermez la connexion existante, reconnectez-vous au point de terminaison du cluster, puis retentez la demande.

De plus, si vous utilisez une back-off-and-retry stratégie pour gérer les problèmes de demande d'écriture, envisagez d'implémenter des requêtes idempotentes pour les demandes de création et de mise à jour (par exemple, en utilisant [fold () .coalesce () .unfold (](http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#upsert)).

# Recommandations pour l'utilisation des demandes de lecture Gremlin dans Lambda
<a name="lambda-functions-gremlin-read-recommendations"></a>

Si votre cluster possède un ou plusieurs réplicas en lecture, il est conseillé d'équilibrer les demandes de lecture entre ces réplicas. L'une des options consiste à utiliser le [point de terminaison du lecteur](feature-overview-endpoints.md). 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 lorsque vous promouvez un réplica pour en faire la nouvelle instance principale.

Cependant, l'utilisation du point de terminaison du lecteur peut entraîner une utilisation inégale des ressources du cluster dans certaines circonstances. Le point de terminaison de lecteur fonctionne en modifiant périodiquement l’hôte vers lequel pointe l'entrée DNS. 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 dans un scénario Lambda à haut débit dans lequel un grand nombre de demandes simultanées adressées à la fonction Lambda entraîne la création de plusieurs contextes d'exécution, chacun avec sa propre connexion. Si ces connexions sont toutes créées presque simultanément, elles sont susceptibles de toutes pointer vers le même réplica du cluster et de continuer à pointer vers lui jusqu'à ce que les contextes d'exécution soient recyclés.

L'un des moyens de répartir les demandes entre les instances consiste à configurer la fonction Lambda pour qu'elle se connecte à un point de terminaison d'instance, choisi au hasard dans une liste de points de terminaison d'instance de réplica, plutôt qu'au point de terminaison du lecteur. L'inconvénient de cette approche est qu'elle nécessite que le code Lambda gère 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 Lambda Java qui doit équilibrer les demandes de lecture entre les instances de votre cluster, vous pouvez utiliser le [client Gremlin pour Amazon Neptune](https://github.com/aws/neptune-gremlin-client), un client Java Gremlin qui connaît la topologie de votre cluster et qui répartit équitablement les connexions et les demandes entre un ensemble d'instances d'un cluster Neptune. [Ce billet de blog](https://aws.amazon.com/blogs/database/load-balance-graph-queries-using-the-amazon-neptune-gremlin-client/) inclut un exemple de fonction Lambda Java qui utilise le client Gremlin pour Amazon Neptune.

# Facteurs susceptibles de ralentir les démarrages à froid des fonctions Lambda Neptune Gremlin
<a name="lambda-functions-gremlin-cold-start-recommendations"></a>

La première fois qu'une AWS Lambda fonction est invoquée, on parle de démarrage à froid. Plusieurs facteurs peuvent augmenter la latence d'un démarrage à froid :
+ **Assurez-vous d'affecter suffisamment de mémoire à la fonction Lambda.**   — La compilation pendant un démarrage à froid peut être nettement plus lente pour une fonction Lambda qu'elle ne le serait lorsqu'elle est activée, EC2 car les cycles du processeur sont AWS Lambda répartis de manière [linéaire en fonction de la mémoire que vous attribuez à la](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) fonction. Avec 1 769 Mo de mémoire, une fonction reçoit l'équivalent d'un vCPU complet (une seconde vCPU de crédits par seconde). L'impact de l'allocation d'une quantité de mémoire insuffisante pour recevoir les cycles de CPU est particulièrement prononcé pour les fonctions Lambda volumineuses écrites en Java.
+ **Sachez que l'[activation de l'authentification de base de données IAM](iam-auth-enable.md) peut ralentir un démarrage à froid**. L'authentification de base de données Gestion des identités et des accès AWS (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 pas les demandes suivantes, car une fois que l'authentification de base de données IAM a établi les informations d'identification de connexion, Neptune ne fait que valider périodiquement qu'elles sont toujours valides.