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.
# Canary-Bereitstellungen von Amazon ECS
Bei Canary-Bereitstellungen wird zunächst ein kleiner Prozentsatz des Datenverkehrs für erste Tests an die neue Version weitergeleitet. Nach erfolgreichem Abschluss der Canary-Phase wird dann der gesamte verbleibende Verkehr auf einmal umgeleitet. Mit Amazon ECS Canary-Bereitstellungen können Sie neue Service-Revisionen anhand des tatsächlichen Benutzerdatenverkehrs validieren und gleichzeitig das Risiko minimieren. Dieser Ansatz bietet eine kontrollierte Methode zur Implementierung von Änderungen mit der Möglichkeit, die Leistung zu überwachen und bei erkannten Problemen schnell ein Rollback durchzuführen.
## Ressourcen, die an einem Canary-Einsatz beteiligt sind
Im Folgenden sind Ressourcen aufgeführt, die an der Bereitstellung von Amazon ECS Canary beteiligt sind:
+ Verkehrsverlagerung — Der Prozess, den Amazon ECS verwendet, um den Produktionsverkehr zu verlagern. Bei Amazon ECS Canary-Bereitstellungen erfolgt die Verlagerung des Datenverkehrs in zwei Phasen: zuerst auf den Canary-Prozentsatz, dann, um die Bereitstellung abzuschließen.
+ Canary-Prozentsatz — Der Prozentsatz des Traffics, der während des Testzeitraums auf die neue Version umgeleitet wurde.
+ Canary-Bake-Time — Die Dauer, für die die Canary-Version überwacht werden muss, bevor mit der vollständigen Bereitstellung fortgefahren wird.
+ Bereitstellungs-Bake-Zeit — Die Zeit in Minuten, die Amazon ECS nach der Verlagerung des gesamten Produktionsdatenverkehrs auf die neue Service-Revision wartet, bevor die alte Service-Revision beendet wird. Dies ist der Zeitraum, in dem sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden, nachdem sich der Produktionsverkehr geändert hat.
+ Lebenszyklusphasen – Eine Reihe von Ereignissen während des Bereitstellungsvorgangs, z. B. „nach der Verschiebung des Produktionsdatenverkehrs“.
+ Lifecycle-Hook — Eine Lambda-Funktion oder ein Pausenpunkt in einer bestimmten Lebenszyklusphase. Lambda-Hooks rufen Lambda-Funktionen auf, die Sie für die Ausführung von benutzerdefiniertem Code definiert haben. Pause-Hooks unterbrechen die Bereitstellung und warten auf Ihren Aufruf`ContinueServiceDeployment`, um fortzufahren.
+ Zielgruppe – Eine Ressource für Elastic Load Balancing, die verwendet wird, um Anfragen an ein oder mehrere registrierte Ziele (z. B. EC2-Instances) weiterzuleiten. Wenn Sie einen Listener erstellen, geben Sie eine Zielgruppe für die Standardaktion an. Der Datenverkehr wird an die in der Listener-Regel angegebene Zielgruppe weitergeleitet.
+ Listener – Eine Ressource für Elastic Load Balancing, die Verbindungsanforderungen mit dem von Ihnen konfigurierten Protokoll und Port überprüft. Die Regeln, die Sie für einen Listener definieren, bestimmen, wie der Amazon ECS Anforderungen an registrierte Ziele weiterleitet.
+ Regel – Eine Ressource für Elastic Load Balancing, die einem Listener zugeordnet ist. Eine Regel definiert, wie Anfragen weitergeleitet werden, und besteht aus einer Aktion, einer Bedingung und einer Priorität.
## Überlegungen
Berücksichtigen Sie bei der Auswahl eines Bereitstellungstyps Folgendes:
+ Ressourcenverbrauch: Bei Canary-Bereitstellungen werden während des Testzeitraums sowohl die ursprünglichen als auch die Canary-Tasksets gleichzeitig ausgeführt, wodurch der Ressourcenverbrauch steigt.
+ Verkehrsvolumen: Stellen Sie sicher, dass der Canary-Prozentsatz ausreichend Traffic generiert, um die neue Version sinnvoll validieren zu können.
+ Komplexität der Überwachung: Bei der Bereitstellung von Canary müssen die Kennzahlen zweier verschiedener Versionen gleichzeitig überwacht und verglichen werden.
+ Rollback-Geschwindigkeit: Bereitstellungen auf Canary ermöglichen ein schnelles Rollback, indem der Traffic wieder auf die ursprünglichen Aufgaben umgeleitet wird.
+ Risikominderung: Die Bereitstellungen von Canary bieten eine hervorragende Risikominderung, da sie das Risiko auf einen kleinen Prozentsatz der Benutzer begrenzen.
+ Bereitstellungsdauer: Die Bereitstellungen von Canary beinhalten Evaluierungszeiträume, die zwar die gesamte Bereitstellungszeit verlängern, aber auch Validierungsmöglichkeiten bieten.
## So funktionieren die Bereitstellungen von Canary
Der Bereitstellungsprozess von Amazon ECS Canary folgt einem strukturierten Ansatz mit sechs verschiedenen Phasen, die sichere und zuverlässige Anwendungsupdates gewährleisten. Jede Phase dient einem bestimmten Zweck bei der Validierung und Umstellung Ihrer Anwendung von der aktuellen Version (blau) auf die neue Version (grün).
1. Vorbereitungsphase: Erstellen Sie die grüne Umgebung neben der bestehenden blauen Umgebung.
1. Bereitstellungsphase: Stellen Sie die neue Service-Revision in der grünen Umgebung bereit. Amazon ECS startet neue Aufgaben mit der aktualisierten Service-Revision, während die blaue Umgebung weiterhin den Produktionsdatenverkehr bedient.
1. Testphase: Validieren Sie die grüne Umgebung mithilfe von Test-Datenverkehrs-Routing. Der Application Load Balancer leitet Testanfragen an die grüne Umgebung weiter, während der Produktionsverkehr weiterhin blau ist.
1. Phase der Verlagerung des kanarischen Datenverkehrs: Während der Canary-Phase wird der konfigurierte Prozentsatz des Traffics auf die neue Version des grünen Dienstes umgestellt, gefolgt von der Verlagerung von 100,0% des Traffics auf die Revision des grünen Dienstes
1. Überwachungsphase: Überwachen Sie den Zustand der Anwendung, die Leistungsmetriken und den Alarmstatus während der Bake-Zeit. Ein Rollback-Vorgang wird eingeleitet, wenn Probleme erkannt werden.
1. Abschlussphase: Schließen Sie die Bereitstellung ab, indem Sie die blaue Umgebung beenden.
Die Canary Traffic Shift-Phase folgt diesen Schritten:
+ Anfänglich — Die Bereitstellung beginnt damit, dass 100% des Datenverkehrs an die blaue (aktuelle) Service-Revision weitergeleitet werden. Die grüne (neue) Dienstrevision empfängt Testverkehr, aber zunächst keinen Produktionsverkehr.
+ Kanarische Verkehrsverlagerung — Dies ist eine zweistufige Strategie zur Verkehrsverlagerung.
+ Schritt 1:10,0% auf Grün, 90,0% auf Blau
+ Schritt 2:100,0% zu Grün, 0,0% zu Blau
+ Canary Bake-Time — Wartet auf eine konfigurierbare Dauer (Canary Bake Time), nachdem sich der Canary Traffic verlagert hat, um die Leistung der neuen Version angesichts der erhöhten Verkehrslast überwachen und validieren zu können.
+ Lifecycle-Hooks — Optionale Lambda-Funktionen oder Pause-Hooks können in verschiedenen Lebenszyklusphasen während der Bereitstellung konfiguriert werden, um eine automatische Validierung, Überwachung oder benutzerdefinierte Logik durchzuführen. Hooks, die für jeden Schritt der Verkehrsverlagerung in der Produktion konfiguriert `PRE_PRODUCTION_TRAFFIC_SHIFT` sind `PRODUCTION_TRAFFIC_SHIFT` oder bei jedem Schritt aufgerufen werden.
### Lebenszyklusphasen der Bereitstellung
Der Canary-Bereitstellungsprozess durchläuft verschiedene Lebenszyklusphasen, die jeweils mit spezifischen Verantwortlichkeiten und Validierungsprüfpunkten verbunden sind. Wenn Sie diese Phasen verstehen, können Sie den Bereitstellungsfortschritt überwachen und Probleme effektiv beheben.
Jede Lifecycle-Phase kann bis zu 24 Stunden dauern, und zusätzlich kann jeder Traffic-Shift-Schritt in PRODUCTION\_TRAFFIC\_SHIFT bis zu 24 Stunden dauern. Wir empfehlen, dass der Wert unter 24 Stunden bleibt. Das liegt daran, dass asynchrone Prozesse Zeit benötigen, um die Hooks auszulösen. Das System kommt zu einem Timeout, die Bereitstellung schlägt fehl und initiiert dann ein Rollback, wenn eine Phase 24 Stunden erreicht ist.
CloudFormation Für Bereitstellungen gelten zusätzliche Timeout-Einschränkungen. Das 24-Stunden-Zeitlimit bleibt zwar in Kraft, CloudFormation erzwingt jedoch ein Limit von 36 Stunden für den gesamten Einsatz. CloudFormation schlägt bei der Bereitstellung fehl und leitet dann ein Rollback ein, wenn der Vorgang nicht innerhalb von 36 Stunden abgeschlossen ist.
Für Pause-Hooks können Sie den Timeout auf bis zu 20.160 Minuten (14 Tage) konfigurieren. Der allgemeine Timeout für die Bereitstellung beträgt 30 Tage.
**Lebenszyklusphasen**
| Lebenszyklusphasen | Description | Lifecycle Hook-Unterstützung |
| --- | --- | --- |
| RECONCILE\_SERVICE | Diese Phase tritt nur ein, wenn Sie eine neue Servicebereitstellung mit mehr als einer Service-Revision im Status ACTIVE starten. | Ja |
| PRE\_SCALE\_UP | Die grüne Service-Revision wurde nicht gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja |
| SCALE\_UP | Der Zeitpunkt, zu dem die grüne Service-Revision auf 100 % aufskaliert wird und neue Aufgaben gestartet werden. Die grüne Service-Revision bedient derzeit keinen Datenverkehr. | Nein |
| POST\_SCALE\_UP | Die grüne Service-Revision wurde gestartet. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Es gibt keinen Test-Datenverkehr. | Ja |
| TEST\_TRAFFIC\_SHIFT | Die blauen und grünen Service-Revisionen werden ausgeführt. Die blaue Service-Revision wickelt 100 % des Produktionsdatenverkehrs ab. Die grüne Service-Revision wird von 0 auf 100 % des Test-Datenverkehrs migriert. | Ja (nur Lambda) |
| POST\_TEST\_TRAFFIC\_SHIFT | Die Verlagerung des Test-Datenverkehrs ist abgeschlossen. Die grüne Service-Revision wickelt 100 % des Test-Datenverkehrs ab. | Ja |
| VERKEHRSSCHICHT VOR DER PRODUKTION | Tritt vor jedem Schritt der Verkehrsverlagerung in der Produktion auf. Bei Canary geschieht dies vor der Verkehrsverlagerung auf Canary und vor der verbleibenden Verkehrsverlagerung. | Ja |
| PRODUCTION\_TRAFFIC\_SHIFT | Der Canary-Produktionsverkehr wird auf Green Revision umgeleitet und der Lifecycle-Hook wird mit einem Timeout von 24 Stunden aufgerufen. Im zweiten Schritt wird der verbleibende Produktionsverkehr auf die grüne Version umgestellt. | Ja (nur Lambda) |
| POST\_PRODUCTION\_TRAFFIC\_SHIFT | Die Verlagerung des Produktionsdatenverkehrs ist abgeschlossen. | Ja |
| BAKE\_TIME | Die Dauer, in der sowohl die blaue als auch die grüne Service-Revision gleichzeitig ausgeführt werden. | Nein |
| CLEAN\_UP | Die blaue Service-Revision wurde vollständig auf 0 laufende Aufgaben herunterskaliert. Die grüne Service-Revision ist nach dieser Phase nun die Service-Revision der Produktion. | Nein |
### Konfigurationsparameter
Für Canary-Bereitstellungen sind die folgenden Konfigurationsparameter erforderlich:
+ Canary-Prozentsatz — Der Prozentsatz des Traffics, der während der Canary-Phase zur neuen Service-Revision weitergeleitet wird. Dies ermöglicht Tests mit einer kontrollierten Teilmenge des Produktionsverkehrs.
+ Canary Bake-Time — Die Wartezeit während der Canary-Phase, bevor der restliche Traffic auf die neue Serviceversion umgestellt wird. Dies bietet Zeit, um die neue Version zu überwachen und zu validieren.
### Verwaltung des Datenverkehrs
Canary-Bereitstellungen verwenden Load Balancer-Zielgruppen, um die Verteilung des Datenverkehrs zu verwalten:
+ Ursprüngliche Zielgruppe — Enthält Aufgaben aus der aktuellen stabilen Version und erhält den Großteil des Traffics.
+ Canary-Zielgruppe — Enthält Aufgaben aus der neuen Version und erhält einen kleinen Prozentsatz des Traffics zum Testen.
+ Gewichtetes Routing — Der Load Balancer verwendet gewichtete Routing-Regeln, um den Traffic auf die Zielgruppen auf der Grundlage des konfigurierten Canary-Prozentsatzes zu verteilen.
### Überwachung und Validierung
Effektive Bereitstellungen von Canary sind auf eine umfassende Überwachung angewiesen:
+ Gesundheitschecks — Beide Taskgruppen müssen die Gesundheitschecks bestehen, bevor sie Traffic empfangen.
+ Vergleich der Kennzahlen — Vergleichen Sie wichtige Leistungsindikatoren zwischen der Originalversion und der Canary-Version, z. B. Reaktionszeit, Fehlerrate und Durchsatz.
+ Automatisches Rollback — Konfiguriere CloudWatch Alarme, die automatisch ein Rollback auslösen, wenn die Leistung der Canary-Version beeinträchtigt wird.
+ Manuelle Validierung — Nutzen Sie den Testzeitraum, um Protokolle, Messwerte und Benutzerfeedback manuell zu überprüfen, bevor Sie fortfahren.
### Bewährte Methoden für den Einsatz von Canary
Halten Sie sich an diese bewährten Methoden, um sicherzustellen, dass Canary-Bereitstellungen mit Diensten erfolgreich sind.
#### Wählen Sie die entsprechenden Prozentsätze für den Traffic
Berücksichtigen Sie bei der Auswahl der Prozentsätze für den kanarischen Verkehr die folgenden Faktoren:
+ Fangen Sie klein an — Beginnen Sie mit 5-10% des Traffics, um die Auswirkungen zu minimieren, falls Probleme auftreten.
+ Berücksichtigen Sie die Kritikalität der Anwendungen — Verwenden Sie kleinere Prozentsätze für unternehmenskritische Anwendungen und höhere Prozentsätze für weniger kritische Dienste.
+ Traffic-Volumen berücksichtigen — Stellen Sie sicher, dass der Prozentsatz der Besucherzahlen ausreichend generiert, um eine aussagekräftige Validierung zu ermöglichen.
#### Legen Sie angemessene Testzeiträume fest
Konfigurieren Sie Testzeiträume auf der Grundlage der folgenden Überlegungen:
+ Planen Sie ausreichend Zeit ein — Legen Sie Testzeiträume fest, die lang genug sind, um aussagekräftige Leistungsdaten zu erfassen, in der Regel 10 bis 30 Minuten.
+ Berücksichtigen Sie die Verkehrsmuster — Berücksichtigen Sie die Verkehrsmuster Ihrer Anwendung und die Zeiten der Spitzenauslastung.
+ Balance zwischen Geschwindigkeit und Sicherheit — Längere Testzeiträume liefern mehr Daten, aber die Bereitstellungsgeschwindigkeit ist gering.
#### Implementieren Sie eine umfassende Überwachung
Richten Sie eine Überwachung ein, um die Leistung von Canary Deployment zu verfolgen:
+ Wichtige Kennzahlen — Überwachen Sie die Reaktionszeit, die Fehlerrate, den Durchsatz und die Ressourcenauslastung für beide Aufgabengruppen.
+ Alarm-based Rollback — Konfigurieren Sie CloudWatch Alarme, die automatisch ein Rollback auslösen, wenn Metriken Schwellenwerte überschreiten.
+ Vergleichende Analyse — Richten Sie Dashboards ein, um Metriken zwischen Original- und Canary-Versionen Seite an Seite zu vergleichen.
+ Geschäftskennzahlen — Schließen Sie neben technischen Kennzahlen auch unternehmensspezifische Kennzahlen wie Konversionsraten oder Nutzerinteraktion ein.
#### Planen Sie Rollback-Strategien
Bereiten Sie sich mit diesen Strategien auf mögliche Rollback-Szenarien vor:
+ Automatisches Rollback — Konfigurieren Sie automatische Rollback-Trigger auf der Grundlage von Zustandsprüfungen und Leistungsmetriken.
+ Manuelle Rollback-Verfahren — Dokumentieren Sie klare Verfahren für manuelles Rollback, wenn automatische Trigger nicht alle Probleme erfassen.
+ Rollback-Tests — Testen Sie die Rollback-Verfahren regelmäßig, um sicherzustellen, dass sie bei Bedarf korrekt funktionieren.
#### Vor der Bereitstellung gründlich validieren
Sorgen Sie für eine gründliche Validierung, bevor Sie mit der Bereitstellung von Canary fortfahren:
+ Pre-deployment Testen — Testen Sie Änderungen in den Staging-Umgebungen gründlich, bevor Sie Canary einsetzen.
+ Konfiguration der Systemdiagnose — Stellen Sie sicher, dass die Integritätsprüfungen die Einsatzbereitschaft und Funktionalität der Anwendung genau widerspiegeln.
+ Überprüfung der Abhängigkeiten — Stellen Sie sicher, dass neue Versionen mit Downstream- und Upstream-Diensten kompatibel sind.
+ Datenkonsistenz — Stellen Sie sicher, dass Änderungen am Datenbankschema und Datenmigrationen abwärtskompatibel sind.
#### Koordinieren Sie die Beteiligung des Teams
Sorgen Sie für eine effektive Teamkoordination bei Canary-Einsätzen:
+ Zeitfenster für den Einsatz — Planen Sie Canary-Einsätze während der Geschäftszeiten ein, wenn die Teams zur Überwachung und Reaktion zur Verfügung stehen.
+ Kommunikationskanäle — Richten Sie klare Kommunikationskanäle für den Einsatzstatus und die Eskalation von Problemen ein.
+ Rollenzuweisungen — Definieren Sie Rollen und Verantwortlichkeiten für die Überwachung, Entscheidungsfindung und Ausführung von Rollbacks.