Fortgeschrittene Serverless-Funktionen in JavaScript in AWS Lambda

Fortgeschrittene Serverless-Funktionen in JavaScript in AWS Lambda: von der Theorie zur Produktion

Die Serverless-Architektur auf Basis von AWS Lambda ist zum Standard für den Aufbau von Microservices und ereignisgesteuerten Systemen geworden. Wenn Sie bereits die grundlegenden Funktionen (Trigger von S3, API Gateway, DynamoDB) beherrschen, ist es Zeit, zur nächsten Stufe überzugehen. In diesem Artikel behandeln wir fortgeschrittene Techniken für die Arbeit mit AWS Lambda in Node.js: Optimierung des Kaltstarts, Arbeit in VPC, Verwendung von Layern, fundiertes Monitoring und Debugging. Jeder Abschnitt wird von praktischen Codebeispielen begleitet.

1. Optimierung des Kaltstarts (Cold Start)

Der Kaltstart ist der größte Feind der Leistung von Serverless-Funktionen. Wenn eine Lambda-Funktion eine Weile nicht genutzt wurde, erstellt AWS einen neuen Container, lädt den Code und initialisiert die Abhängigkeiten. Dies kann zwischen 200 ms und mehreren Sekunden dauern. Sehen wir uns an, wie dieser Effekt minimiert werden kann.

1.1. Nutzung des globalen Gültigkeitsbereichs

Code außerhalb des Handlers wird nur einmal beim Erstellen des Containers ausgeführt. Lagern Sie schwere Operationen dorthin aus: Datenbankverbindungen, Konfigurationsladung, SDK-Initialisierung.

// ❌ Schlecht: Jeder Aufruf erstellt eine neue Verbindung\nexports.handler = async (event) => {\n  const AWS = require('aws-sdk');\n  const dynamoDB = new AWS.DynamoDB.DocumentClient();\n  // ...\n};\n\n// ✅ Gut: Die Verbindung wird einmal erstellt\nconst AWS = require('aws-sdk');\nconst dynamoDB = new AWS.DynamoDB.DocumentClient();\n\nexports.handler = async (event) => {\n  // verwende dynamoDB\n};

1.2. Reduzierung der Paketgröße

Jedes überflüssige Modul erhöht die Ladezeit. Verwenden Sie aws-sdk Version 3 mit Tree-Shaking oder binden Sie nur die benötigten Clients ein:

// Statt des vollständigen SDK:\nconst { DynamoDBClient } = require('@aws-sdk/client-dynamodb');\nconst { DynamoDBDocumentClient } = require('@aws-sdk/lib-dynamodb');

1.3. Provisioned Concurrency

Aktivieren Sie für latenzkritische Funktionen (z. B. APIs unter Last) Provisioned Concurrency. Dies stellt sicher, dass eine bestimmte Anzahl von Containern immer "warm" ist.

// Beispiel über die AWS CLI:\naws lambda put-provisioned-concurrency-config \\\n  --function-name my-function \\\n  --qualifier PROD \\\n  --provisioned-concurrent-executions 10

2. Arbeit mit VPC: Sicherheit und Leistung

Wenn eine Lambda-Funktion auf Ressourcen innerhalb einer VPC zugreifen muss (RDS, ElastiCache, private APIs), ist eine Netzwerkkonfiguration erforderlich. Die Verbindung zu einer VPC erhöht jedoch den Kaltstart um 5-10 Sekunden aufgrund der Erstellung von ENIs (Elastic Network Interfaces).

2.1. Optimierung von VPC-Funktionen

\n
• Verwenden Sie VPC Endpoints für AWS-Services (S3, DynamoDB, SQS) – dies ermöglicht den Zugriff ohne Umweg über NAT/Internet Gateway.
\n
• Minimieren Sie die Anzahl der Subnetze – Lambda erstellt ein ENI in jedem angegebenen Subnetz. Beschränken Sie sich auf zwei (verschiedene AZs).
\n
• Cachen Sie Verbindungen – wenn die Funktion eine Verbindung zu RDS herstellt, verwenden Sie einen Verbindungspool (z. B. pg-pool für PostgreSQL).
\n

const { Pool } = require('pg');\n\n// Der Pool wird außerhalb des Handlers erstellt\nconst pool = new Pool({\n  host: process.env.DB_HOST,\n  database: 'mydb',\n  max: 5, // Verbindungslimit\n  idleTimeoutMillis: 30000,\n});\n\nexports.handler = async (event) => {\n  const client = await pool.connect();\n  try {\n    const result = await client.query('SELECT NOW()');\n    return { statusCode: 200, body: result.rows };\n  } finally {\n    client.release();\n  }\n};

2.2. VPC und Kaltstart

Wenn der Kaltstart kritisch ist, ziehen Sie Alternativen in Betracht:

\n
• Verwenden Sie Aurora Serverless oder DynamoDB anstelle von RDS.
\n
• Lagern Sie Daten in ElastiCache (Redis) aus und stellen Sie die Verbindung übe