Einführung in Continuous Deployment, Teil 2 Blue/Green-Deployment in AWS

Blue/Green-Deployments sind eine spannende Strategie zur Realisierung von Continuous Delivery. In der Public Cloud mit Amazon Web Services, kurz AWS, lassen sie sich sogar mit vertretbarem Aufwand umsetzen. Was aber theoretisch ganz nett klingt, wirft in der Praxis dann doch häufig Fragen auf.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Nicht selten wird das Konzept von Blue/Green-Deployments missverstanden, und auch die Begrifflichkeiten sind nicht immer einheitlich. Der Streaming-Anbieter Netflix beispielsweise spricht von A/B-Deployments.

Grundsätzlich sollte aber klar sein, dass man unter Blue/Green-Deployment ein Konzept versteht, bei dem der Traffic-Flow zwischen zwei weitgehend identischen Deployment-Sets geswitched wird. Dabei kann man unter „Deployment“ alles Mögliche verstehen, vom einzelnen Servern bis zu einer Gruppe von virtuellen Maschinen, neudeutsch auch Multi-Tier-Applikationen aus Web-Server, App-Servern und DB-Servern genannt.

Wichtig ist das Verständnis, dass Blue/Green-Deployments kein Konzept auf Applikations-Ebene, sondern auf „Hardware“-Ebene ist, auch wenn es sich in der Praxis um VMs oder Container handelt. Im Verantwortungsbereich der Applikation liegt der inkrementelle Rollout von Features oder das Testing, nicht aber das Aktivieren oder Deaktivieren von Features, da jeglicher Traffic „immer“ zum ersten oder zum zweiten Set geht.

Essenziell ist aber, dass der Übergang (Switch) „sauber“ passiert, wie nach dem Umlegen eines Hebels – und hier liegt der Hase im Pfeffer. Im Folgenden demonstrieren wir verschiedene Switchover-Methoden bei in Amazon Web Services realisierten Blue/Green-Deployments. Im zweiten Teil dieses Beitrages soll ein solches Deployment in AWS dann gezielt realisiert werden.

Einführung in Continuous Deployment, Teil 1

Continuous Delivery mit Blue/Green-Deployments

Blue/Green-Deployments in AWS

Für den Prozess des eigentlichen Switchovers bieten sich verschiedene Verfahren an. Amazon als derzeit größter Public-Cloud-Betreiber stellt vorgefertigte Konzepte zur Realisierung von Blue/Green-Deployments (Whitepaper) bereit, aber auch Pivotal mit CloudFoundry und andere Cloud-Anbieter haben entsprechende Konzepte entwickelt. So propagiert Amazon AWS je nach Anforderung mehrere Modelle für das Traffic-Routing in Blue/Green-Deployments, z. B.

• 1. via DNS-Redirection mit AWS Route 53, Amazons skalierbarer Hosted-DNS-Service

• 2. über Load-Balancer, z. B. Amazon AWS Elastic Load Balancers (ELB) sowie

• 3. durch eine Kombination von ELB und AWS Auto Scaling.

Version-Switching durch Ändern von DNS-Records

Eines der populärsten Verfahren – und in AWS relativ einfach zu realisieren – ist das Switching via DNS-Redirection. Dabei lässt sich das Blue/Green-Switching durch Anpassen des CNAME-Records im DNS erreichen. Hierbei definiert man eine Hosted-DNS-Zone in Route 53 sowie ein entsprechendes „Ressource Record“, um dem jeweiligen Set in einem öffentlichen Subnetz (Public Subnet) den Domain-Namen bekannt zu machen und festzulegen, wie der Traffic für diese DNS-Domain zu routen ist.

AWS ist wie Lego. So funktioniert DNS-Routing via Record-Updates mit einer breiten Palette an Blue/Green-Konfigurationen in AWS, solange man den Endpoint in der Umgebung per DNS-Namen oder IP-Adresse ansprechen kann. Das Switching via CNAME-Updates in Route 53 lässt sich beispielsweise auch mit einem Chef-Konfigurationsmanagement kombinieren, das bei AWS über den OpsWorks-Service bereit gestellt wird.

Beliebt ist es auch, die Datenbank-Server-Tiers nicht als virtuelle Maschinen (EC2-Instanzen), sondern als Managed Service bereitzustellen. Amazons Relational Database Service (RDS) stellt eine breite Palette freier und kommerzieller Datenbank-Services von PostgreSQL über MySQL bis Oracle als Dienst zur Verfügung – darunter auch Aurora, eine kommerzielle MySQL-Version speziell von und für AWS, die Enterprise-Features zu einem Zehntel der Kosten sonstiger Enterprise-Datenbanken ermöglicht. Der Vorteil an RDS ist, dass die einzelnen Datenbankinstanzen per einfacher Klick-Option auch als Multi-Availability-Zone-Deployment bereitgestellt werden können.

Switching via AWS Elastic Load Balancing

