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.

Entwerfen von Lambda-Anwendungen

Eine gut konzipierte ereignisgesteuerte Anwendung verwendet eine Kombination aus AWS Diensten und benutzerdefiniertem Code, um Anfragen und Daten zu verarbeiten und zu verwalten. Dieses Kapitel konzentriert sich auf Lambda-spezifische Themen im Anwendungsdesign. Bei der Entwicklung von Anwendungen für stark frequentierte Produktionssysteme gibt es viele wichtige Überlegungen für Serverless-Architekten.

Viele der bewährten Verfahren, die für die Softwareentwicklung und verteilte Systeme gelten, gelten auch für die Entwicklung Serverless-Anwendungen. Das übergeordnete Ziel besteht darin, Workloads zu entwickeln, die:

Die folgenden Designprinzipien können Ihnen dabei helfen, Workloads zu erstellen, die diese Ziele erfüllen. Nicht jedes Prinzip lässt sich auf jede Architektur anwenden, aber sie sollten Ihnen bei allgemeinen Architekturentscheidungen als Leitfaden dienen.

Verwendung von Diensten anstelle von benutzerdefiniertem Code

Serverlose Anwendungen bestehen normalerweise aus mehreren AWS Diensten, die mit benutzerdefiniertem Code integriert sind, der in Lambda-Funktionen ausgeführt wird. Lambda kann zwar in die meisten AWS Dienste integriert werden, aber die Dienste, die in serverlosen Anwendungen am häufigsten verwendet werden, sind:

Es gibt viele etablierte, gängige Muster in verteilten Architekturen, die Sie selbst erstellen oder mithilfe von AWS Services implementieren können. Für die meisten Kunden ist es wirtschaftlich nicht sinnvoll, Zeit in die Entwicklung dieser Muster zu investieren. Wenn Ihre Anwendung eines dieser Muster benötigt, verwenden Sie den entsprechenden AWS Dienst:

Diese Dienste sind für die Integration mit Lambda konzipiert und Sie können Infrastructure as Code (IaC) verwenden, um Ressourcen in den Diensten zu erstellen und zu verwerfen. Sie können jeden dieser Dienste über das AWS SDK nutzen, ohne dass Sie Anwendungen installieren oder Server konfigurieren müssen. Der Umgang mit diesen Diensten über den Code in Ihren Lambda-Funktionen ist ein wichtiger Schritt zur Erstellung gut konzipierter Serverless-Anwendungen.

Informationen zu Lambda-Abstraktionsebenen

Der Lambda-Dienst beschränkt Ihren Zugriff auf die zugrunde liegenden Betriebssysteme, Hypervisoren und Hardware, auf denen Ihre Lambda-Funktionen ausgeführt werden. Der Dienst wird ständig verbessert und die Infrastruktur verändert, um neue Features hinzuzufügen, die Kosten zu senken und den Dienst leistungsfähiger zu machen. Ihr Code sollte kein Wissen darüber voraussetzen, wie Lambda aufgebaut ist und keine Hardware-Affinität voraussetzen.

In ähnlicher Weise werden die Integrationen von Lambda mit anderen Diensten von verwaltet AWS, sodass Ihnen nur eine geringe Anzahl von Konfigurationsoptionen zur Verfügung steht. Bei der Interaktion zwischen API Gateway und Lambda gibt es beispielsweise kein Konzept für den Load Balancer, da dieser vollständig von den Diensten verwaltet wird. Sie haben auch keine direkte Kontrolle darüber, welche Verfügbarkeitszonen die Dienste beim Aufrufen von Funktionen zu einem bestimmten Zeitpunkt verwenden oder wie Lambda entscheidet, wann die Anzahl der Ausführungsumgebungen nach oben oder unten skaliert wird.

Diese Abstraktion ermöglicht es Ihnen, sich auf die Integrationsaspekte Ihrer Anwendung, den Datenfluss und die Geschäftslogik zu konzentrieren, bei denen Ihr Workload einen Mehrwert für Ihre Endbenutzer bietet. Wenn Sie den Diensten die Verwaltung der zugrundeliegenden Mechanismen überlassen, können Sie Anwendungen schneller entwickeln und müssen weniger eigenen Code pflegen.

Implementieren der Zustandslosigkeit in Funktionen

