Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Laufzeiten von Lambda Managed Instances
Lambda verarbeitet Anfragen anders, wenn Lambda Managed Instances verwendet werden. Anstatt Anfragen nacheinander in jeder Ausführungsumgebung zu bearbeiten, verarbeiten Lambda Managed Instances mehrere Anfragen gleichzeitig in jeder Ausführungsumgebung. Diese Änderung des Ausführungsmodells bedeutet, dass Funktionen, die Lambda Managed Instances verwenden, Thread-Sicherheit, Statusverwaltung und Kontextisolation berücksichtigen müssen — Aspekte, die im Lambda-Modell (Standard) mit nur einer Parallelität nicht auftreten. Darüber hinaus variiert die Implementierung mehrerer Parallelitäten je nach Laufzeit.
## Unterstützte Sprachen
Lambda Managed Instances können mit den folgenden Programmiersprachen und Laufzeiten verwendet werden:
+ **Java:** Java 21 und höher.
+ **Python:** Python 3.13 und höher.
+ **Node.js:** Node.js 22 und höher.
+ **.NET:** .NET 8 und höher.
+ **Rust: Wird** mit der reinen Betriebssystem-Runtime `provided.al2023` und höher unterstützt.
## Sprachspezifische Überlegungen
Jede Programmiersprache implementiert Multiparallelität unterschiedlich. Sie müssen verstehen, wie Multiparallelität in der von Ihnen gewählten Programmiersprache implementiert wird, um die entsprechenden Best Practices für Parallelität anwenden zu können.
**Java**
Verwendet einen einzigen Prozess mit Betriebssystem-Threads für Parallelität. Mehrere Threads führen die Handler-Methode gleichzeitig aus, was eine threadsichere Behandlung von Status- und gemeinsam genutzten Ressourcen erfordert.
**Python**
Verwendet mehrere Python-Prozesse, bei denen jede gleichzeitige Anforderung in einem separaten Prozess ausgeführt wird. Dies schützt vor den meisten Parallelitätsproblemen, obwohl bei gemeinsam genutzten Ressourcen wie dem `/tmp` Verzeichnis Vorsicht geboten ist.
**Node.js**
Verwendet [Worker-Threads](https://nodejs.org/api/worker_threads.html) mit asynchroner Ausführung. Gleichzeitige Anfragen werden über Worker-Threads verteilt, und jeder Worker-Thread kann gleichzeitige Anfragen auch asynchron verarbeiten, was eine sichere Handhabung von Status- und gemeinsam genutzten Ressourcen erfordert.
**.NET**
Verwendet .NET-Aufgaben mit asynchroner Verarbeitung mehrerer gleichzeitiger Anfragen. Erfordert den sicheren Umgang mit staatlichen und gemeinsam genutzten Ressourcen.
**Rust**
Verwendet einen einzigen Prozess mit asynchronen Aufgaben, die von [Tokio](https://tokio.rs/) unterstützt werden. Der Handler muss \$1 sein. `Clone` `Send`
## Nächste Schritte
Ausführliche Informationen zu den einzelnen Laufzeitumgebungen finden Sie in den folgenden Themen:
+ [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ [Laufzeit von Node.js für verwaltete Lambda-Instanzen](lambda-managed-instances-nodejs-runtime.md)
+ [Python-Laufzeit für verwaltete Lambda-Instanzen](lambda-managed-instances-python-runtime.md)
+ [.NET-Laufzeit für verwaltete Lambda-Instanzen](lambda-managed-instances-dotnet-runtime.md)
+ [Rust-Unterstützung für Lambda Managed Instances](lambda-managed-instances-rust.md)
# Java-Laufzeit für Lambda Managed Instances
Für Java-Laufzeiten verwenden Lambda Managed Instances Betriebssystem-Threads für Parallelität. Lambda lädt Ihr Handler-Objekt während der Initialisierung einmal pro Ausführungsumgebung und erstellt dann mehrere Threads. Diese Threads werden parallel ausgeführt und erfordern eine threadsichere Behandlung von Status- und gemeinsam genutzten Ressourcen. Jeder Thread verwendet dasselbe Handler-Objekt und alle statischen Felder.
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Java-Laufzeiten ist die Standardeinstellung 32 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt auch die Anzahl der Threads, die von der Java-Laufzeit verwendet werden. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
## Erstellung von Funktionen für Mehrfachparallelität
Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Thread-Sicherheitspraktiken anwenden wie in jeder anderen Multithread-Umgebung. Da das Handler-Objekt von allen Runtime-Worker-Threads gemeinsam genutzt wird, muss jeder veränderbare Status threadsicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.
AWS SDK-Clients sind Thread-sicher und erfordern keine besondere Behandlung.
**Beispiel: Datenbank-Verbindungspools**
Der folgende Code verwendet ein statisches Datenbankverbindungsobjekt, das von Threads gemeinsam genutzt wird. Abhängig von der verwendeten Verbindungsbibliothek ist dies möglicherweise nicht threadsicher.
```
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();
}
}
```
Ein threadsicherer Ansatz besteht darin, einen Verbindungspool zu verwenden. Im folgenden Beispiel ruft der Funktionshandler eine Verbindung aus dem Pool ab. Die Verbindung wird nur im Kontext einer einzelnen Anfrage verwendet.
```
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();
}
}
```
**Beispiel: Sammlungen**
Standard-Java-Sammlungen sind nicht threadsicher:
```
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";
}
}
```
Verwenden Sie stattdessen Thread-sichere Sammlungen:
```
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";
}
}
```
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Thread oder pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen werden in Protokollen verschachtelt) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal.
Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `LambdaLogger` Objekt aus `context.getLogger()` verwenden, `requestId` ist es automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit Java](java-logging.md#java-logging-advanced).
## Kontext anfordern
Das `context` Objekt ist an den Anforderungsthread gebunden. `context.getAwsRequestId()`Die Verwendung ermöglicht einen threadsicheren Zugriff auf die Anforderungs-ID für die aktuelle Anfrage.
Wird verwendet`context.getXrayTraceId()`, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen threadsicheren Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
Wenn Sie in Ihrem Programm virtuelle Threads verwenden oder während der Initialisierung Threads erstellen, müssen Sie den erforderlichen Anforderungskontext an diese Threads übergeben.
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Threads gemeinsam genutzt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ AWS SDK for Java 2.0: Version 2.34.0 oder höher
+ AWS X-Ray SDK for Java: Version 2.20.0 oder höher
+ AWS Distribution für OpenTelemetry — Instrumentation für Java: Version 2.20.0 oder höher
+ Powertools für AWS Lambda (Java): Version 2.8.0 oder höher
## Powertools für AWS Lambda (Java)
Powertools for AWS Lambda (Java) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda (Java)](https://github.com/aws-powertools/powertools-lambda-java).
## Nächste Schritte
+ Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md)
+ Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md)
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# Laufzeit von Node.js für verwaltete Lambda-Instanzen
Für Laufzeiten von Node.js verwendet Lambda Managed Instances Worker-Threads mit`async`/`await`-basierter Ausführung, um gleichzeitige Anfragen zu verarbeiten. Die Funktionsinitialisierung erfolgt einmal pro Worker-Thread. Gleichzeitige Aufrufe werden in zwei Dimensionen verarbeitet: Worker-Threads sorgen für Parallelität in VCPUs, und asynchrone Ausführung sorgt für Parallelität innerhalb jedes Threads. Jede gleichzeitige Anforderung, die von demselben Worker-Thread bearbeitet wird, verwendet dasselbe Handler-Objekt und denselben globalen Status, sodass eine sichere Behandlung bei mehreren gleichzeitigen Anfragen erforderlich ist.
## Maximale Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Laufzeiten von Node.js sind standardmäßig 64 gleichzeitige Anfragen pro vCPU festgelegt, oder Sie können Ihren eigenen Wert konfigurieren. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
Für Node.js wird die Anzahl der gleichzeitigen Anfragen, die jede Ausführungsumgebung verarbeiten kann, durch die Anzahl der Worker-Threads und die Kapazität jedes Worker-Threads bestimmt, gleichzeitige Anfragen asynchron zu verarbeiten. Die Standardanzahl von Worker-Threads wird durch die Anzahl der CPUs verfügbaren V bestimmt. Sie können die Anzahl der Worker-Threads auch konfigurieren, indem Sie die `AWS_LAMBDA_NODEJS_WORKER_COUNT` Umgebungsvariable festlegen. Wir empfehlen die Verwendung von asynchronen Funktionshandlern, da dies die Verarbeitung mehrerer Anfragen pro Worker-Thread ermöglicht. Wenn Ihr Funktionshandler synchron ist, kann jeder Worker-Thread jeweils nur eine einzelne Anfrage verarbeiten.
## Funktionen für Mehrfachparallelität erstellen
Mit einem asynchronen Funktionshandler verarbeitet jeder Runtime-Worker mehrere Anfragen gleichzeitig. Globale Objekte werden von mehreren gleichzeitigen Anfragen gemeinsam genutzt. Vermeiden Sie bei veränderlichen Objekten die Verwendung von global state or use. `AsyncLocalStorage`
AWS SDK-Clients sind asynchron-sicher und erfordern keine besondere Behandlung.
**Beispiel: Globaler Status**
Der folgende Code verwendet ein globales Objekt, das innerhalb des Funktionshandlers mutiert ist. Das ist nicht asynchron-sicher.
```
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 };
};
```
Durch die Initialisierung des `state` Objekts innerhalb des Funktionshandlers wird ein gemeinsamer globaler Status vermieden.
```
export const handler = async (event, context) => {
let state = {
currentUser: event.userId,
requestData: event.data
};
await processData(state.requestData);
return { user: state.currentUser };
};
```
**Beispiel: Datenbankverbindungen**
Der folgende Code verwendet ein gemeinsames Client-Objekt, das von mehreren Aufrufen gemeinsam genutzt wird. Je nach verwendeter Verbindungsbibliothek ist dies möglicherweise nicht sicher für Parallelität.
```
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])
};
};
```
Ein Ansatz, der die Parallelität sicherstellt, besteht darin, einen Verbindungspool zu verwenden. Der Pool verwendet für jede gleichzeitige Datenbankabfrage eine separate Verbindung.
```
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])
};
};
```
## Node.js 22 Callback-basierte Handler
Wenn Sie Node.js 22 verwenden, können Sie keinen Callback-basierten Funktionshandler mit Lambda Managed Instances verwenden. Callback-basierte Handler werden nur für Lambda-Funktionen (Standard) unterstützt. Für Laufzeiten von Node.js 24 und höher sind Callback-basierte Funktionshandler sowohl für Lambda (Standard) als auch für Lambda Managed Instances veraltet.
Verwenden Sie stattdessen einen `async` Funktionshandler, wenn Sie Lambda Managed Instances verwenden. Weitere Informationen finden Sie unter [Definieren des Lambda-Funktionshandlers in Node.js](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html).
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge einer einzelnen Anfrage zugeordnet werden können. Wenn Sie den `console` Logger verwenden, `requestId` ist er automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit Node.js](nodejs-logging.md#node-js-logging-advanced).
Beliebte Protokollierungsbibliotheken von Drittanbietern, wie [Winston](https://github.com/winstonjs/winston), unterstützen in der Regel die Verwendung der Konsole für die Protokollausgabe.
## Kontext anfordern
`context.awsRequestId`Die Verwendung ermöglicht einen asynchronen Zugriff auf die Anforderungs-ID für die aktuelle Anfrage.
Wird verwendet`context.xRayTraceId`, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen parallelen Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`context.getRemainingTimeInMillis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Worker-Thread. Möglicherweise werden Protokolleinträge wiederholt, wenn Ihre Funktion während der Initialisierung Protokolle ausgibt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Lambda-Funktionen (Standard) mit Erweiterungen können das SIGTERM-Signal auch abonnieren, indem `process.on()` Dies wird für Funktionen, die Lambda Managed Instances verwenden, nicht unterstützt, da es `process.on()` nicht mit Worker-Threads verwendet werden kann. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ AWS SDK für JavaScript v3: Version 3.933.0 oder höher
+ AWS X-Ray SDK für Node.js: Version 3.12.0 oder höher
+ AWS Distribution für OpenTelemetry — Instrumentierung für JavaScript: Version 0.8.0 oder höher
+ Powertools für AWS Lambda (TypeScript): Version 2.29.0 oder höher
## Elektrowerkzeuge für AWS Lambda () TypeScript
Powertools for AWS Lambda (TypeScript) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda () TypeScript](https://github.com/aws-powertools/powertools-lambda-typescript).
## Nächste Schritte
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md)
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# Python-Laufzeit für verwaltete Lambda-Instanzen
Die Lambda-Laufzeit verwendet mehrere Python-Prozesse, um gleichzeitige Anfragen zu verarbeiten. Jede gleichzeitige Anforderung wird in einem separaten Prozess mit eigenem Speicherplatz und eigener Initialisierung ausgeführt. Jeder Prozess verarbeitet synchron jeweils eine Anfrage. Prozesse teilen sich den Speicher nicht direkt, sodass globale Variablen, Caches auf Modulebene und Singleton-Objekte zwischen gleichzeitigen Anfragen isoliert werden.
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Python-Laufzeiten ist die Standardeinstellung 16 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt auch die Anzahl der Prozesse, die von der Python-Laufzeit verwendet werden. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
**Wichtig**
Die Verwendung prozessbasierter Parallelität bedeutet, dass jeder Runtime-Worker-Prozess seine eigene Initialisierung durchführt. Die gesamte Speicherbelegung entspricht dem Arbeitsspeicher pro Prozess multipliziert mit der Anzahl gleichzeitiger Prozesse. Wenn Sie große Bibliotheken oder Datensätze laden und über eine hohe Parallelität verfügen, haben Sie einen großen Speicherbedarf. Je nach Arbeitslast müssen Sie möglicherweise Ihr CPU-to-memory Verhältnis anpassen oder eine niedrigere Parallelitätseinstellung verwenden, um eine Überschreitung des verfügbaren Speichers zu vermeiden. Sie können die `MemoryUtilization` Metrik verwenden CloudWatch , um den Speicherverbrauch zu verfolgen.
## Erstellung von Funktionen für mehrere Parallelitäten
Aufgrund des prozessbasierten Multi-Concurrency-Modells greifen Lambda Managed Instances-Funktionen, die Python-Laufzeiten verwenden, bei mehreren Aufrufen nicht gleichzeitig auf speicherinterne Ressourcen zu. Sie müssen keine Codierungspraktiken anwenden, um die Sicherheit der Parallelität im Speicher zu gewährleisten.
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Prozess oder pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal.
Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `logging` Modul aus der Python-Standardbibliothek in Lambda verwenden, `requestId` ist das automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter [Erweiterte Lambda-Protokollierungssteuerelemente mit Python verwenden](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced).
## Kontext anfordern
Wird verwendet`context.aws_request_id`, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.
Bei Python-Laufzeiten können Sie die `_X_AMZN_TRACE_ID` Umgebungsvariable verwenden, um mit Lambda Managed Instances auf die X-Ray-Trace-ID zuzugreifen. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`context.get_remaining_time_in_millis()`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisierung und Herunterfahren
Die Initialisierung der Funktion erfolgt einmal pro Prozess. Möglicherweise werden Protokolleinträge wiederholt, wenn Ihre Funktion während der Initialisierung Protokolle ausgibt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:
+ Powertools für AWS Lambda (Python): Version 3.23.0 oder höher
## Powertools für AWS Lambda (Python)
Powertools for AWS Lambda (Python) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter [Powertools for AWS Lambda (Python)](https://github.com/aws-powertools/powertools-lambda-python).
## Nächste Schritte
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md)
+ [.NET-Laufzeit für Lambda Managed Instances](lambda-managed-instances-dotnet-runtime.md) überprüfen
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# .NET-Laufzeit für verwaltete Lambda-Instanzen
Für .NET-Laufzeiten verwenden Lambda Managed Instances einen einzigen .NET-Prozess pro Ausführungsumgebung. Mithilfe von.NET-Aufgaben werden mehrere Anfragen gleichzeitig verarbeitet.
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für .NET-Laufzeiten ist die Standardeinstellung 32 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
## Erstellung von Funktionen für Mehrfachparallelität
Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Sicherheitspraktiken für Parallelität anwenden wie in jeder anderen Umgebung mit mehreren gleichzeitigen Vorgängen. Da das Handler-Objekt von allen Tasks gemeinsam genutzt wird, muss jeder veränderbare Status Thread-sicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.
AWS SDK-Clients sind Thread-sicher und erfordern keine besondere Behandlung.
**Beispiel: Datenbank-Verbindungspools**
Der folgende Code verwendet ein statisches Datenbankverbindungsobjekt, das von mehreren gleichzeitigen Anfragen gemeinsam genutzt wird. Das `SqlConnection` Objekt ist nicht threadsicher.
```
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();
...
}
}
```
Um dieses Problem zu lösen, verwenden Sie für jede Anfrage eine separate Verbindung, die aus einem Verbindungspool stammt. ADO.NET-Anbieter unterstützen beispielsweise `Microsoft.Data.SqlClient` automatisch das Verbindungspooling, wenn das Verbindungsobjekt geöffnet wird.
```
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();
...
}
}
```
**Beispiel: Sammlungen**
Standard-.NET-Sammlungen sind nicht threadsicher:
```
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";
}
}
```
Verwenden Sie aus Sicherheitsgründen Sammlungen aus dem `System.Collections.Concurrent` Namespace:
```
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";
}
}
```
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn eine andere Anforderung die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen, die in Protokollen verschachtelt werden) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) eingeführt wurde. Dieses Format beinhaltet die`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das `context.Logger` Objekt zum Generieren von Protokollen verwenden, `requestId` wird es automatisch in jeden Protokolleintrag aufgenommen. Weitere Informationen finden Sie unter[Verwenden von Lambda-Optionen für die erweiterte Protokollierung mit .NET](csharp-logging.md#csharp-logging-advanced).
## Kontext anfordern
Verwenden Sie die `context.AwsRequestId` Eigenschaft, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.
Verwenden Sie die `context.TraceId` Eigenschaft, um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen parallelen Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.
Wird verwendet`ILambdaContext.RemainingTime`, um Timeouts zu erkennen. Weitere Informationen finden Sie unter [Fehlerbehandlung und Wiederherstellung](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling).
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Anfragen gemeinsam genutzt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Für Lambda Managed Instances sind die folgenden Mindestpaketversionen erforderlich:
+ Amazon.Lambda.Core: Version 2.7.1 oder höher
+ Amazon.Lambda. RuntimeSupport: Version 1.14.1 oder höher
+ OpenTelemetry. Instrumentierung. AWSLambda: Version 1.14.0 oder höher
+ AWSXRayRecorder.Core: Version 2.16.0 oder höher
+ AWSSDK.Core: Version 4.0.0.32 oder höher
## Powertools für AWS Lambda (.NET)
[Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) und [AWS Distro for OpenTelemetry - Instrumentation for](https://github.com/aws-observability/aws-otel-dotnet-instrumentation) unterstützen DotNet derzeit keine Lambda Managed Instances.
## Nächste Schritte
+ Überprüfen Sie die [Java-Laufzeit für Lambda Managed Instances](lambda-managed-instances-java-runtime.md)
+ Überprüfen Sie die [Laufzeit von Node.js für Lambda Managed Instances](lambda-managed-instances-nodejs-runtime.md)
+ Überprüfen Sie die [Python-Laufzeit für Lambda Managed Instances](lambda-managed-instances-python-runtime.md)
+ Erfahren Sie mehr über die [Skalierung von Lambda Managed Instances](lambda-managed-instances-scaling.md)
# Rust-Unterstützung für Lambda Managed Instances
## Konfiguration der Parallelität
Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die `PerExecutionEnvironmentMaxConcurrency` Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert für Rust ist 8 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt die Anzahl der Tokio-Aufgaben, die von der Laufzeit ausgelöst werden, und ist für die gesamte Lebensdauer der Ausführungsumgebung statisch. Jeder Worker bearbeitet jeweils genau eine In-Flight-Anfrage, ohne Multiplexing pro Mitarbeiter. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.
## Erstellung von Funktionen für Mehrfachparallelität
Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Thread-Sicherheitspraktiken anwenden wie in jeder anderen Multithread-Umgebung. Da das Handler-Objekt von allen Worker-Threads gemeinsam genutzt wird, muss jeder veränderbare Status Thread-sicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.
Um die gleichzeitige Bearbeitung von Anfragen zu aktivieren, fügen Sie Ihrer `Cargo.toml` Datei das `concurrency-tokio` Feature-Flag hinzu.
```
[dependencies]
lambda_runtime = { version = "1", features = ["concurrency-tokio"] }
```
Der `lambda_runtime::run_concurrent(…)` Einstiegspunkt muss innerhalb einer Tokio-Laufzeit aufgerufen werden, die in der Regel durch das `#[tokio::main]` Attribut Ihrer Hauptfunktion bereitgestellt wird. Ihr Handler-Closure muss \$1 implementieren [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html). [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html) Auf diese Weise kann das Framework Ihren Handler sicher für mehrere asynchrone Aufgaben gemeinsam nutzen. Wenn diese Grenzen nicht eingehalten werden, wird Ihr Code nicht kompiliert.
Wenn Sie einen gemeinsamen Status für mehrere Aufrufe benötigen (einen Datenbankpool, eine Konfigurationsstruktur), binden Sie ihn ein [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)und klonen Sie ihn in jeden Aufruf. `Arc`
Alle AWS SDKs für Rust-Clients sind konkurrenzsicher und erfordern keine besondere Behandlung.
### Beispiel: SDK-Client AWS
Im folgenden Beispiel wird ein S3-Client verwendet, um bei jedem Aufruf ein Objekt hochzuladen. Der Client wird direkt in die Closure geklont, ohne: `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
```
### Beispiel: Datenbank-Verbindungspools
Wenn Ihr Handler Zugriff auf einen gemeinsamen Status wie einen Client und eine Konfiguration benötigt, binden Sie ihn ein [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)und klonen Sie ihn `Arc` in jeden Aufruf:
```
#[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
```
## Gemeinsames /tmp-Verzeichnis
Das `/tmp` Verzeichnis wird von allen gleichzeitigen Aufrufen in derselben Ausführungsumgebung gemeinsam genutzt. Verwenden Sie eindeutige Dateinamen pro Aufruf (geben Sie z. B. die Anforderungs-ID an) oder implementieren Sie explizite Dateisperren, um Datenbeschädigungen zu vermeiden.
## Protokollierung
Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen werden in Protokollen verschachtelt) ist in Systemen mit mehreren gleichzeitigen Vorgängen normal. Funktionen, die Lambda Managed Instances verwenden, unterstützen das strukturierte JSON-Protokollformat über die [erweiterten Protokollierungssteuerungen](monitoring-logs.md#monitoring-cloudwatchlogs-advanced) von Lambda. Dieses Format beinhaltet das`requestId`, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Weitere Informationen finden Sie unter[Implementierung der erweiterten Protokollierung mit der Tracing Crate](rust-logging.md#rust-logging-tracing).
## Kontext anfordern
Das `Context` Objekt wird direkt an jeden Handler-Aufruf übergeben. Wird verwendet`event.context.request_id`, um auf die Anforderungs-ID für die aktuelle Anfrage zuzugreifen.
Wird verwendet`event.context.xray_trace_id`, um auf die X-Ray-Trace-ID zuzugreifen. Lambda unterstützt die `_X_AMZN_TRACE_ID` Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird automatisch weitergegeben, wenn das AWS SDK für Rust verwendet wird.
Wird verwendet`event.context.deadline`, um Timeouts zu erkennen — sie enthält die Frist für den Aufruf in Millisekunden.
## Initialisierung und Herunterfahren
Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Anfragen gemeinsam genutzt.
Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. `lambda_runtime`bietet ein Hilfsprogramm zur Vereinfachung der Konfiguration der Signalverarbeitung bei ordnungsgemäßem Herunterfahren,. [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) Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter [Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung](lambda-runtime-environment.md).
## Versionen von Abhängigkeiten
Lambda Managed Instances erfordert die folgende Mindestpaketversion:
+ `lambda_runtime`: Version 1.1.1 oder höher, mit aktivierter Funktion `concurrency-tokio`
+ Die unterstützte Mindestversion von Rust (MSRV) ist 1.84.0.