Einige Experten raten von der DNS-Redirection via CNAME ab, unter anderem weil ja meist mehrere DNS-Clients auf mehreren Ebenen involviert sind, von denen nicht alle notwendigerweise TTL-Regeln wie vorgesehen befolgen. Daher kann es sein, dass der „Switch“ (Übergang) wegen der involvierten Caches (TTL) möglicherweise nicht sauber vonstatten geht, sodass eigentlich beide „Sets“ noch eine Zeit aktiv bleiben müssten.

Eine „saubere“ Switchover-Methode besteht in der Verwendung eines oder mehrerer Load Balancer. Amazon Elastic Loadbalancing kennt sogar zwei Typen von Load Balancern. Beide bieten hohe Verfügbarkeit und automatische Skalierung. Der Classic Load Balancer verteilt den Datenverkehr auf Basis von Anwendungs- oder Netzwerkinformationen. Alternativ verteilt der Application Load Balancer den Datenverkehr auf Grundlage erweiterter Anwendungsinformationen, welche auch die Inhalte der Anfrage berücksichtigen.

Mittels Load Balancing lässt sich ein komplett neues Set an EC2-Instanzen starten und am ELB registrieren. Empfängt das neue Set dann Traffic, kann das alte vom ELB deregistriert werden. Dies passiert allerdings nicht unmittelbar, sondern dauert eine gewisse Zeit, weil meist noch offene Anfragen beantwortet werden müssen. Es ist nicht empfehlenswert, den Switchover-Vorgang durch Abbrechen von Anfragen zu beschleunigen. Idealerweise sollten offene Anfragen noch vom „alten“ Set beantwortet werden.

Hat der betreffende Service jedoch sehr lange Antwortzeiten, kann man darüber nachdenken, im ELB Connection Draining einzurichten

Dass viele Experten das Realisieren des Switchings über das wechselseitige Registrieren an einem gemeinsamen ELB empfehlen, liegt auch an der Skalierung desselben. Ein neuer Load Balancer für jedes einzelne Set – bspw. in Kombination mit DNS-Switching – wäre nämlich höchst wahrscheinlich nicht ausreichend schnell in der Lage, die Last z. B. eines Web-Server-Tiers der jeweils einen Seite aufrechtzuerhalten bzw. zu übernehmen.

Benutzt man aber den gleichen Load Balancer für beide Sets, ist dieser quasi zu jedem Zeitpunkt vorskaliert und damit einsatzbereit. Allerdings sorgt ELB in AWS von sich aus dafür, dass nur „fehlerfreie“ EC2-Instanzen Traffic empfangen. Etwaige fehlerhafte EC2 Instances werden automatisch erkannt und jeglicher Datenverkehr automatisch über die verbleibenden fehlerfreien Instanzen geleitet.

Zusätzlich profitiert der Load Balancer in AWS vom Konzept der Verfügbarkeitszonen (Availability Zones, AZ) in AWS. Sind nämlich sämtliche EC2-Instanzen in einer AZ fehlerhaft, leitet Elastic Load Balancing den Traffic an fehlerfreien EC2-Instanzen in der jeweils anderen AZ weiter, sofern vorher ein Blue/GreenMulti-AZ-Deployment für EC2-Instances festgelegt wurde. Eine noch bessere Skalierung erhält man, kombiniert man beim Blue/Green-Deployment in AWS ELB mit AWS Auto-Scaling.

Weitere Tipps für Blue/Green-Deployments in AWS

Wird bereits Traffic zum neuen Instanz-Set geschickt, obwohl dieses noch nicht bereit ist, kann das verständlicherweise zu großen Komplikationen führen. So nutzen viele Java-Anwendungen beispielsweise Tomcat als Applikations-Server.

Selbst wenn eine EC2-Instanz ihre Boot-Sequenz vollständig abgeschlossen hat, muss auf Anwendungsebene (Application Level) noch einiges passieren, bevor die Anwendung tatsächlich für die Verarbeitung von Datenverkehr bereit ist; etwa das Initialisieren von Datenstrukturen, Einlesen von Konfigurationsdaten, Konfigurieren des Loggings, „Anwärmen“ des Cache etc. Daher ist es empfehlenswert, einen Load-Balancer-Endpoint in der Applikation, bzw. Dienst einzurichten, der mitteilt, wann die Applikation zum Empfang von Traffic bereit ist.

DNS Failover und ELB

Route 53 und ELB arbeiten allerdings auf Wunsch auch Hand in Hand. So können Administratoren beispielsweise die Zustandsprüfungs- und DNS Failover-Funktionen von Route 53 zur Erhöhung der Verfügbarkeit der Anwendungen hinter ELB verwenden, damit Route 53 nicht fehlschlägt, wenn fehlerhafte EC2-Instanzen im Load Balancer registriert sind oder der Load Balancer selbst fehlerhaft ist.

Zusätzlich lässt sich das Feature „Route 53 DNS Failover“ benutzen, um bei in mehreren AWS-Regionen ausgeführten Anwendungen alternative Load Balancer für Failover in den einzelnen Regionen festzulegen. Falls eine Anwendung nicht reagiert, entfernt Route 53 den nicht verfügbaren Load Balancer-Endpoint vom Dienst und leitet den Traffic zu einem alternativen Load Balancer in einer anderen Region um.

(ID:44523131)