DETAILLIERTE EINBLICKE IN DIE KATEGORIEN
Serverlos
Einführung
Der Serverlos – Deep Dive stellt grundlegende Konzepte, Referenzarchitekturen, bewährte Methoden und praktische Aktivitäten vor, um Ihnen den Einstieg in die Erstellung serverloser Anwendungen zu erleichtern. Dies ist der ideale Ort, um anzufangen, wenn Sie neu bei Serverlos sind. Für erfahrene Serverlos-Builder haben wir Ressourcen und Links zu weiterführenden Themen.
Was ist "serverless" bzw. serverlose Datenverarbeitung?
Mit Serverlos können Sie Anwendungen und Services erstellen und ausführen, ohne sich über Server Gedanken machen zu müssen. Für Sie verringern sich die Aufgaben der Infrastrukturverwaltung wie die Bereitstellung von Servern oder Clustern, Patching, Betriebssystemwartung und Kapazitätsbereitstellung. Sie können sie für praktisch jeden Anwendungstyp oder Back-End-Service erstellen, und alles, was zum Ausführen und Skalieren Ihrer Anwendung mit hoher Verfügbarkeit erforderlich ist, wird für Sie durchgeführt.
Serverlose Anwendungen sind ereignisgesteuert und über technologie-agnostische APIs oder Messaging lose gekoppelt. Ereignisgesteuerter Code wird als Reaktion auf ein Ereignis, wie z. B. eine Zustandsänderung oder eine Endpunktanforderung, ausgeführt. Ereignisgesteuerte Architekturen entkoppeln Code vom Zustand. Die Integration zwischen lose gekoppelten Komponenten erfolgt in der Regel asynchron, mit Messaging.
AWS Lambda ist ein serverloser Compute-Service, der sich gut für ereignisgesteuerte Architekturen eignet. Lambda-Funktionen werden durch Ereignisse über integrierte Ereignisquellen wie Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) und Amazon Kinesis ausgelöst, die zur Erstellung asynchroner Integrationen verwendet werden können. Lambda-Funktionen konsumieren und produzieren Ereignisse, die dann von anderen Services konsumiert werden können.
Serverlose Architekturmuster verwenden Lambda zusammen mit anderen verwalteten Services, die ebenfalls serverlos sind. Zusätzlich zu Nachrichten- und Streaming-Diensten verwenden serverlose Architekturen verwaltete Services wie das Amazon API Gateway für die API-Verwaltung, Amazon DynamoDB für Datenspeicher und AWS Step Functions für die Orchestrierung. Die serverlose Plattform umfasst auch eine Reihe von Entwicklertools, darunter das Serverless Application Model (SAM), die Ihre Bereitstellung und das Testen Ihrer Lambda-Funktionen und serverlosen Anwendungen vereinfachen.
Was spricht für die Verwendung der serverlosen Datenverarbeitung?
Kein Servermanagement: Server müssen weder bereitgestellt noch gewartet werden. Software oder Laufzeit muss weder installiert noch gewartet oder verwaltet werden.
Flexible Skalierung: Ihre Anwendung kann automatisch oder durch Anpassen der Kapazität durch Umschalten der Verbrauchseinheiten (z. B. Durchsatz, Arbeitsspeicher) anstatt der Einheiten einzelner Server skaliert werden.
Für Wert bezahlen: Statt nach Servereinheit erfolgt die Bezahlung nach konsistentem Durchsatz oder Ausführungsdauer.
Automatisierte Hochverfügbarkeit: In der serverlosen Datenverarbeitung sind Verfügbarkeit und Fehlertoleranz integriert. Sie müssen diese Funktionen nicht entwickeln, da sie von den Services, die die Anwendung ausführen, automatisch bereitgestellt werden.
Zentrale serverlose Services
Serverlose Anwendungen werden in der Regel unter Verwendung vollständig verwalteter Services als Bausteine in den Bereichen Compute, Daten, Messaging und Integration, Streaming sowie Benutzerverwaltung und Identitätsebenen erstellt. Services wie AWS Lambda, API Gateway, SQS, SNS, EventBridge oder Step Functions bilden den Kern der meisten Anwendungen, unterstützt durch Services wie DynamoDB, S3 oder Kinesis.
| Kategorie |
Service |
Beschreibung |
|---|---|---|
| Berechnen | AWS Lambda | Mit AWS Lambda können Sie zustandslose, serverlose Anwendungen auf einer verwalteten Plattform ausführen, die Mikroservice-Architekturen, Bereitstellung und Verwaltung der Ausführung auf Funktionsebene unterstützt. |
| API Proxy | API Gateway | Amazon API Gateway ist ein vollständig verwalteter Service, der es für Entwickler einfach macht, APIs in jeder Größenordnung zu erstellen, zu veröffentlichen, zu pflegen, zu überwachen und zu sichern. Es bietet eine umfassende Plattform für das API-Management. API Gateway ermöglicht Ihnen die Verarbeitung von Hunderttausenden von gleichzeitigen API-Anrufen und übernimmt das Verkehrsmanagement, Autorisierungs- und Zugriffskontrolle, Überwachung und API-Versionsverwaltung. |
| Messaging und Integration | SNS | Amazon SNS ist ein vollständig verwalteter Pub/Sub-Messaging Service, der es einfach macht, Mikroservices, verteilte Systeme und serverlose Anwendungen zu entkoppeln und zu skalieren. |
| SQS | Amazon SQS ist ein vollständig verwalteter Message Queuing Service, der es einfach macht, Mikroservices, verteilte Systeme und serverlose Anwendungen zu entkoppeln und zu skalieren. |
|
| EventBridge | Amazon EventBridge ist ein serverloser Ereignisbus, der es einfach macht, Anwendungen unter Nutzung von Daten aus Ihren eigenen Anwendungen, integrierter Software-as-a-Service (SaaS)-Anwendungen und AWS-Services zu verbinden. |
|
| Orchestrierung | Step Functions |
AWS Step Functions macht es einfach, die Komponenten von verteilten Anwendungen und Mikroservices unter Verwendung visueller Workflows zu koordinieren. |
Los geht's!
Im Folgenden finden Sie eine Reihe von Ressourcen, die Ihnen helfen sollen, unsere wichtigsten serverlosen Services kennenzulernen.
Erstellen Sie eine Hello World Lambda-Funktion mit der AWS Lambda-Konsole und lernen Sie die Grundlagen der Ausführung von Code ohne Bereitstellung oder Verwaltung von Servern.
Erstellen Sie eine Lambda-Funktion, die von Amazon S3 jedes Mal aufgerufen wird, wenn eine Bilddatei in einen S3-Bucket hochgeladen wird, und erstellen Sie automatisch eine Miniaturansicht dieses Bildes.
Verwenden Sie die Lambda-Konsole, um eine Lambda-Funktion und einen Amazon API Gateway-Endpunkt zum Auslösen dieser Funktion zu erstellen.
Erfahren Sie, wie Sie AWS Step Functions zum Entwerfen und Ausführen eines serverlosen Workflows nutzen, mit dem mehrere AWS Lambda-Funktionen koordiniert werden können.
Grundlagen
In diesem Abschnitt erfahren Sie etwas über ereignisgesteuertes Design, das Kernprinzip hinter skalierbaren serverlosen Anwendungen.
Eine ereignisgesteuerte Architektur verwendet Ereignisse, um entkoppelte Services auszulösen und zwischen ihnen zu kommunizieren. Ein Ereignis ist eine Zustandsänderung oder eine Aktualisierung, so wie ein Artikel, das auf einer E-Commerce-Website in einen Einkaufswagen gelegt wird. Ereignisse können entweder den Status (z. B. der gekaufte Artikel, seinen Preis und eine Lieferadresse) oder Ereignisse können Identifikatoren sein (z. B. eine Benachrichtigung, dass eine Bestellung versandt wurde).
Ereignisgesteuerte Architekturen haben drei Schlüsselkomponenten: Ereignisproduzenten, Ereignisrouter und Ereignisverbraucher. Ein Hersteller veröffentlicht ein Ereignis an den Router, der die Ereignisse filtert und an die Verbraucher weiterleitet. Hersteller-Services und Verbraucher-Services sind voneinander entkoppelt, wodurch sie unabhängig voneinander skaliert, aktualisiert und bereitgestellt werden können.
Um zu verstehen, warum eine ereignisgesteuerte Architektur wünschenswert ist, wollen wir uns einen synchronen API-Aufruf ansehen.
Kunden nutzen Ihre Mikroservices, indem sie HTTP-API-Aufrufe durchführen. Amazon API Gateway hostet RESTful-HTTP-Anfragen und -Antworten an Kunden. AWS Lambda enthält die Geschäftslogik, um eingehende API-Aufrufe zu verarbeiten und DynamoDB als persistenten Speicher zu nutzen.
Bei synchronem Aufruf erwartet API Gateway eine sofortige Antwort und verfügt über einen Timeout von 30 Sekunden. Wenn bei synchronen Ereignisquellen die Antwort von Lambda mehr als 30 Sekunden benötigt, sind Sie für das Schreiben eines Codes für Wiederholungsversuche und Fehlerbehandlung verantwortlich. Aus diesem Grund werden alle Fehler oder Skalierungsprobleme, die bei einer dem Client nachgeschalteten Komponente auftreten, wie z. B. Lese-/Schreib-Kapazitätseinheiten in DynamoDB, an den Client zurückgeschoben, damit Frontend-Code verarbeitet werden kann. Durch die Verwendung asynchroner Muster und die Entkopplung dieser Komponenten können Sie ein robusteres, hoch skalierbares System aufbauen.
Lernen Sie, ein Fanout-Messaging-Szenario zu implementieren, bei dem Nachrichten an mehrere Abonnenten "gepusht" werden, wodurch die Notwendigkeit entfällt, regelmäßig nach Aktualisierungen zu prüfen oder abzufragen, und eine parallele asynchrone Verarbeitung der Nachricht durch die Abonnenten ermöglicht wird.
Erfahren Sie, wie Sie in AWS Lambda einen Ereignis-Hersteller und -Verbraucher aufbauen und eine Regel für die Weiterleitung von Ereignissen erstellen.
Lambda-Funktionen werden durch Ereignisse ausgelöst. Sie führen dann als Reaktion auf den Auslöser Code aus und können auch eigene Ereignisse erzeugen. Es gibt viele Optionen für das Auslösen einer Lambda-Funktion, und Sie haben viel Flexibilität, um benutzerdefinierte Ereignisquellen zu erstellen, die Ihren speziellen Bedürfnissen entsprechen.
Die wichtigsten Arten von Ereignisquellen sind:
- Datenspeicher, wie z. B. Amazon S3, Amazon DynamoDB oder Amazon Kinesis, können Lambda-Funktionen auslösen. Wenn es Daten speichert, zu denen Sie Änderungen verfolgen möchten, können Sie es möglicherweise als Ereignisquelle verwenden.
- Endpunkte, die Ereignisse aussenden, können Lambda aufrufen. Wenn Sie Alexa zum Beispiel bitten, etwas zu tun, gibt sie ein Ereignis aus, das eine Lambda-Funktion auslöst.
- Auch Messaging-Services, wie Amazon SQS oder Amazon SNS, können Ereignisquellen sein. Wenn Sie beispielsweise etwas zu einem SNS-Thema verschieben, könnte dies eine Lambda-Funktion auslösen.
- Wenn bestimmte Aktionen innerhalb eines Repositorys auftreten, wie z. B. das Committieren von Code in Ihr AWS CodeCommit Repo, kann eine Lambda-Funktion ausgelöst werden, um z.B. Ihren CI/CD-Buildprozess zu starten.
Erfahren Sie alles über den Aufruf von AWS Lambda-Funktionen mit unserem Entwicklerhandbuch.
In diesem Abschnitt finden Sie eine Reihe von Referenzarchitekturen, die gängige Anwendungsfälle von serverlosen Anwendungen abdecken.
-
RESTful Mikroservices
Serverlose Technologien bauen auf einer hochverfügbaren, fehlertoleranten Infrastruktur auf und ermöglichen es Ihnen, zuverlässige Services für Ihre unternehmenskritischen Workloads aufzubauen. Die AWS Serverless Kerndienste sind eng mit Dutzenden von anderen AWS-Services integriert und profitieren von einem reichhaltigen Ökosystem von AWS und Tools von Drittparteien. Dieses Ökosystem ermöglicht es Ihnen, den Build-Prozess zu rationalisieren, Aufgaben zu automatisieren, Services und Abhängigkeiten zu orchestrieren und Ihre Mikroservices zu überwachen. Mit AWS Serverless Services zahlen Sie nur für das, was Sie nutzen. Dies ermöglicht Ihnen, die Nutzung mit Ihrem Unternehmen zu steigern und die Kosten bei geringer Nutzung niedrig zu halten. All diese Merkmale machen Serverless-Technologien ideal für den Aufbau belastbarer Mikroservices.
Beispiel für eine RESTful Mikroservice-Architektur
Kunden nutzen Ihre Mikroservices, indem sie HTTP-API-Aufrufe durchführen. Im Idealfall sollten Ihre Kunden einen eng an Ihre API gebundenen Servicevertrag haben, um konsistente Erwartungen an Service Levels und Änderungskontrolle zu erreichen.
Amazon API Gateway hostet RESTful-HTTP-Anfragen und -Antworten an Kunden. In diesem Szenario bietet API Gateway integrierte Autorisierung, Drosselung, Sicherheit, Fehlertoleranz, Zuordnung von Anfrage/Antwort und Leistungsoptimierung.
AWS Lambda enthält die Geschäftslogik, um eingehende API-Aufrufe zu verarbeiten und DynamoDB als persistenten Speicher zu nutzen.
Amazon DynamoDB speichert persistent Daten von Mikroservices und skaliert nach Bedarf. Da Mikroservices oft nur auf eine Sache ausgelegt sind, wird regelmäßig ein schemenloser NoSQL-Datenspeicher eingebunden.
-
Verarbeitung von Bildern
Die Bildverarbeitung ist eine häufige Workload, die ereignisgesteuert sein kann und dynamisch auf- und abwärts skaliert werden muss, wofür serverlose Technologien gut geeignet sind. Im Allgemeinen werden Bilder in Amazon S3 gespeichert, was Lambda-Funktionen zur Verarbeitung auslösen kann. Nach der Verarbeitung kann die Lambda-Funktion die modifizierte Version an einen anderen S3-Bucket oder an API Gateway zurückgeben.
Das folgende Schaubild zeigt die Architektur von Serverless Image Handler. Diese kann mithilfe des Handbuchs für die Lösungsimplementierung und der zugehörigen AWS CloudFormation-Vorlage in wenigen Minuten bereitgestellt werden.
AWS Lambda ruft Bilder aus Ihrem Amazon Simple Storage Service-Bucket (Amazon S3) ab und verwendet Sharp, um eine modifizierte Version des Bildes an das Amazon API Gateway zurückzugeben. Die Lösung generiert einen Amazon CloudFront-Domänennamen, der zwischengespeicherten Zugriff auf die Image-Handler-API bietet.
Zusätzlich stellt die Lösung eine optionale Demo-Benutzeroberfläche bereit, über die Sie direkt mit Ihrem Image Handler API-Endpunkt interagieren können, indem Sie Bilddateien verwenden, die bereits in Ihrem Konto vorhanden sind. Die Demo-Benutzeroberfläche wird in einem Amazon S3-Bucket bereitgestellt, damit Kunden sofort mit der Bearbeitung von Bildern über eine einfache Webbenutzeroberfläche beginnen können. Mithilfe von CloudFront wird der Zugang zu den Inhalten des Website-Bereichs der Lösung beschränkt.
Bereitstellung der Lösung >>
-
Stream-Verarbeitung
Sie können AWS Lambda und Amazon Kinesis einsetzen, um Echtzeit-Streamingdaten zum Verfolgen von Anwendungsaktivitäten, die Verarbeitung von Transaktionsaufträgen, Klickstromanalyse, Datenbereinigung, das Generieren von Metriken, Filtern von Protokollen, Indexieren, die Analyse von sozialen Medien sowie die IoT-Gerätedatentelemetrie und -messung zu verarbeiten.
Beispiel einer Stream-Verarbeitungsarchitektur
Die in diesem Diagramm beschriebene Architektur kann mit einer AWS CloudFormation-Vorlage erstellt werden. Die Vorlage bewirkt Folgendes:
- Erstellt einen Kinesis-Strom
- Erstellt eine DynamoDB-Tabelle mit dem Namen -EventData
- Erstellt Lambda-Funktion 1 (-DDBEventProcessor), die Datensätze von Kinesis empfängt und Datensätze in die DynamoDB-Tabelle schreibt
- Erstellt eine IAM-Rolle und -Richtlinie, damit die Ereignisverarbeitungs-Lambda-Funktion aus dem Kinesis-Stream gelesen und in die DynamoDB-Tabelle geschrieben werden kann
- Erstellt einen IAM-Benutzer mit der Berechtigung, Ereignisse in den Kinesis-Datenstrom zusammen mit Anmeldeinformationen für den Benutzer zur Verwendung in einem API-Client zu setzen
-
Webanwendung
Mit Serverless Computing auf AWS können Sie Ihre gesamte Web-Anwendung einsetzen, ohne Server zu verwalten, Kapazitäten bereitzustellen oder für ungenutzte Ressourcen zu bezahlen. Außerdem müssen Sie keine Kompromisse bei Sicherheit, Zuverlässigkeit oder Leistung eingehen. Webanwendungen, die mit Serverless-Technologien erstellt werden, bieten hohe Verfügbarkeit und können bei Bedarf global skaliert werden.
- Die Verbraucher dieser Webanwendung könnten geographisch konzentriert oder weltweit verteilt sein. Die Nutzung von Amazon CloudFront bietet diesen Kunden nicht nur ein besseres Leistungserlebnis durch Caching und optimales Ursprungs-Routing, sondern begrenzt auch redundante Anrufe an Ihr Backend.
- Amazon S3 hostet statische Webanwendungen und wird sicher über CloudFront bereitgestellt.
- Ein Amazon Cognito-Benutzerpool bietet Funktionen zur Benutzerverwaltung und Identitätsprovider für Ihre Webanwendung.
- In vielen Szenarien, in denen statische Inhalte von Amazon S3 vom Verbraucher heruntergeladen werden, müssen dynamische Inhalte an Ihre Anwendung gesendet oder von ihr empfangen werden. Wenn ein Benutzer beispielsweise Daten über ein Formular einreicht, dient das Amazon API Gateway als sicherer Endpunkt, um diese Anrufe zu tätigen und Antworten zurückzugeben, die über Ihre Webanwendung angezeigt werden.
- Eine AWS Lambda-Funktion ermöglicht das Erstellen, Lesen, Aktualisieren und Löschen (CRUD) von Operationen auf der DynamoDB für Ihre Webanwendung.
- Amazon DynamoDB kann den NoSQL-Datenspeicher im Backend bereitstellen, um mit dem Verkehr Ihrer Webanwendung elastisch zu skalieren.
- Die Verbraucher dieser Webanwendung könnten geographisch konzentriert oder weltweit verteilt sein. Die Nutzung von Amazon CloudFront bietet diesen Kunden nicht nur ein besseres Leistungserlebnis durch Caching und optimales Ursprungs-Routing, sondern begrenzt auch redundante Anrufe an Ihr Backend.
Eine bewährte Methode für Ihre Bereitstellung in einer Mikroservice-Architektur besteht darin, sicherzustellen, dass eine Änderung den Dienstleistungsvertrag des Verbrauchers nicht bricht. Wenn der API-Besitzer eine Änderung vornimmt, die den Servicevertrag bricht und der Verbraucher darauf nicht vorbereitet ist, kann es zu Ausfällen kommen.
Um die Auswirkungen von Änderungen an Ihrer Bereitstellung zu verstehen, müssen Sie wissen, welche Verbraucher Ihre API verwenden. Sie können Metadaten über die Nutzung mit Hilfe von API-Schlüsseln sammeln, und diese können auch als eine Art Vertrag fungieren, wenn eine Änderung an einer API vorgenommen wird.
Wenn Kunden die Auswirkungen von Änderungen an einer API abschwächen möchten, können sie die API klonen und Kunden an eine andere Subdomain (z. B. v2.my-service.com) weiterleiten, um sicherzustellen, dass bestehende Kunden nicht beeinträchtigt werden. Dieser Ansatz ermöglicht es den Kunden, nur neue Änderungen am neuen API-Service-Vertrag vorzunehmen, bringt aber Kompromisse mit sich. Kunden, die diesen Ansatz wählen, müssen zwei Versionen der API pflegen und werden sich mit der Infrastrukturverwaltung und dem Bereitstellungsaufwand befassen.
| Bereitstellung |
Auswirkungen auf den Kunden |
Zurücksetzen | Faktoren des Ereignismodells |
Geschwindigkeit Ihrer Bereitstellung |
|---|---|---|---|---|
| Alles auf einmal | Alles auf einmal | Ältere Version erneut bereitstellen | Jedes Ereignismodell mit niedriger Gleichzeitigkeitsrate | Sofort |
| Blau/Grün | Alles auf einmal mit einem gewissen Grad von Tests der Produktionsumgebung im Vorfeld | Verkehr auf vorherige Umgebung zurückführen | Besser für asynchrone und synchrone Ereignismodelle bei Workloads mit mittlerer Gleichzeitigkeit | Minuten bis Stunden der Validierung und dann sofort an die Kunden |
| Canary/Linear | 1–10 % typische anfängliche Verkehrsverlagerung, dann stufenweise Erhöhung oder alles auf einmal | 100 % des Datenverkehrs auf vorherige Bereitstellung zurückführen | Besser für Workloads mit hoher Gleichzeitigkeit | Minuten bis Stunden |
-
Alles-auf-einmal-Bereitstellungen
Bei Alles-auf-einmal-Bereitstellungen müssen Änderungen an der bestehenden Konfiguration vorgenommen werden. Ein Vorteil dieser Art der Bereitstellung besteht darin, dass Backend-Änderungen an Datenspeichern, wie z. B. einer relationalen Datenbank, einen viel geringeren Aufwand zur Abstimmung von Transaktionen während des Änderungszyklus erfordern. Diese Art der Bereitstellung ist zwar mit geringem Aufwand verbunden und kann in Modellen mit niedriger Währung mit geringen Auswirkungen durchgeführt werden, birgt jedoch ein zusätzliches Risiko, wenn es um Rollback geht, und verursacht in der Regel Ausfallzeiten. Ein Beispielszenario für die Verwendung dieses Bereitstellungsmodells ist für Entwicklungsumgebungen, in denen die Auswirkungen auf den Benutzer minimal sind.
-
Blau/Grün-Bereitstellungen
Beim Blau/Grün-Bereitstellungsmuster verlagern Kunden einen Teil des Datenverkehrs in die neue Live-Umgebung (grün), während die alte Umgebung (blau) warm gehalten wird, für den Fall, dass das System zurückgesetzt werden muss. Bei der Verwendung dieses Musters ist es am besten, Änderungen klein zu halten, damit Rollbacks schnell und einfach durchgeführt werden können. Blau/Grün-Bereitstellungen sollen Ausfallzeiten reduzieren, und viele Kunden nutzen sie für die Bereitstellung in der Produktion. Mit API Gateway können Sie auf einfache Weise festlegen, welcher Prozentsatz des Datenverkehrs in die neue grüne Umgebung verlagert wird, wodurch es zu einem effektiven Werkzeug für dieses Bereitstellungsmuster wird.
Diese Art der Bereitstellung eignet sich besonders für serverlose Architekturen, die sowohl zustandslos als auch von der zugrunde liegenden Infrastruktur entkoppelt sind.
Sie benötigen die richtigen Indikatoren, um zu wissen, ob ein Rollback erforderlich ist. Als bewährte Methode empfehlen wir Kunden, die hochauflösende CloudWatch-Metriken verwenden, die in 1-Sekunden-Intervallen überwachen und Abwärtstrends schnell erfassen können. In Verbindung mit CloudWatch-Alarmen können Sie ein beschleunigtes Rollback ermöglichen. CloudWatch-Metriken können auf API Gateway, Step Functions, Lambda (einschließlich benutzerdefinierter Metriken) und DynamoDB erfasst werden.
-
Canary-Bereitstellungen
Die Canary-Bereitstellungen sind für Sie eine immer häufiger genutzte Möglichkeit, die neue Version einer Software in einer kontrollierten Umgebung zu nutzen und schnelle Bereitstellungszyklen zu ermöglichen. Bei Canary-Bereitstellungen wird eine kleine Anzahl von Anfragen zu der neuen Änderung gestellt, um die Auswirkungen auf eine kleine Anzahl Ihrer Benutzer zu analysieren.
Mit canary-Bereitstellungen in API Gateway können Sie eine Änderung an Ihrem Backend-Endpunkt (z. B. Lambda) bereitstellen, während der HTTP-Endpunkt des API Gateways für Verbraucher weiterhin derselbe bleibt. Darüber hinaus können Sie auch steuern, wie viel Prozent des Datenverkehrs zu neuen Bereitstellungen und für einen kontrollierten Verkehrsübergang weitergeleitet wird. Ein praktisches Szenario für eine Canary-Bereitstellung könnte eine neue Website sein. Sie können die Klickraten bei einer kleinen Anzahl von Endbenutzern überwachen, bevor Sie den gesamten Datenverkehr auf die neue Bereitstellung verlagern.
Implementierung von Canary-Bereitstellungen von AWS Lambda-Funktionen mit Alias-VerkehrsverlagerungLernen Sie, wie man Canary-Bereitstellungen von AWS Lambda-Funktionen implementiert.
Schrittweise Bereitstellung von serverlosen AnwendungenAWS SAM bietet schrittweise Lambda-Bereitstellungen für Ihre serverlose Anwendung.