Bei Standard-Lambda-Funktionen sollten Sie davon ausgehen, dass die Umgebung nur für einen einzigen Aufruf existiert. Die Funktion sollte beim ersten Start alle erforderlichen Zustände initialisieren. Beispielsweise kann Ihre Funktion das Abrufen von Daten aus einer DynamoDB-Tabelle erfordern. Sie sollte alle dauerhaften Datenänderungen vor dem Beenden in einem dauerhaften Speicher wie Amazon S3, DynamoDB oder Amazon SQS speichern. Sie sollte sich nicht auf bestehende Datenstrukturen oder temporäre Dateien oder auf interne Zustände stützen, die bei mehreren Aufrufen verwaltet würden.

Bei der Verwendung von Durable Functions wird der Status zwischen Aufrufen automatisch beibehalten, sodass der Status nicht manuell im externen Speicher gespeichert werden muss. Für alle Daten, die nicht explizit über den verwaltet werden, sollten Sie jedoch weiterhin die Prinzipien der Zustandslosigkeit beachten. DurableContext

Um Datenbankverbindungen und Bibliotheken zu initialisieren oder den Status zu laden, können Sie die statische Initialisierung nutzen. Da Ausführungsumgebungen nach Möglichkeit wiederverwendet werden, um die Leistung zu verbessern, können Sie die für die Initialisierung dieser Ressourcen benötigte Zeit über mehrere Aufrufe hinweg amortisieren. Sie sollten jedoch keine Variablen oder Daten, die in der Funktion verwendet werden, in diesem globalen Bereich speichern.

Kopplung minimieren

Die meisten Architekturen sollten viele, kürzere Funktionen den wenigen, größeren vorziehen. Der Zweck jeder Funktion sollte darin bestehen, das an die Funktion übergebene Ereignis zu verarbeiten, ohne Kenntnisse oder Erwartungen in Bezug auf den gesamten Arbeitsablauf oder das Transaktionsvolumen. Dadurch ist die Funktion unabhängig von der Quelle des Ereignisses und nur minimal mit anderen Diensten verbunden.

Alle Konstanten mit globalem Geltungsbereich, die sich nur selten ändern, sollten als Umgebungsvariablen implementiert werden, um Aktualisierungen ohne Bereitstellungen zu ermöglichen. Alle Geheimnisse oder sensiblen Informationen sollten im AWS Systems Manager Parameter Store oder AWS Secrets Manager gespeichert und von der Funktion geladen werden. Da diese Ressourcen kontospezifisch sind, können Sie auf diese Weise Build-Pipelines für mehrere Konten erstellen. Die Pipelines laden die entsprechenden Geheimnisse für jede Umgebung, ohne dass diese für Entwickler sichtbar sind oder Codeänderungen erforderlich sind.

Entwickeln für On-Demand-Daten statt Batches

Viele herkömmliche Systeme sind so konzipiert, dass sie periodisch laufen und Batch von Transaktionen verarbeiten, die sich im Laufe der Zeit angesammelt haben. So kann beispielsweise eine Bankanwendung stündlich laufen, um die Transaktionen von Geldautomaten in einem zentralen Hauptbuch zu verarbeiten. In Lambda-basierten Anwendungen sollte die benutzerdefinierte Verarbeitung durch jedes Ereignis ausgelöst werden, so dass der Dienst bei Bedarf die Gleichzeitigkeit erhöhen kann, um die Verarbeitung von Transaktionen nahezu in Echtzeit zu ermöglichen.

Während Standard-Lambda-Funktionen auf eine Ausführungszeit von 15 Minuten begrenzt sind, können Durable Functions bis zu einem Jahr lang ausgeführt werden, sodass sie für länger andauernde Verarbeitungsanforderungen geeignet sind. Dennoch sollten Sie, wenn möglich, die ereignisgesteuerte Verarbeitung der Stapelverarbeitung vorziehen.

Sie können Cron-Aufgaben zwar in serverlosen Anwendungen ausführen, indem Sie geplante Ausdrücke für Regeln in Amazon verwenden EventBridge, diese sollten jedoch sparsam oder als letztes Mittel verwendet werden. Bei jeder geplanten Aufgabe, die einen Batch verarbeitet, besteht die Möglichkeit, dass das Transaktionsvolumen über das hinausgeht, was innerhalb des 15-minütigen Lambda-Dauerbegrenzung verarbeitet werden kann. Wenn Sie aufgrund der Einschränkungen externer Systeme gezwungen sind, einen Scheduler zu verwenden, sollten Sie in der Regel für den kürzesten sinnvollen wiederkehrenden Zeitraum planen.

