API-Release-Strategien mit API Gateway
December 22, 2022
Sobald Sie Bereitstellung und Veröffentlichung ausreichend getrennt haben, besteht der nächste Schritt darin, Mechanismen zur Steuerung der schrittweisen Freigabe von Funktionen auszuwählen. Es ist entscheidend, eine Veröffentlichungsstrategie zu wählen, die es Ihnen ermöglicht, das Risiko in der Produktion zu reduzieren. Denn egal, wie sehr Sie eine neue Version Ihrer API vor der Veröffentlichung testen, der eigentliche Test erfolgt, wenn Sie sie schließlich den Kunden präsentieren.
Wir können dieses Risiko reduzieren, indem wir einen Test oder ein Experiment mit einem kleinen Teil des Datenverkehrs durchführen und das Ergebnis überprüfen. Wenn das Ergebnis erfolgreich ist, wird die Veröffentlichung für den gesamten Datenverkehr ausgelöst. Bestimmte Strategien eignen sich besser für bestimmte Szenarien und erfordern unterschiedliche Grade an zusätzlichen Diensten und Infrastruktur. In diesem Beitrag werden wir 3 beliebte API-Veröffentlichungsstrategien untersuchen, die heutzutage ein API-Gateway verwenden.
Warum ein API-Gateway in der API-Bereitstellung verwenden?
Ein Vorteil des Umstiegs auf eine API-basierte Architektur besteht darin, dass wir schnell iterieren und neue Änderungen an unseren Diensten bereitstellen können. Mit einem API-Gateway haben wir auch das Konzept von Datenverkehr und Routing für den modernisierten Teil der Architektur etabliert. Ein API-Gateway bietet Stufen, die es Ihnen ermöglichen, mehrere bereitgestellte APIs hinter demselben Gateway zu haben, und es ist in der Lage, Updates ohne Ausfallzeiten durchzuführen. Die Verwendung eines API-Gateways ermöglicht es Ihnen, die zahlreichen API-Management-Funktionen des Dienstes zu nutzen, wie z.B. Authentifizierung, Ratenbegrenzung, Beobachtbarkeit (wichtige Metriken für APIs), mehrere API-Versionierung und Stufenbereitstellungsmanagement (Bereitstellung einer API in mehreren Stufen wie dev, test, stage und prod).
Open-Source-API-Gateways (Apache APISIX und Traefik), Service-Mesh-Lösungen (Istio und Linkerd) sind in der Lage, Datenverkehr aufzuteilen und Funktionen wie Canary Release und Blue-Green-Bereitstellung zu implementieren. Mit Canary-Tests können Sie eine kritische Überprüfung einer neuen Version einer API durchführen, indem Sie nur einen kleinen Teil Ihrer Benutzerbasis auswählen. Wir werden den Canary Release im nächsten Abschnitt behandeln.
Canary Release
Ein Canary Release führt eine neue Version der API ein und leitet einen kleinen Prozentsatz des Datenverkehrs an die Canary-Version weiter. In API-Gateways ermöglicht die Datenverkehrsaufteilung, den Datenverkehr schrittweise von einer Version eines Zieldienstes zu einer anderen zu verschieben oder zu migrieren. Beispielsweise kann eine neue Version v1.1 eines Dienstes neben der ursprünglichen Version v1.0 bereitgestellt werden. Die Datenverkehrsverschiebung ermöglicht es Ihnen, Ihren neuen Dienst zunächst nur für einen kleinen Prozentsatz des Benutzerdatenverkehrs, z.B. 1%, an v1.1 zu routen und dann im Laufe der Zeit den gesamten Datenverkehr auf den neuen Dienst umzuleiten.
Dies ermöglicht es Ihnen, den neuen Dienst zu überwachen, nach technischen Problemen wie erhöhter Latenz oder Fehlerraten zu suchen und die gewünschten geschäftlichen Auswirkungen zu beobachten, wie z.B. eine Steigerung der Schlüsselperformanceindikatoren wie der Kundenkonversionsrate oder des durchschnittlichen Warenkorbwerts. Datenverkehrsaufteilung ermöglicht es Ihnen, A/B- oder multivariate Tests durchzuführen, indem Sie den Datenverkehr, der für einen Zieldienst bestimmt ist, zwischen mehreren Versionen des Dienstes aufteilen. Beispielsweise können Sie den Datenverkehr 50/50 auf Ihre Versionen v1.0 und v1.1 des Zieldienstes aufteilen und sehen, welche über einen bestimmten Zeitraum besser abschneidet. Erfahren Sie mehr über die Datenverkehrsaufteilungsfunktion im Apache APISIX Ingress Controller.
Wo angebracht, sind Canary Releases eine ausgezeichnete Option, da der Prozentsatz des Datenverkehrs, der der Canary-Version ausgesetzt ist, stark kontrolliert wird. Der Kompromiss besteht darin, dass das System eine gute Überwachung haben muss, um Probleme schnell identifizieren und bei Bedarf zurückrollen zu können (was automatisiert werden kann). Diese Anleitung zeigt Ihnen, wie Sie Apache APISIX und Flagger verwenden können, um schnell eine Canary-Release-Lösung zu implementieren.
Datenverkehrsspiegelung
Zusätzlich zur Verwendung der Datenverkehrsaufteilung zum Durchführen von Experimenten können Sie auch die Datenverkehrsspiegelung verwenden, um den Datenverkehr zu kopieren oder zu duplizieren und diesen an einen zusätzlichen Ort oder eine Reihe von Orten zu senden. Häufig werden bei der Datenverkehrsspiegelung die Ergebnisse der duplizierten Anfragen nicht an den aufrufenden Dienst oder Endbenutzer zurückgegeben. Stattdessen werden die Antworten außerhalb des normalen Betriebs auf Korrektheit überprüft, z.B. durch den Vergleich der Ergebnisse, die von einem refaktorierten und einem bestehenden Dienst generiert werden, oder es werden bestimmte Betriebseigenschaften beobachtet, während eine neue Dienstversion die Anfrage bearbeitet, wie z.B. Antwortlatenz oder benötigte CPU.
Die Verwendung der Datenverkehrsspiegelung ermöglicht es Ihnen, Dienste „im Dunkeln“ freizugeben, bei denen der Benutzer über die neue Version im Unklaren gelassen wird, Sie jedoch intern die gewünschten Auswirkungen beobachten können.
Die Implementierung der Datenverkehrsspiegelung am Rand von Systemen ist in den letzten Jahren immer beliebter geworden. APISIX bietet das proxy-mirror-Plugin an, um Client-Anfragen zu spiegeln. Es dupliziert den echten Online-Datenverkehr an den Spiegeldienst und ermöglicht eine spezifische Analyse des Online-Datenverkehrs oder des Anfrageinhalts, ohne den Online-Dienst zu unterbrechen.
Blue-Green
Blue-Green wird normalerweise an einem Punkt in der Architektur implementiert, der einen Router, ein Gateway oder einen Load Balancer verwendet, hinter dem sich eine vollständige blaue Umgebung und eine grüne Umgebung befinden. Die aktuelle blaue Umgebung repräsentiert die aktive Live-Umgebung, und die grüne Umgebung repräsentiert die nächste Version des Stacks. Die grüne Umgebung wird vor dem Umschalten auf Live-Datenverkehr überprüft, und beim Go-Live wird der Datenverkehr von blau auf grün umgeschaltet. Die blaue Umgebung ist jetzt „ausgeschaltet“, aber wenn ein Problem festgestellt wird, ist ein schnelles Rollback möglich. Die nächste Änderung würde von grün zu blau erfolgen, wobei ab der ersten Veröffentlichung hin und her gewechselt wird.
Blue-Green funktioniert gut aufgrund seiner Einfachheit und ist eine der besseren Bereitstellungsoptionen für gekoppelte Dienste. Es ist auch einfacher, persistente Dienste zu verwalten, obwohl Sie im Falle eines Rollbacks dennoch vorsichtig sein müssen. Es erfordert auch die doppelte Anzahl an Ressourcen, um parallel zur aktuell aktiven Umgebung inaktiv zu bleiben.
Datenverkehrsmanagement mit Argo Rollouts
Die diskutierten Strategien bieten viel Wert, aber die Bereitstellung selbst ist eine Aufgabe, die Sie nicht manuell verwalten möchten. Hier ist ein Tool wie Argo Rollouts wertvoll, um einige der diskutierten Bedenken praktisch zu demonstrieren.
Mit Argo ist es möglich, eine Rollout CRD (Custom Resource Definition) zu definieren, die die Strategie darstellt, die Sie für die Bereitstellung einer neuen Canary-Version Ihrer API verwenden können. Eine CRD ermöglicht es Argo, die Kubernetes API zu erweitern, um Bereitstellungsverhalten zu unterstützen. CRDs sind ein beliebtes Muster bei Kubernetes und ermöglichen es dem Benutzer, mit einer API zu interagieren, die um verschiedene Funktionen erweitert wurde.
Sie können Apache APISIX und den Apache APISIX Ingress Controller für das Datenverkehrsmanagement mit Argo Rollouts verwenden. Diese Anleitung zeigt Ihnen, wie Sie ApisixRoute mit Argo Rollouts integrieren können, indem Sie es als gewichteten Round-Robin-Load-Balancer verwenden.
Zusammenfassung
Mit dem Aufstieg des Progressive Delivery-Ansatzes und den fortgeschrittenen Anforderungen innerhalb der Continuous Delivery zuvor ist die Fähigkeit, die Bereitstellung und Veröffentlichung von Diensten (und entsprechenden APIs) zu trennen, eine leistungsstarke Technik. Die Fähigkeit, Dienste als Canary zu veröffentlichen und die Datenverkehrsaufteilungs- und Spiegelungsfunktionen des API-Gateways zu nutzen, kann Ihrem Unternehmen einen Wettbewerbsvorteil verschaffen, sowohl bei der Risikominderung einer schlechten Veröffentlichung als auch beim effektiveren Verständnis der Anforderungen Ihrer Kunden.