Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Recomendaciones para utilizar AWS Lambda con Amazon Neptune Gremlin
Ahora recomendamos utilizar un único origen de recorrido de gráficos y conexión durante toda la vida útil de un contexto de ejecución de Lambda, en lugar de utilizar uno para cada invocación de función (cada invocación de función gestiona solo una solicitud de cliente). Dado que las solicitudes de clientes simultáneas las gestionan distintas instancias de funciones que se ejecutan en contextos de ejecución distintos, no es necesario mantener un grupo de conexiones para gestionar estas solicitudes dentro de una instancia de función. Si el controlador de Gremlin que utiliza tiene un grupo de conexiones, configúrelo para que utilice solo una conexión.
Para gestionar los errores de conexión, utilice la lógica de reintento en cada consulta. Aunque el objetivo sea mantener una conexión única durante todo el tiempo que dure un contexto de ejecución, los eventos de red inesperados pueden provocar que la conexión se interrumpa de forma abrupta. Estos errores de conexión se manifiestan como errores diferentes en función del controlador que se utilice. Debe codificar la función de Lambda para gestionar estos problemas de conexión e intentar volver a conectarse si es necesario.
Algunos controladores de Gremlin gestionan automáticamente las reconexiones. El controlador de Java, por ejemplo, intenta restablecer automáticamente la conectividad con Neptune en nombre del código del cliente. Con este controlador, el código de función solo necesita retroceder y volver a intentar la consulta. En cambio, los controladores de JavaScript y Python no implementan ninguna lógica de reconexión automática, por lo que con estos controladores el código de la función debe intentar volver a conectarse después de retroceder y solo volver a intentar la consulta una vez que se haya restablecido la conexión.
Los ejemplos de código que se indican a continuación incluyen la lógica de reconexión en lugar de suponer que el cliente se está encargando de ello.
# Recomendaciones para utilizar las solicitudes de escritura de Gremlin en Lambda
Si la función de Lambda modifica los datos del gráfico, plantéese adoptar una estrategia de retroceso y reintento para gestionar las siguientes excepciones:
+ **`ConcurrentModificationException`**: la semántica de las transacciones de Neptune significa que, en ocasiones, se produce un error en las solicitudes de escritura con una `ConcurrentModificationException`. En estas situaciones, pruebe un mecanismo de reintento exponencial basado en el retroceso.
+ **`ReadOnlyViolationException`**: dado que la topología del clúster puede cambiar en cualquier momento como resultado de eventos planificados o imprevistos, las responsabilidades de escritura pueden migrar de una instancia del clúster a otra. Si el código de función intenta enviar una solicitud de escritura a una instancia que ya no es la instancia principal (escritor), se produce un error en la solicitud con una `ReadOnlyViolationException`. Cuando esto suceda, cierre la conexión existente, vuelva a conectarse al punto de conexión del clúster y, a continuación, vuelva a intentar la solicitud.
Además, si utiliza una estrategia de retroceso y reintento para solucionar los problemas de las solicitudes de escritura, plantéese implementar consultas idempotentes para las solicitudes de creación y actualización. Por ejemplo, mediante [fold().coalesce().unfold()](http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#upsert).
# Recomendaciones para utilizar las solicitudes de lectura de Gremlin en Lambda
Si tiene una o varias réplicas de lectura en el clúster, es buena idea equilibrar las solicitudes de lectura entre estas réplicas. Una opción es utilizar el [punto de conexión del lector](feature-overview-endpoints.md). El punto de conexión del lector equilibra las conexiones entre las réplicas, incluso si la topología del clúster cambia al añadir o eliminar réplicas, o al promover una réplica para que se convierta en la nueva instancia principal.
Sin embargo, el uso del punto de conexión del lector puede provocar un uso irregular de los recursos del clúster en algunas circunstancias. El punto de conexión del lector funciona mediante el cambio periódico del host al que apunta la entrada de DNS. Si un cliente abre muchas conexiones antes de que cambie la entrada de DNS, todas las solicitudes de conexión se envían a una única instancia de Neptune. Este puede ser el caso de un caso de Lambda de alto rendimiento en el que un gran número de solicitudes simultáneas a la función de Lambda provoca la creación de varios contextos de ejecución, cada uno con su propia conexión. Si todas estas conexiones se crean casi simultáneamente, es probable que todas apunten a la misma réplica del clúster y que sigan apuntando a esa réplica hasta que se reciclen los contextos de ejecución.
Una forma de distribuir las solicitudes entre las instancias es configurar la función de Lambda para que se conecte a un punto de conexión de la instancia, elegido al azar en una lista de puntos de conexión de la instancia de réplica, en lugar del punto de conexión del lector. El inconveniente de este enfoque es que requiere que el código de Lambda gestione los cambios en la topología del clúster mediante la supervisión del clúster y la actualización de la lista de puntos de conexión cada vez que cambia la pertenencia al clúster.
Si está escribiendo una función de Lambda de Java que necesita equilibrar las solicitudes de lectura entre las instancias del clúster, puede utilizar el [cliente Gremlin para Amazon Neptune](https://github.com/aws/neptune-gremlin-client), un cliente Java Gremlin que conoce la topología del clúster y que distribuye de forma equitativa las conexiones y solicitudes entre un conjunto de instancias de un clúster de Neptune. [Esta publicación de blog](https://aws.amazon.com/blogs/database/load-balance-graph-queries-using-the-amazon-neptune-gremlin-client/) incluye un ejemplo de función de Lambda de Java que usa el cliente Gremlin para Amazon Neptune.
# Factores que pueden ralentizar los arranques en frío de las funciones de Lambda en Neptune Gremlin
La primera vez que se invoca una función de AWS Lambda se denomina arranque en frío. Existen varios factores que pueden aumentar la latencia de un arranque en frío:
+ **Asegúrese de asignar memoria suficiente a la función de Lambda.** La compilación durante un arranque en frío puede ser considerablemente más lenta en una función de Lambda que en EC2, ya que AWS Lambda asigna los ciclos de CPU [de forma lineal en proporción a la memoria](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) que se asigna a la función. Con 1769 MB de memoria, la función recibe el equivalente de una vCPU completa (un segundo de créditos de vCPU por segundo). El impacto de no asignar suficiente memoria para recibir ciclos de CPU adecuados es especialmente marcado en el caso de las funciones de Lambda de gran tamaño escritas en Java.
+ **Tenga en cuenta que [al habilitar la autenticación de bases de datos de IAM](iam-auth-enable.md) se puede ralentizar un arranque en frío.** La autenticación de base de datos de AWS Identity and Access Management (IAM) también puede ralentizar los arranques en frío, especialmente si la función de Lambda tiene que generar una nueva clave de firma. Esta latencia solo afecta al arranque en frío y no a las solicitudes posteriores, ya que una vez que la autenticación de la base de datos de IAM haya establecido las credenciales de conexión, Neptune solo validará periódicamente que siguen siendo válidas.