View a markdown version of this page

Bewährte Methoden für Lambda Managed Instances - AWS Lambda

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.

Bewährte Methoden für Lambda Managed Instances

Kapazitätsanbieter-Konfiguration

Trennen Sie die Kapazitätsanbieter nach Vertrauensstufe. Erstellen Sie verschiedene Kapazitätsanbieter für Workloads mit unterschiedlichen Sicherheitsanforderungen. Alle Funktionen, die demselben Kapazitätsanbieter zugewiesen sind, müssen gegenseitig vertrauenswürdig sein, da die Kapazitätsanbieter als Sicherheitsgrenze dienen.

Verwenden Sie aussagekräftige Namen. Benennen Sie Kapazitätsanbieter, um deren Verwendungszweck und Vertrauensstufe deutlich anzugeben (z. B.production-trusted,dev-sandbox). Dies hilft den Teams, den Zweck und die Sicherheitslage der einzelnen Kapazitätsanbieter zu verstehen.

Verwenden Sie mehrere Availability Zones. Geben Sie Subnetze für mehrere Availability Zones an, wenn Sie Kapazitätsanbieter erstellen. Lambda startet standardmäßig drei Instances, um die AZ-Resilienz zu gewährleisten und eine hohe Verfügbarkeit Ihrer Funktionen sicherzustellen.

Auswahl des Instance-Typs

Lassen Sie Lambda die Instanztypen auswählen. Standardmäßig wählt Lambda die besten Instance-Typen für Ihren Workload aus. Wir empfehlen, Lambda Managed Instances die Instanztypen für Sie auswählen zu lassen, da eine Beschränkung der Anzahl möglicher Instanztypen zu einer geringeren Verfügbarkeit führen kann.

Geben Sie Instanztypen für bestimmte Anforderungen an. Wenn Sie bestimmte Hardwareanforderungen haben, legen Sie die zulässigen Instance-Typen auf eine Liste kompatibler Instances fest. Beispiel:

  • Wählen Sie für Anwendungen, die eine hohe Netzwerkbandbreite benötigen, mehrere n-Instance-Typen aus

  • Wählen Sie für Test- oder Entwicklungsumgebungen mit Kostenbeschränkungen kleinere Instance-Typen wie m7a.large

Konfiguration der Funktionen

Wählen Sie die entsprechenden Speicher- und vCPU-Einstellungen. Wählen Sie Speicher- und vCPU-Konfigurationen aus, die die mehrfache Ausführung Ihrer Funktion unterstützen. Die unterstützte Mindestfunktionsgröße beträgt 2 GB und 1 vCPU.

  • Wählen Sie für Python-Anwendungen ein höheres Verhältnis von Arbeitsspeicher zu vCPUs (z. B. 4 zu 1 oder 8 zu 1), da Python mehrere Parallelitäten verarbeitet

  • Wählen Sie für CPU-intensive Operationen oder Funktionen, die wenig I/O ausführen, mehr als eine vCPU

  • Für IO-heavy Anwendungen wie Webdienste oder Batch-Jobs bietet die Mehrfachparallelität den größten Vorteil

Konfigurieren Sie die maximale Parallelität entsprechend. Lambda wählt sinnvolle Standardwerte für maximale Parallelität, die Ressourcenverbrauch und Durchsatz ausgleichen. Passen Sie diese Einstellung an die Ressourcennutzung Ihrer Funktion an:

  • Erhöhen Sie die maximale Parallelität (bis zu 64 pro vCPU), wenn Ihre Funktionsaufrufe sehr wenig CPU verbrauchen

  • Verringern Sie die maximale Parallelität, wenn Ihre Anwendung viel Arbeitsspeicher und sehr wenig CPU verbraucht

Beachten Sie, dass es in Ausführungsumgebungen mit sehr geringer Parallelität zu Drosselungen und Skalierungsschwierigkeiten kommen kann.

Long-running Funktionen

Funktionen auf AWS Lambda Managed Instances können bis zu 90 Minuten (5.400 Sekunden) pro Aufruf für asynchrone Aufrufe und für Aufrufe der Ereignisquellenzuordnung ausgeführt werden, mit Ausnahme von Amazon MQ- und Amazon DocumentDB-Ereignisquellenzuordnungen, die auf 15 Minuten begrenzt bleiben. Synchrone Aufrufe und die Initialisierungsphase der Funktion bleiben ebenfalls auf 15 Minuten begrenzt. Weitere Informationen zum Einstellen des Timeouts finden Sie unter Timeout für Lambda-Funktionen konfigurieren. Da Ihre Funktion länger laufen kann, sollten Sie die folgenden Überlegungen für Komponenten beachten, die kurzlebiger Natur sind, wie Netzwerkverbindungen und Anmeldeinformationen.

