Maximizar a performance do SnapStart do Lambda

Ajuste de performance

Para maximizar os benefícios do SnapStart, recomendamos carregar previamente as classes que contribuem para a latência de startup em seu código de inicialização, em vez de no manipulador de função. Isso remove a latência associada ao carregamento pesado de classes do caminho de invocação, otimizando a performance de startup com o SnapStart.

Se não for possível carregar previamente as classes durante a inicialização, recomendamos carregar previamente as classes com invocações fictícias. Para fazer isso, atualize o código do manipulador de função, conforme mostrado no exemplo a seguir da função “pet store” no repositório GitHub do AWS Labs.

private static SpringLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler;
  static {
      try {
          handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class);

          // Use the onStartup method of the handler to register the custom filter
          handler.onStartup(servletContext -> {
              FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class);
              registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*");
          });

          // Send a fake Amazon API Gateway request to the handler to load classes ahead of time
          ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity();
          identity.setApiKey("foo");
          identity.setAccountId("foo");
          identity.setAccessKey("foo");

          AwsProxyRequestContext reqCtx = new AwsProxyRequestContext();
          reqCtx.setPath("/pets");
          reqCtx.setStage("default");
          reqCtx.setAuthorizer(null);
          reqCtx.setIdentity(identity);

          AwsProxyRequest req = new AwsProxyRequest();
          req.setHttpMethod("GET");
          req.setPath("/pets");
          req.setBody("");
          req.setRequestContext(reqCtx);

          Context ctx = new TestContext();
          handler.proxy(req, ctx);


      } catch (ContainerInitializationException e) {
          // if we fail here. We re-throw the exception to force another cold start
          e.printStackTrace();
          throw new RuntimeException("Could not initialize Spring framework", e);
      }
  }

Práticas recomendadas de rede

O estado das conexões que a função estabelece durante a fase de inicialização não é garantido quando o Lambda retoma a função de um snapshot. Na maioria dos casos, as conexões de rede que um SDK da AWS estabelece são retomadas automaticamente. Para outras conexões, recomendamos as práticas recomendadas a seguir.

Restabelecer as conexões de rede

Sempre restabeleça as conexões de rede quando a função for retomada de um snapshot. Recomendamos restabelecer as conexões de rede no manipulador de função. Como alternativa, você pode usar um hook de runtime afterRestore.

Não usar o nome do host como um identificador exclusivo do ambiente de execução

Recomendamos não usar o hostname para identificar o ambiente de execução como um nó ou um contêiner exclusivo em suas aplicações. Com o SnapStart, um único snapshot é usado como estado inicial para diversos ambientes de execução, e todos os ambientes de execução retornam o mesmo valor do hostname para InetAddress.getLocalHost(). Para aplicações que requerem uma identidade de ambiente de execução ou um valor do hostname exclusivo, recomendamos gerar um ID exclusivo no manipulador de função. Como alternativa, use um hook de runtime afterRestore para gerar um ID exclusivo e, em seguida, use o ID exclusivo como identificador para o ambiente de execução.

Evitar vincular conexões a portas de origem fixas

Recomendamos evitar vincular conexões de rede a portas de origem fixas. As conexões são restabelecidas quando uma função é retomada de um snapshot, e as conexões de rede vinculadas a uma porta de origem fixa podem apresentar falhas.

Evitar usar o cache do DNS Java

As funções do Lambda já armazenam as respostas de DNS em cache. Se você usar outro cache DNS com o SnapStart, poderá experimentar tempos limite de conexão quando a função for retomada de um snapshot.

A classe java.util.logging.Logger pode habilitar indiretamente o cache do DNS da JVM. Para substituir as configurações padrão, defina networkaddress.cache.ttl como 0 antes de inicializar o logger. Exemplo:

public class MyHandler {
  // first set TTL property
  static{
   java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
  }
 // then instantiate logger
  var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class);
}

Para evitar falhas UnknownHostException no runtime do Java 11, recomendamos definir networkaddress.cache.negative.ttl como 0. Em runtimes do Java 17 e versões posteriores, essa etapa não é necessária. Você pode definir essa propriedade para uma função do Lambda com a variável de ambiente AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0.

Desabilitar o cache do DNS da JVM não desabilita o cache do DNS gerenciado do Lambda.