So ist es beispielsweise keine optimale Vorgehensweise, einen Batch-Prozess zu verwenden, der eine Lambda-Funktion auslöst, um eine Liste neuer Amazon-S3-Objekte abzurufen. Dies liegt daran, dass der Dienst zwischen den Batches möglicherweise mehr neue Objekte erhält, als innerhalb einer 15-minütigen Lambda-Funktion verarbeitet werden können.

Stattdessen sollte Amazon S3 die Lambda-Funktion jedes Mal aufrufen, wenn ein neues Objekt in den Bucket gestellt wird. Dieser Ansatz ist deutlich skalierbarer und funktioniert nahezu in Echtzeit.

Erwägen AWS Step Functions Sie die Orchestrierung

Workflows, die Verzweigungslogik, verschiedene Arten von Fehlermodellen und Wiederholungslogik beinhalten, verwenden in der Regel einen Orchestrator, um den Status der Gesamtausführung zu verfolgen. Vermeiden Sie die Verwendung von Lambda-Funktionen für diesen Zweck, da dies zu einer engen Verknüpfung und einer komplexen Codeverarbeitung führt.

Mit AWS Step Functions verwenden Sie Zustandsmaschinen, um die Orchestrierung zu verwalten. Dadurch werden die Fehlerbehandlung, das Routing und die Verzweigungslogik aus Ihrem Code extrahiert und durch Zustandsautomaten ersetzt, die mit JSON deklariert werden. Abgesehen davon, dass es Workflows robuster und beobachtbarer macht, ermöglicht es Ihnen auch, Workflows zu versionieren und den Zustandsautomaten zu einer kodifizierten Ressource zu machen, die Sie zu einem Code-Repository hinzufügen können.

Es ist üblich, dass einfachere Workflows in Lambda-Funktionen mit der Zeit komplexer werden. Beim Betrieb einer produktiven Serverless-Anwendung ist es wichtig zu erkennen, wann dies geschieht, damit Sie diese Logik in einen Zustandsautomaten migrieren können.

Implementieren von Idempotenz

AWS Serverlose Dienste, einschließlich Lambda, sind fehlertolerant und für den Umgang mit Ausfällen konzipiert. Wenn beispielsweise ein Dienst eine Lambda-Funktion aufruft und es zu einer Dienstunterbrechung kommt, ruft Lambda Ihre Funktion in einer anderen Verfügbarkeitszone auf. Wenn Ihre Funktion einen Fehler auslöst, wiederholt Lambda den Aufruf.

Da ein und dasselbe Ereignis mehr als einmal eintreten kann, sollten die Funktionen idempotent sein. Dies bedeutet, dass der mehrfache Empfang desselben Ereignisses das Ergebnis nicht über den ersten Empfang hinaus verändert.

Sie können Idempotenz in Lambda-Funktionen implementieren, indem Sie eine DynamoDB-Tabelle verwenden, um kürzlich verarbeitete Bezeichner zu verfolgen und festzustellen, ob die Transaktion bereits zuvor bearbeitet wurde. Die DynamoDB-Tabelle implementiert in der Regel einen TTL-Wert (Time To Live) für ablaufende Elemente, um den verwendeten Speicherplatz zu begrenzen.

Verwenden Sie mehrere Konten für die Verwaltung von Kontingenten AWS

Viele Servicekontingente AWS werden auf Kontoebene festgelegt. Das bedeutet, dass Sie bei zunehmendem Workload schnell an Ihre Grenzen stoßen können.

Eine effektive Möglichkeit, dieses Problem zu lösen, besteht darin, mehrere AWS Konten zu verwenden und jede Arbeitslast einem eigenen Konto zuzuweisen. Dadurch wird verhindert, dass Kontingente mit anderen Workloads oder Ressourcen außerhalb der Produktion geteilt werden.

Mithilfe von AWS -Organisationen können Sie außerdem die Abrechnung, Compliance und Sicherheit dieser Konten zentral verwalten. Sie können Richtlinien an Gruppen von Konten anhängen, um benutzerdefinierte Skripts und manuelle Prozesse zu vermeiden.

Ein gängiger Ansatz besteht darin, jedem Entwickler ein AWS Konto zur Verfügung zu stellen und dann separate Konten für die Betabereitstellungsphase und die Produktion zu verwenden:

In diesem Modell hat jeder Entwickler seine eigenen Beschränkungen für das Konto, sodass sich deren Nutzung nicht auf Ihre Produktionsumgebung auswirkt. Dieser Ansatz ermöglicht es Entwicklern auch, Lambda-Funktionen lokal auf ihren Entwicklungsmaschinen anhand von Live-Cloud-Ressourcen in ihren individuellen Konten zu testen.