Berücksichtigen Sie Timeouts bei inaktiven Verbindungen. Stellen Sie sicher, dass Timeouts bei inaktiven Verbindungen bei Downstream-Diensten wie Amazon RDS ElastiCache, Amazon und externen APIs die volle Funktionsdauer berücksichtigen. Wenn Ihre Funktion den Datenverkehr über ein NAT-Gateway leitet, senden Sie Keep-Alive-Pakete, um zu verhindern, dass inaktive Verbindungen nach dem Leerlauf-Timeout des NAT-Gateways von 350 Sekunden unterbrochen werden.

Respektieren Sie die DNS-TTL-Werte. Beachten Sie die DNS-TTL-Werte, wenn Sie externe Hostnamen auflösen. Die AWS SDKs erledigen das automatisch, aber benutzerdefinierte HTTP-Clients können DNS-Auflösungen zwischenspeichern, die über ihre TTL hinausgehen.

Aktualisieren Sie die temporären Anmeldeinformationen. Wenn Ihre Funktion temporäre Anmeldeinformationen oder Token erwirbt, stellen Sie sicher, dass diese für die gesamte Ausführungsdauer gültig bleiben, oder aktualisieren Sie sie im Hintergrund.

Design für Idempotenz. Lambda garantiert nicht, dass die Verarbeitung exakt einmal erfolgt. Wenn Funktionen länger laufen, vergrößert sich das Zeitfenster für Wiederholungen und doppelte Lieferungen. Verwenden Sie Powertools for AWS Lambda, um Idempotenz für Operationen wie Zahlungen oder Datenbankschreibvorgänge zu implementieren, sodass diese das gleiche Ergebnis liefern, auch wenn sie mehrmals ausgeführt werden. Wenn Sie langlebige Lambda-Funktionen verwenden, haben Schritte eine Semantik, die mindestens einmal ausgeführt wird: Das SDK für dauerhafte Ausführung überspringt abgeschlossene Schritte während der Wiedergabe, aber Schritte, die vor dem Checkpointing fehlschlagen, können erneut ausgeführt werden. Sie können Ausführungsnamen als Idempotenzschlüssel verwenden.

Optimieren Sie die Zuordnungen der Ereignisquellen für eine längere Verarbeitung. Stellen Sie für Amazon SQS das Sichtbarkeits-Timeout der Warteschlange auf mindestens das Sechsfache des Funktions-Timeouts ein, sodass Lambda genügend Zeit hat, um einen Batch erneut zu versuchen, falls die Funktion gedrosselt wird. Lambda validiert dies, wenn Sie die Zuordnung der Ereignisquelle erstellen, verhindert jedoch nicht, dass spätere Änderungen an der Warteschlange oder Funktion, die zu einer Nichtübereinstimmung führen, vorgenommen werden. Konfigurieren Sie für Amazon Kinesis Data Streams und Amazon DynamoDB Streams das maximale Batching-Fenster und den Parallelisierungsfaktor, um längeren Verarbeitungszeiten pro Batch Rechnung zu tragen, und aktivieren Sie die Meldung von partiellen Batch-Fehlern, sodass nur fehlgeschlagene Datensätze und nicht der gesamte Batch erneut versucht werden.

Skalierungskonfiguration

Legen Sie eine angemessene Zielressourcenauslastung fest. Standardmäßig bietet Lambda genügend Headroom, sodass sich Ihr Traffic innerhalb von 5 Minuten ohne Drosselung verdoppeln kann. Passen Sie dies auf der Grundlage Ihrer Workload-Merkmale an:

  • Legen Sie für sehr konstante Workloads oder Anwendungen, die nicht auf Drosselungen reagieren, das Ziel auf ein hohes Niveau fest, um eine höhere Auslastung und niedrigere Kosten zu erzielen

  • Setzen Sie bei Workloads mit potenziellen Datenverkehrsspitzen die Ressourcenziele auf ein niedriges Niveau, um zusätzlichen Spielraum zu erhalten

Planen Sie das Verkehrswachstum ein. Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, treten möglicherweise Drosselungen auf, wenn Lambda Instances und Ausführungsumgebungen hochskaliert. Entwerfen Sie Ihre Anwendung so, dass sie potenzielle Drosselungen in Zeiten schneller Skalierung bewältigt.

