# Runtimes de instâncias gerenciadas do Lambda
O Lambda processa solicitações de forma diferente ao usar as instâncias gerenciadas do Lambda. Em vez de lidar com solicitações sequencialmente em cada ambiente de execução, as instâncias gerenciadas do Lambda processam várias solicitações simultaneamente em cada ambiente de execução. Essa mudança no modelo de execução significa que as funções que usam instâncias gerenciadas do Lambda precisam considerar a segurança de threads, o gerenciamento do estado e o isolamento do contexto, questões que não surgem no modelo de simultaneidade única do Lambda (padrão). Além disso, a implementação de multissimultaneidade varia entre os runtimes.
## Idiomas compatíveis
As instâncias gerenciadas do Lambda podem ser usadas com as seguintes linguagens de programação e runtimes:
+ **Java:** Java 21 e posteriores.
+ **Python:** Python 3.13 e posteriores.
+ **Node.js:** Node.js 22 e posteriores.
+ **.NET:** .NET 8 e posteriores.
+ **Rust:** com suporte usando o runtime exclusivo do sistema operacional `provided.al2023` e versões posteriores.
## Considerações específicas de cada linguagem
Cada linguagem de programação implementa a multiconcorrência de maneira diferente. Você precisa entender como a multisaimultaneidade é implementada na linguagem de programação escolhida para aplicar as melhores práticas de simultaneidade apropriadas.
**Java**
Usa um único processo com threads de sistema operacional para simultaneidade. Vários threads executam o método manipulador simultaneamente, exigindo um tratamento seguro do estado e dos recursos compartilhados.
**Python**
Usa vários processos do Python em que cada solicitação simultânea é executada em um processo separado. Isso protege contra a maioria dos problemas de simultaneidade, embora seja necessário cuidado com recursos compartilhados, como o diretório `/tmp`.
**Node.js**
Usa [threads de operador](https://nodejs.org/api/worker_threads.html) com execução assíncrona. As solicitações simultâneas são distribuídas entre os threads de operador, e cada thread de operador também pode lidar com solicitações simultâneas de forma assíncrona, exigindo tratamento seguro do estado e dos recursos compartilhados.
**.NET**
Usa tarefas do .NET com processamento assíncrono de várias solicitações simultâneas. Requer o manuseio seguro do estado e dos recursos compartilhados.
**Rust**
Utiliza um único processo com tarefas assíncronas implementadas por [Tokio](https://tokio.rs/). O manipulador deve ser `Clone` \$1 `Send`.
## Próximas etapas
Para obter informações detalhadas sobre cada runtime, consulte os tópicos a seguir:
+ [Runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ [Runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ [Runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ [.Runtime do .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ [Suporte ao Rust para instâncias gerenciadas do Lambda](lambda-managed-instances-rust.md)
# Runtime de Java para instâncias gerenciadas do Lambda
Para runtimes de Java, as instâncias gerenciadas do Lambda usam threads do sistema operacional para simultaneidade. O Lambda carrega seu objeto manipulador uma vez por ambiente de execução durante a inicialização e, em seguida, cria vários threads. Esses threads são executados paralelamente e exigem um tratamento seguro do estado e dos recursos compartilhados. Cada thread compartilha o mesmo objeto manipulador e quaisquer campos estáticos.
## 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 runtimes de Java, o padrão é 32 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. Esse valor também determina o número de threads usados pelo runtime de Java. 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 thread ao usar instâncias gerenciadas do Lambda como você faria em qualquer outro ambiente de vários threads. Como o objeto manipulador é compartilhado entre todas as threads de operador de runtime, 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 threads. Dependendo da biblioteca de conexão usada, isso pode não ser seguro para threads.
```
public class DBQueryHandler implements RequestHandler {
// Single connection shared across all threads - NOT SAFE
private static Connection connection;
public DBQueryHandler() {
this.connection = DriverManager.getConnection(jdbcUrl, username, password);
}
@Override
public String handleRequest(Object input, Context context) {
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery();
// Multiple threads using same connection causes issues
return result.toString();
}
}
```
Uma abordagem segura para threads é usar um grupo de conexões. No exemplo a seguir, o manipulador de funções recupera uma conexão do grupo. A conexão só é usada no contexto de uma única solicitação.
```
public class DBQueryHandler implements RequestHandler {
private static HikariDataSource dataSource;
public DBQueryHandler() {
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database");
dataSource = new HikariDataSource(config); // Create pool once per Lambda container
}
@Override
public String handleRequest(Object input, Context context) {
String query = "SELECT column_name FROM your_table LIMIT 10";
StringBuilder result = new StringBuilder("Data:\n");
// try-with-resources automatically calls close() on the connection,
// which returns it to the HikariCP pool (does NOT close the physical DB connection)
try (Connection connection = dataSource.getConnection();
PreparedStatement stmt = connection.prepareStatement(query);
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
result.append(rs.getString("column_name")).append("\n");
}
} catch (Exception e) {
context.getLogger().log("Error: " + e.getMessage());
return "Error";
}
return result.toString();
}
}
```
**Exemplo: coleções**
As coleções de Java padrão não são seguras para threads:
```
public class Handler implements RequestHandler {
private static List items = new ArrayList<>();
private static Map cache = new HashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Not thread-safe
cache.put("key", input); // Not thread-safe
return "Success";
}
}
```
Em vez disso, use coleções seguras para threads:
```
public class Handler implements RequestHandler {
private static final List items =
Collections.synchronizedList(new ArrayList<>());
private static final ConcurrentHashMap cache =
new ConcurrentHashMap<>();
@Override
public String handleRequest(Object input, Context context) {
items.add("list item"); // Thread-safe
cache.put("key", input); // Thread-safe
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 outro processo sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por thread ou 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](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o objeto `LambdaLogger` de `context.getLogger()`, o `requestId` é incluído automaticamente em cada entrada de log. Consulte para obter mais informações [Usar controles avançados de registro em log do Lambda com Java](java-logging.md#java-logging-advanced).
## Contexto da solicitação
O objeto `context` está vinculado ao thread da solicitação. O uso de `context.getAwsRequestId()` proporciona acesso com segurança de thread para acessar o ID da solicitação atual.
Use `context.getXrayTraceId()` para acessar o ID de rastreamento do X-Ray. Isso fornece acesso com segurança de thread 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.
Use `com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
Se você usar threads virtuais em seu programa ou criar threads durante a inicialização, precisará passar qualquer contexto de solicitação necessário para esses threads.
## 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 os threads.
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](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ AWS SDK para Java 2.0: versão 2.34.0 ou posterior
+ AWS X-Ray SDK para Java: versão 2.20.0 ou posterior
+ AWS Distro para OpenTelemetry - Instrumentação para Java: versão 2.20.0 ou posterior
+ Powertools para AWS Lambda (Java): versão 2.8.0 ou posterior
## Powertools para AWS Lambda (Java)
O Powertools para AWS Lambda (Java) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (Java)](https://github.com/aws-powertools/powertools-lambda-java).
## Próximas etapas
+ Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Analise o [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Runtime de Node.js para instâncias gerenciadas do Lambda
Para runtimes de Node.js, as instâncias gerenciadas do Lambda usam threads de operador com execução `async`/`await` para lidar com solicitações simultâneas. A inicialização da função ocorre uma vez por thread de operador. As invocações simultâneas são tratadas em duas dimensões: os threads de operador fornecem paralelismo entre vCPUs e a execução assíncrona fornece simultaneidade em cada thread. Cada solicitação simultânea tratada pelo mesmo thread de operador compartilha o mesmo objeto manipulador e estado global, exigindo tratamento seguro em várias solicitações simultâneas.
## Simultaneidade máxima
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 de Node.js, o padrão é 64 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.
Para o Node.js, o número de solicitações simultâneas que cada ambiente de execução pode processar é determinado pelo número de threads de operador e pela capacidade de cada thread de operador de processar solicitações simultâneas de forma assíncrona. O número padrão de threads de operador é determinado pelo número de vCPUs disponíveis, ou é possível configurar o número de threads de operador definindo a variável de ambiente `AWS_LAMBDA_NODEJS_WORKER_COUNT`. Recomendamos o uso de manipuladores de funções assíncronos, pois isso permite processar várias solicitações por thread de operador. Se seu manipulador de funções for síncrono, cada thread de operador só poderá processar uma única solicitação por vez.
## Funções de construção para multissimultaneidade
Com um manipulador de funções assíncrono, cada operador de runtime processa várias solicitações simultaneamente. Objetos globais serão compartilhados por várias solicitações simultâneas. Para objetos mutáveis, evite usar o estado global ou use `AsyncLocalStorage`.
Os clientes de SDK da AWS são seguros para assincronia e não exigem tratamento especial.
**Exemplo: estado global**
O código a seguir usa um objeto global que sofre mutação dentro do manipulador de funções. Isso não é seguro para uso assíncrono.
```
let state = {
currentUser: null,
requestData: null
};
export const handler = async (event, context) => {
state.currentUser = event.userId;
state.requestData = event.data;
await processData(state.requestData);
// state.currentUser might now belong to a different request
return { user: state.currentUser };
};
```
Inicializar o objeto `state` dentro do manipulador de funções evita o estado global compartilhado.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Exemplo: conexões de banco de dados**
O código a seguir usa um objeto cliente compartilhado que é compartilhado entre várias invocações. Dependendo da biblioteca de conexão usada, isso pode não ser seguro para simultaneidade.
```
const { Client } = require('pg');
// Single connection created at init time
const client = new Client({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
// Connect once during cold start
client.connect();
exports.handler = async (event) => {
// Multiple parallel invocations share this single connection = BAD
// With multi-concurrent Lambda, queries will collide
const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
Uma abordagem segura para simultaneidade é usar um grupo de conexões. O grupo usa uma conexão separada para cada consulta simultânea ao banco de dados.
```
const { Pool } = require('pg');
// Connection pool created at init time
const pool = new Pool({
host: process.env.DB_HOST,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
max: 20, // Max connections in pool
idleTimeoutMillis: 30000,
connectionTimeoutMillis: 2000
});
exports.handler = async (event) => {
// Pool gives each parallel invocation its own connection
const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]);
return {
statusCode: 200,
body: JSON.stringify(result.rows[0])
};
};
```
## Manipuladores baseados em retorno de chamada do Node.js 22
Ao usar o Node.js 22, não é possível usar um manipulador de funções baseado em retorno de chamada com instâncias gerenciadas do Lambda. Há suporte para manipuladores baseados em retorno de chamada apenas com funções do Lambda (padrão). Para runtimes do Node.js 24 e posteriores, os manipuladores de funções baseados em retorno de chamada estão obsoletos tanto para o Lambda (padrão) quanto para instâncias gerenciadas do Lambda.
Em vez disso, use um manipulador de funções `async` ao usar instâncias gerenciadas do Lambda. Para obter mais informações, consulte [Definição do manipulador de função do Lambda em Node.js](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
## 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 outro processo 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](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o logger `console`, o `requestId` é incluído automaticamente em cada entrada de log. Consulte para obter mais informações [Usar controles avançados de registro em log do Lambda com Node.js](nodejs-logging.md#node-js-logging-advanced).
Bibliotecas de registro em log populares de terceiros, como a [Winston](https://github.com/winstonjs/winston), geralmente incluem suporte para o uso do console para saída de logs.
## Contexto da solicitação
O uso de `context.awsRequestId` proporciona acesso com segurança de assincronia para acessar o ID da solicitação atual.
Use `context.xRayTraceId` 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.
Use `context.getRemainingTimeInMillis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por thread de operador. É possível visualizar ver entradas de log repetidas se sua função emitir logs durante a inicialização.
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. Funções do Lambda (padrão) com extensões também podem assinar o sinal SIGTERM usando.`process.on()`. Não há suporte para isso em funções que usam instâncias gerenciadas do Lambda, pois `process.on()` não pode ser usado com threads de operador. 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](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ AWS SDK para JavaScript v3: versão 3.933.0 ou posterior
+ AWS X-Ray SDK para Node.js: versão 3.12.0 ou posterior
+ AWS Distro para OpenTelemetry - Instrumentação para JavaScript: versão 0.8.0 ou posterior
+ Powertools para AWS Lambda (TypeScript): versão 2.29.0 ou posterior
## Powertools para AWS Lambda (TypeScript)
O Powertools para AWS Lambda (TypeScript) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (TypeScript)](https://github.com/aws-powertools/powertools-lambda-typescript).
## Próximas etapas
+ Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ Analise o [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Runtime de Python para instâncias gerenciadas do Lambda
O runtime do Lambda usa vários processos do Python para lidar com solicitações simultâneas. Cada solicitação simultânea é executada em um processo separado com seu próprio espaço de memória e inicialização. Cada processo lida com uma solicitação por vez, de forma síncrona. Os processos não compartilham memória diretamente, então variáveis globais, caches em nível de módulo e objetos singleton são isolados entre solicitações simultâneas.
## 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 runtimes de Python, o padrão é 16 solicitações simultâneas por vCPU, ou é possível configurar seu próprio valor. Esse valor também determina o número de processos usados pelo runtime de Java. 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.
**Importante**
Usar a simultaneidade baseada em processos significa que cada processo de operador de runtime executa sua própria inicialização. O uso total de memória é igual à memória por processo multiplicada pelo número de processos simultâneos. Se você estiver carregando grandes bibliotecas ou conjuntos de dados e tiver alta simultaneidade, ocupará uma grande quantidade de memória. De acordo com sua workload, talvez seja necessário ajustar a relação CPU/memória ou usar uma configuração de simultaneidade mais baixa para evitar exceder a memória disponível. É possível usar a métrica `MemoryUtilization` no CloudWatch para monitorar o consumo de memória.
## Funções de construção para multissimultaneidade
Devido ao modelo de multissimultaneidade baseado em processos, as funções de instâncias gerenciadas do Lambda que usam runtimes de Python não acessam recursos na memória simultaneamente a partir de várias invocações. Não é preciso aplicar práticas de codificação para segurança de simultaneidade na memória.
## 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 outro processo sobrescrever o arquivo. Para resolver isso, implemente o bloqueio de arquivos para arquivos compartilhados ou use nomes de arquivo exclusivos por processo ou 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](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Quando você usa o módulo `logging` da biblioteca padrão do Python no Lambda, 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 Python](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Contexto da solicitação
Use `context.aws_request_id` para acessar o ID da solicitação atual.
Com os runtimes de Python, é possível usar a variável de ambiente `_X_AMZN_TRACE_ID` para acessar o ID de rastreamento do X-Ray com instâncias gerenciadas do Lambda. O ID de rastreamento do X-Ray é propagado automaticamente ao usar o AWS SDK.
Use `context.get_remaining_time_in_millis()` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
## Inicialização e desligamento
A inicialização da função ocorre uma vez por processo. É possível visualizar ver entradas de log repetidas se sua função emitir logs durante a inicialização.
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](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ Powertools para AWS Lambda (Python): versão 3,23.0 ou posterior
## Powertools para AWS Lambda (Python)
O Powertools para AWS Lambda (Python) é compatível com as instâncias gerenciadas do Lambda e fornece utilitários para registro em log, rastreamento, métricas e muito mais. Para obter mais informações, consulte [Powertools para AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Próximas etapas
+ Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Analise o [runtime de .NET para instâncias gerenciadas do Lambda](lambda-managed-instances-dotnet-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# 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 items = new List();
private static Dictionary cache = new Dictionary();
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 items = new ConcurrentBag();
private static ConcurrentDictionary cache = new ConcurrentDictionary();
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](monitoring-logs.md#monitoring-cloudwatchlogs-advanced). 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. Consulte para obter mais informações [Uso de controles avançados de registro em log do Lambda com .NET](csharp-logging.md#csharp-logging-advanced).
## 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.
Use `ILambdaContext.RemainingTime` para detectar tempos limite. Consulte [Tratamento de erros e recuperação](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling) para obter mais informações.
## 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](lambda-runtime-environment.md).
## 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)](https://docs.aws.amazon.com/powertools/dotnet/) e [AWS Distro para OpenTelemetry - Instrumentação para DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) atualmente não oferecem suporte a instâncias gerenciadas do Lambda.
## Próximas etapas
+ Analise o [runtime de Java para instâncias gerenciadas do Lambda](lambda-managed-instances-java-runtime.md)
+ Analise o [runtime de Node.js para instâncias gerenciadas do Lambda](lambda-managed-instances-nodejs-runtime.md)
+ Analise o [runtime de Python para instâncias gerenciadas do Lambda](lambda-managed-instances-python-runtime.md)
+ Saiba mais sobre a [escalabilidade de instâncias gerenciadas do Lambda](lambda-managed-instances-scaling.md)
# Suporte ao Rust para instâncias gerenciadas do Lambda
## 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. Esta é uma configuração opcional, e o valor padrão no Rust é de 8 solicitações simultâneas por vCPU; você também pode definir seu próprio valor. Esse valor determina o número de tarefas da Tokio criadas pelo runtime e permanece fixo durante todo o tempo de vida do ambiente de execução. Cada operador lida com exatamente uma solicitação em andamento por vez, sem multiplexação por operador. 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 thread ao usar instâncias gerenciadas do Lambda como você faria em qualquer outro ambiente de vários threads. Como o objeto manipulador é compartilhado entre todas as threads de operador, 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.
Para habilitar o tratamento simultâneo de solicitações, adicione o sinalizador de recurso `concurrency-tokio` ao arquivo `Cargo.toml`.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
O ponto de entrada `lambda_runtime::run_concurrent(…)` deve ser chamado de dentro de um runtime da Tokio, normalmente fornecido pelo atributo `#[tokio::main]` em sua função principal. O fechamento do manipulador deve implementar [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html) \$1 [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html). Isso permite que o framework compartilhe seu manipulador entre várias tarefas assíncronas com segurança. Se esses limites não forem respeitados, seu código não será compilado.
Quando você precisar de um estado compartilhado entre invocações (um pool de bancos de dados, uma estrutura de configuração), envolva-o em [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) e clone `Arc` em cadainvocação.
Todos os clientes do AWS SDK para Rust são seguros contra concorrência e não exigem tratamento especial.
### Exemplo: cliente do AWS SDK
O exemplo abaixo usa um cliente do S3 para carregar um objeto em cada invocação. O cliente é clonado diretamente no fechamento sem `Arc`:
```
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let s3_client = aws_sdk_s3::Client::new(&config);
run_concurrent(service_fn(move |event: LambdaEvent| {
let s3_client = s3_client.clone(); // cheap clone, no Arc needed
async move {
s3_client.put_object()
.bucket(&event.payload.bucket)
.key(&event.payload.key)
.body(event.payload.body.into_bytes().into())
.send()
.await?;
Ok(Response { message: "uploaded".into() })
}
}))
.await
```
### Exemplo: grupos de conexão de banco de dados
Quando o manipulador precisar acessar um estado compartilhado, como um cliente e uma configuração, envolva-o em [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html) e clone `Arc` em cada invocação:
```
#[derive(Debug)]
struct AppState {
dynamodb_client: DynamoDbClient,
table_name: String,
cache_ttl: Duration,
}
let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
let state = Arc::new(AppState {
dynamodb_client: DynamoDbClient::new(&config),
table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"),
cache_ttl: Duration::from_secs(300),
});
run_concurrent(service_fn(move |event: LambdaEvent| {
let state = state.clone();
async move { handle(event, state).await }
}))
.await
```
## Diretório /tmp compartilhado
O diretório `/tmp` é compartilhado entre todas as chamadas simultâneas no mesmo ambiente de execução. Use nomes de arquivo exclusivos para cada chamada (por exemplo, inclua o ID da solicitação) ou implemente o bloqueio explícito de arquivos para evitar corrupção de dados.
## Registro em log
A intercalação de logs (entradas de logs de solicitações diferentes sendo intercaladas em logs) é normal em sistemas multissimultâneos. Funções do Lambda que utilizam Instâncias gerenciadas do Lambda oferecem suporte ao formato de log JSON estruturado por meio de [controles avançados de registro de logs](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) do Lambda. Esse formato inclui o `requestId`, permitindo que as entradas de log sejam correlacionadas a uma única solicitação. Consulte para obter mais informações [Implementar registro em log avançado com a caixa Tracing](rust-logging.md#rust-logging-tracing).
## Contexto da solicitação
O objeto `Context` é passado diretamente para cada invocação do manipulador. Use `event.context.request_id` para acessar o ID para a solicitação atual.
Use `event.context.xray_trace_id` para acessar o ID de rastreamento do X-Ray. 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 para Rust.
Use `event.context.deadline` para detectar tempos limite: ele contém o prazo de invocação em milissegundos.
## 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 por extensões como um gatilho para tarefas de limpeza, como a liberação de buffers. `lambda_runtime` oferece uma função auxiliar para simplificar a configuração do tratamento de sinais de desligamento ordenado, [https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html). 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](lambda-runtime-environment.md).
## Versões de dependências
As instâncias gerenciadas do Lambda exigem as versões mínimas de pacotes a seguir:
+ `lambda_runtime`: versão 1.1.1 ou posterior, com o recurso `concurrency-tokio` habilitado
+ A versão mínima compatível do Rust (MSRV) é a 1.84.0.