Gerenciar conexões do WebSocket do Gremlin em funções do AWS Lambda
Se você usar uma variante da linguagem Gremlin para consultar o Neptune, o driver se conectará ao banco de dados usando uma conexão do WebSocket. Os WebSockets são projetados para ser compatíveis com cenários de conexão cliente-servidor de longa duração. O AWS Lambda, por outro lado, foi projetado para oferecer compatibilidade com execuções relativamente curtas e sem estado. Essa incompatibilidade na filosofia de design pode causar alguns problemas inesperados ao usar o Lambda para consultar o Neptune.
Uma função do AWS Lambda é executada em um contexto de execução que isola a função de outras funções. O contexto de execução é criado na primeira vez que a função é invocada e pode ser reutilizado para invocações subsequentes da mesma função.
No entanto, qualquer contexto de execução nunca é usado para lidar com várias invocações simultâneas da função. Se a função for invocada simultaneamente por vários clientes, o Lambda criará um contexto de execução adicional para cada instância da função. Todos esses novos contextos de execução podem, por sua vez, ser reutilizados para invocações subsequentes da função.
Em algum momento, o Lambda recicla contextos de execução, principalmente se eles permanecerem inativos por algum tempo. O AWS Lambda expõe o ciclo de vida do contexto de execução, incluindo as fases Init, Invoke e Shutdown por meio de extensões do Lambda. Usando essas extensões, você pode escrever um código que limpe recursos externos, como conexões de banco de dados, quando o contexto de execução é reciclado.
Uma prática recomendada comum é abrir a conexão do banco de dados fora da função de manipulador do Lambda para que ela possa ser reutilizada com cada chamada do manipulador. Se a conexão com o banco de dados cair em algum momento, você poderá se reconectar de dentro do manipulador. No entanto, com essa abordagem, existe o perigo de vazamentos de conexão. Se uma conexão ociosa permanecer aberta por muito tempo após a destruição de um contexto de execução, cenários de invocação do Lambda intermitentes poderão gradualmente vazar conexões e esgotar os recursos do banco de dados.
Os limites de conexão e os tempos limite de conexão do Neptune mudaram com as versões mais recentes do mecanismo. Anteriormente, cada instância suportava até sessenta mil conexões do WebSocket. Agora, o número máximo de conexões simultâneas do WebSocket por instância do Neptune varia de acordo com o tipo de instância.
Além disso, a partir da versão 1.0.3.0 do mecanismo, o Neptune reduziu o tempo limite de inatividade das conexões de uma hora para cerca de vinte minutos. Se um cliente não fechar uma conexão, ela será fechada automaticamente após um tempo limite de inatividade de 20 a 25 minutos. O AWS Lambda não documenta os tempos de vida do contexto de execução, mas experiências demonstram que o novo tempo limite de conexão do Neptune se alinha bem com os tempos limite do contexto de execução inativo do Lambda. No momento em que um contexto de execução inativo é reciclado, há uma boa chance de a conexão já ter sido fechada pelo Neptune ou ser fechada logo depois.