Sicherheit

Wenden Sie für Berechtigungen die geringste Zugriffsrechte an. PassCapacityProvider Erteilen lambda:PassCapacityProvider Sie Berechtigungen nur für die erforderlichen Kapazitätsanbieter. Verwenden Sie Berechtigungen auf Ressourcenebene, um einzuschränken, welche Kapazitätsanbieter Benutzer Funktionen zuweisen können.

Überwachen Sie die Nutzung des Kapazitätsanbieters. Wird verwendet AWS CloudTrail , um Zuweisungen und Zugriffsmuster von Kapazitätsanbietern zu überwachen. Dies hilft bei der Identifizierung unberechtigter Zugriffsversuche und gewährleistet die Einhaltung der Sicherheitsrichtlinien.

Trennen Sie nicht vertrauenswürdige Workloads. Verlassen Sie sich bei der Sicherheitsisolierung zwischen nicht vertrauenswürdigen Workloads nicht auf Container. Verwenden Sie verschiedene Kapazitätsanbieter, um Workloads zu trennen, denen nicht gegenseitig vertraut wird.

Kostenoptimierung

Verwenden Sie die EC2-Preisoptionen. Nutzen Sie EC2-Sparpläne und Reserved Instances, um Ihre Kosten zu senken. Diese Preisoptionen gelten für die zugrunde liegende EC2-Rechenleistung (die Verwaltungsgebühr von 15% ist nicht ermäßigt).

Optimieren Sie für stationäre Workloads. Lambda Managed Instances eignen sich am besten für Steady-State-Funktionen mit vorhersehbarem hohem Datenvolumen. Bei stark frequentierten Datenverkehrsmustern könnte Lambda (Standard) kostengünstiger sein.

Überwachen Sie die Ressourcenauslastung. Verfolgen Sie CloudWatch Kennzahlen, um die CPU- und Speicherauslastung zu verstehen. Passen Sie die Funktionsspeicherzuweisung und die Auswahl des Instanztyps an die tatsächlichen Nutzungsmuster an, um die Kosten zu optimieren.

Überwachung und Beobachtbarkeit

Überwachen Sie die Kennzahlen von Kapazitätsanbietern. Verfolgen Sie Kennzahlen auf Ebene der Kapazitätsanbieter, einschließlich CPUUtilization MemoryUtilization, vCPUAvailable, und stellen Sie sicher, dass genügend Ressourcen MemoryAvailable für Ihre Workloads verfügbar sind.

Überwachen Sie die Kennzahlen der Ausführungsumgebung. Verfolgen Sie Kennzahlen auf der Ebene der Ausführungsumgebung, einschließlich ExecutionEnvironmentConcurrency und ExecutionEnvironmentConcurrencyLimit um das Skalierungsverhalten zu verstehen und potenzielle Drosselungen zu identifizieren.

Richten Sie Alarme ein. CloudWatch Erstellen Sie CloudWatch Alarme für wichtige Kennzahlen, um Probleme proaktiv zu identifizieren:

  • Hohe CPU- oder Speicherauslastung

  • Niedrige verfügbare Kapazität

  • Annäherung an die Parallelitätsgrenzen

Language-specific Überlegungen

Folgen Sie den sprachspezifischen Best Practices. Jede Programmiersprache behandelt mehrere Parallelitäten unterschiedlich. In den sprachspezifischen Leitfäden finden Sie ausführliche Empfehlungen:

  • Java: Verwenden Sie threadsichere Sammlungen und für den anforderungsspezifischen AtomicInteger Status ThreadLocal

  • Node.js: Verwenden Sie es InvokeStore für alle anforderungsspezifischen Zustände und vermeiden Sie globale Variablen

  • Python: Verwenden Sie eindeutige Dateinamen /tmp zusammen mit Anforderungs-IDs und ziehen Sie eine prozessbasierte Speicherisolierung in Betracht

  • Rust: Verwenden Sie run_concurrent anstelle vonrun, wenn die concurrency-tokio Funktion aktiviert ist. Der Handler muss Clone + seinSend.

Testen Sie auf Thread-Sicherheits- und Parallelitätsprobleme. Testen Sie Ihre Funktionen vor der Bereitstellung in der Produktion gründlich auf Thread-Sicherheitsprobleme, Rennbedingungen und die korrekte Zustandsisolierung unter gleichzeitiger Last.

Nächste Schritte