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

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

Verwenden Sie aussagekräftige Namen. Benennen Sie Kapazitätsanbieter, um deren Verwendungszweck und Vertrauensstufe eindeutig 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 bei der Erstellung von Kapazitätsanbietern Subnetze für mehrere Availability Zones an. Lambda startet aus Gründen der AZ-Resilienz standardmäßig drei Instances und gewährleistet so eine hohe Verfügbarkeit Ihrer Funktionen.

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 Einschrä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 für zulässige Instanztypen eine Liste kompatibler Instanzen fest. Beispiel:

  • Wählen Sie für Anwendungen, die eine hohe Netzwerkbandbreite erfordern, 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 mehrere gleichzeitige Ausführungen 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 Multiparallelität so handhabt

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

  • Bei IO-heavy Anwendungen wie Webdiensten oder Batch-Jobs bietet die Mehrfachparallelität den größten Vorteil

Konfigurieren Sie die maximale Parallelität entsprechend. Lambda wählt vernünftige Standardwerte für maximale Parallelität, die den Ressourcenverbrauch und den Durchsatz in Einklang bringen. 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 nur sehr wenig CPU verbrauchen

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

Beachten Sie, dass in Ausführungsumgebungen mit sehr geringer Parallelität Drosselungen und Skalierungsschwierigkeiten auftreten können.

Long-running Funktionen

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

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

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

Temporäre Anmeldeinformationen aktualisieren. Wenn Ihre Funktion temporäre Anmeldeinformationen oder Token abruft, stellen Sie sicher, dass sie 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. Je länger Funktionen ausgeführt werden, desto größer wird das Zeitfenster für Wiederholungsversuche und doppelte Lieferungen. Verwenden Sie Powertools for AWS Lambda, um Idempotenz für Operationen wie Zahlungen oder Datenbankschreibvorgänge zu implementieren, sodass sie dasselbe Ergebnis liefern, auch wenn sie mehr als einmal ausgeführt werden. Wenn Sie dauerhafte Lambda-Funktionen verwenden, haben Schritte eine Semantik, die mindestens einmal ausgeführt wird: Das Durable Execution SDK ü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.

Passen Sie die Zuordnungen der Ereignisquellen für eine längere Verarbeitung an. Legen Sie für Amazon SQS das Sichtbarkeits-Timeout der Warteschlange auf mindestens das Sechsfache des Funktions-Timeouts fest, sodass Lambda genügend Zeit hat, einen Batch erneut zu versuchen, wenn die Funktion gedrosselt wird. Lambda überprüft dies, wenn Sie die Ereignisquellenzuordnung 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ängere Verarbeitungszeiten pro Stapel zu berücksichtigen, und aktivieren Sie die Meldung teilweiser Batch-Fehler, sodass nur fehlgeschlagene Datensätze wiederholt werden und nicht der gesamte Stapel.

Skalierungskonfiguration

Legen Sie die entsprechende Zielressourcenauslastung fest. Standardmäßig bietet Lambda genügend Spielraum, sodass sich Ihr Traffic ohne Drosselungen innerhalb von 5 Minuten verdoppeln kann. Passen Sie dies an Ihre Workload-Merkmale an:

  • Bei sehr gleichbleibenden Workloads oder Anwendungen, die nicht empfindlich auf Drosselungen reagieren, sollten Sie das Ziel auf einen hohen Wert setzen, um eine höhere Auslastung und niedrigere Kosten zu erreichen

  • Setzen Sie sich bei Workloads mit potenziellen Datenverkehrsspitzen niedrige Ressourcenziele, um zusätzlichen Spielraum zu haben

Planen Sie das Verkehrswachstum ein. Wenn sich Ihr Traffic innerhalb von 5 Minuten mehr als verdoppelt, kann es zu Drosselungen kommen, wenn Lambda Instances und Ausführungsumgebungen skaliert. Entwerfen Sie Ihre Anwendung so, dass sie potenziellen Drosselungen in Zeiten schneller Skalierung begegnet.

Sicherheit

Wenden Sie die geringsten Rechte für Berechtigungen 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 von Kapazitätsanbietern. Wird verwendet AWS CloudTrail , um die Zuweisungen und Zugriffsmuster von Kapazitätsanbietern zu überwachen. Dies hilft bei der Identifizierung unberechtigter Zugriffsversuche und gewährleistet die Einhaltung von 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 die Kosten zu senken. Diese Preisoptionen gelten für die zugrunde liegende EC2-Rechenleistung (die Verwaltungsgebühr von 15% wird nicht rabattiert).

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

Überwachen Sie die Ressourcennutzung. Verfolgen Sie CloudWatch Metriken, 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 der Kapazitätsanbieter. Verfolgen Sie Kennzahlen auf Ebene der Kapazitätsanbieter, einschließlich CPU-Auslastung MemoryUtilization, vCPUAvailable, und überprüfen Sie, ob ausreichend Ressourcen MemoryAvailable für Ihre Workloads verfügbar sind.

Überwachen Sie die Kennzahlen der Ausführungsumgebung. Verfolgen Sie Metriken auf der Ebene der Ausführungsumgebung, einschließlich ExecutionEnvironmentConcurrency und ExecutionEnvironmentConcurrencyLimit um das Skalierungsverhalten zu verstehen und mögliche 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

  • Wir nähern uns den Grenzwerten für Parallelität

Language-specific Überlegungen

Folgen Sie den sprachspezifischen Best Practices. Jede Programmiersprache behandelt Multiparallelität unterschiedlich. Ausführliche Empfehlungen finden Sie in den sprachspezifischen Leitfäden:

  • Java: Verwenden Sie Thread-sichere Sammlungen und für anforderungsspezifische AtomicInteger Status ThreadLocal

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

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

  • Rust: Verwenden Sie run_concurrent stattrun, 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, Race-Bedingungen und die korrekte Zustandsisolierung bei gleichzeitiger Last.

Nächste Schritte