Runtime do .NET para instâncias gerenciadas do Lambda - AWS Lambda
Configuração de simultaneidadeFunções de construção para multissimultaneidadeDiretório /tmp compartilhadoRegistro em logContexto da solicitaçãoInicialização e desligamentoVersões de dependênciasPowertools para AWS Lambda (.NET)Próximas etapas

Runtime do .NET para instâncias gerenciadas do Lambda

Para runtimes do .NET, as instâncias gerenciadas do Lambda usam um único processo .NET por ambiente de execução. Várias solicitações simultâneas são processadas usando tarefas do .NET.

Configuração de simultaneidade

O número máximo de solicitações simultâneas que o Lambda envia para cada ambiente de execução é controlado pela definição PerExecutionEnvironmentMaxConcurrency da configuração da função. Essa é uma definição opcional e o valor padrão varia de acordo com o runtime. Para os runtimes do .NET, o padrão é 32 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. O Lambda ajusta automaticamente o número de solicitações simultâneas até o máximo configurado com base na capacidade de cada ambiente de execução de absorver essas solicitações.

Funções de construção para multissimultaneidade

É necessário aplicar as mesmas práticas de segurança de simultaneidade ao usar instâncias gerenciadas do Lambda como você faria em qualquer outro ambiente multissimultâneo. Como o objeto manipulador é compartilhado entre todas as tarefas, qualquer estado mutável deve ser seguro para threads. Isso inclui coleções, conexões de banco de dados e quaisquer objetos estáticos que sejam modificados durante o processamento da solicitação.

Os clientes de SDK da AWS são seguros para threads e não exigem tratamento especial.

Exemplo: grupos de conexão de banco de dados

O código a seguir usa um objeto de conexão de banco de dados estático que é compartilhado entre solicitações simultâneas. O objeto SqlConnection não é seguro para threads.

public class DBQueryHandler
{
    // Single connection shared across threads - NOT SAFE
    private SqlConnection connection;

    public DBQueryHandler()
    {
        connection = new SqlConnection("your-connection-string-here");
        connection.Open();
    }

    public string Handle(object input, ILambdaContext context)
    {
        using var cmd = connection.CreateCommand();
        cmd.CommandText = "SELECT ..."; // your query

        using var reader = cmd.ExecuteReader();

        ...
    }
}

Para resolver isso, use uma conexão separada para cada solicitação, extraída de um grupo de conexões. Os provedores de ADO.NET como o Microsoft.Data.SqlClient oferecem suporte automático a grupos de conexões quando o objeto de conexão é aberto.

public class DBQueryHandler
{
    public DBQueryHandler()
    {
    }

    public string Handle(object input, ILambdaContext context)
    {
        using var connection = new SqlConnection("your-connection-string-here");
        connection.Open();
        using var cmd = connection.CreateCommand();
        cmd.CommandText = "SELECT ..."; // your query

        using var reader = cmd.ExecuteReader();

        ...
    }
}

Exemplo: coleções

As coleções .NET padrão não são de threads seguros:

public class Handler
{
    private static List<string> items = new List<string>();
    private static Dictionary<string, object> cache = new Dictionary<string, object>();

    public string FunctionHandler(object input, ILambdaContext context)
    {
        items.Add(context.AwsRequestId);
        cache["key"] = input;

        return "Success";
    }
}

Use coleções do namespace System.Collections.Concurrent para segurança de simultaneidade:

public class Handler
{
    private static ConcurrentBag<string> items = new ConcurrentBag<string>();
    private static ConcurrentDictionary<string, object> cache = new ConcurrentDictionary<string, object>();

    public string FunctionHandler(object input, ILambdaContext context)
    {
        items.Add(context.AwsRequestId);
        cache["key"] = input;

        return "Success";
    }
}

Diretório /tmp compartilhado

O diretório /tmp é compartilhado entre todas as solicitações simultâneas no ambiente de execução. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados, por exemplo, se outra solicitação sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por solicitação para evitar conflitos. Lembre-se de limpar arquivos desnecessários para evitar o esgotamento do espaço disponível.

Registro em log

A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos. As funções que usam instâncias gerenciadas do Lambda sempre usam o formato de log de JSON estruturado introduzido com controles de registro em log avançados. Esse formato inclui o requestId, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o objeto context.Logger para gerar logs, o requestId é incluído automaticamente em cada entrada de log. Para obter mais informações, consulte Uso de controles avançados de registro em log do Lambda com .NET.

Contexto da solicitação

Use a propriedade context.AwsRequestId para acessar o ID da solicitação atual.

Use a propriedade context.TraceId para acessar o ID de rastreamento do X-Ray. Isso fornece acesso com segurança de simultaneidade ao ID de rastreamento da solicitação atual. O Lambda não oferece suporte à variável de ambiente _X_AMZN_TRACE_ID com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK.

Inicialização e desligamento

A inicialização da função ocorre uma vez por ambiente de execução. Os objetos criados durante a inicialização são compartilhados entre as solicitações.

Para as funções do Lambda com extensões, o ambiente de execução emite um sinal SIGTERM durante o desligamento. Esse sinal é usado pelas extensões para acionar tarefas de limpeza, como descarregar buffers. É possível se inscrever em eventos SIGTERM para acionar tarefas de limpeza de funções, como fechar conexões de banco de dados. Para saber mais sobre o ciclo de vida do ambiente de execução, consulte Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda.

Versões de dependências

As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:

  • Amazon.Lambda.Core: versão 2.7.1 ou posterior

  • Amazon.Lambda.RuntimeSupport: versão 1.14.1 ou posterior

  • OpenTelemetry.Instrumentation.AWSLambda: versão 1.14.0 ou posterior

  • AWSXRayRecorder.Core: versão 2.16.0 ou posterior

  • AWSSDK.Core: versão 4.0.0.32 ou posterior

Powertools para AWS Lambda (.NET)

Powertools para AWS Lambda (.NET) e AWS Distro para OpenTelemetry - Instrumentação para DotNet atualmente não oferecem suporte a instâncias gerenciadas do Lambda.

Próximas etapas