4 Min. Lesezeit
Case Study am Beispiel eines international operierenden Logistik-Konzerns mit Standorten rund um den Globus. Im Zusammenspiel von AWS und Atlassians Data Center-Deployment wird ein extremer Performance Boost erreicht. Unserem PoC wurde von den Solution Architekten von Atlassian und AWS bescheinigt, die derzeit beste Lösung zu sein.
Ein weltweit agierendes Logistik-Unternehmen mit über 30.000 Mitarbeitern steht vor der Herausforderung, business-kritische Anwendungen (Jira Software, Confluence usw.) mit geringen Latenzen erreichbar zu machen. Massiver Painpoint: zu schlechte Performance im weltweiten Einsatz. Inklusive der berüchtigten so genannten Jira Kaffee-Pause an Standorten in China und den USA. Die Applikationen werden on-premise im eigenen, deutschen Rechenzentrum betrieben.
Bei dem Projekt war es die Aufgabe, den Beweis anzutreten, dass AWS-Instanzen in Kombination mit dem Atlassian Data Center-Deployment einen massiven Performance-Boost bringen kann. Unsere Proof of Concept-Instanzen fütterten wir mit einem 40 GB-Datenbankdump, um realistische Ergebnisse zu erzielen.
Das Ergebnis: Bis zu 10x bessere Performance, weltweite Hochverfügbarkeit und Zero Downtime. Solution Architekten von AWS und Atlassian waren eng in die Entwicklung eingebunden und bescheinigen dem Setup, dass es die derzeit bestmögliche Lösung ist.
Aktuell ist ein Multi-Region Deployment von AWS mit den Atlassian-Applikationen nicht möglich. Um dennoch den gewünschten Performance-Boost zu erreichen, wird AWS Cloudfront als Cache für den statischen Content genutzt.
Die AWS-Experten der demicon entwarfen in Absprache mit dem Kunden ein erstes Grobkonzept, um alle Anforderungen abzubilden. Als Atlassian Platinum Solution Partner und AWS Consulting Partner wurde der direkte Draht zu AWS und Atlassian genutzt, um Solution Architekten einzubinden. Damit stellten wir sicher, dass unser vorgeschlagenes Setup auch tatsächlich das bestmögliche Ergebnis darstellt.
Der PoC sollte folgende Punkte aufzeigen:
Nach der Aufnahme der Requirements entwickelten die Cloud-Architekten entsprechend der beschriebenen Vorgaben den PoC.
Der erste Vergleich der beiden Systeme (Kundensystem vs. AWS-Deployment) lieferte bereits sehr beeindruckende Zahlen: Die Ladezeiten wurden auf ein Viertel der Zeit verkürzt und das Laden vom Dashboard sogar auf nur noch ein Fünftel der vorherigen Zeit.
Um diese Zahlen zu untermauern und aus einer Laborumgebung eine realitätsnahe Umgebung zu schaffen, wurden im nächsten Schritt die kompletten Datensätze (rund 40 GB) aus dem vorhandenen System hochgeladen, um das System mit der gleichen Last zu testen.
Direkt hinter dem CDN wird ein AWS ELB (Elastic Load Balancer) eingesetzt, der den Traffic annimmt und an die Nodes über ein AWS NAT-Gateway verteilt. Der Load Balancer macht hier auch die Healthchecks und schickt Traffic nur an "gesunde" Nodes. Im Falle eines Ausfalles einer Node wird der Traffic komplett auf den noch vorhandenen Node umgeleitet.
Sobald durch einen Healthcheck bemerkt wurde, dass eine Node ausgefallen ist oder die Last auf einem Node zu hoch wird, erfolgt das Hochfahren durch die Autoscaling Groups und die Launch Configuration einer neuen Node. Diese wird nach erfolgreichem Healthcheck automatisiert in den Load Balancer eingebunden. Bei einem Ausfall einer Node wird diese automatisch aus dem Load Balancer entfernt.
Die Application Nodes sind von außen nicht direkt erreichbar und liegen in einem privaten Subnetz. Man erreicht die Application Node nur über einen sogenannten Bastion Host / Jumpbox. Die Jumpbox befindet sich im öffentlichen Netz und wird durch AWS Security Groups und Network ACL's abgesichert. Hier ist nur der Port 22 für SSH aus dem Netz der Demicon erreichbar. Ausserdem ist der Bastion Host nur per SSH-Key Accessible.
Die eigentlichen Daten befinden sich in einem AWS RDS mit Postgres welches in einem Muti-Availability Zone Deployment läuft. Im Falle eines Ausfalls einer AZ wird automatisch der Traffic zur Backup DB umgeleitet, welche sich in einer anderen Availability Zone (AZ) befindet. Hierdurch ist es möglich, einen Ausfall einer kompletten AZ abzufangen - ohne spürbare Beeinträchtigungen.
Atlassian hat die Nutzung von AWS Aurora auf der Summit 2019 in Las Vegas angekündigt. Sobald eine Freigabe erfolgt ist, könnte hier noch einmal ein weiterer Performance-Boost entstehen. AWS Aurora ist bis zu 10 Mal schneller als eine normale PostgreSQL DB und hat bis zu 15 Read Replicas.
Für Attachments und Plugins (Apps vom Atlassian Marketplace) wird ein Netzwerkspeicher (AWS EFS) eingesetzt. Durch den Einsatz des Netzwerkspeichers sind die eigentlichen Nodes somit ohne relevante Daten und können ausfallen oder zerstört werden ohne einen Datenverlust zu erleiden. Hier ist nun auch kein Nachjustieren der Größe einer Festplatte von Nöten, da AWS EFS mit den Anforderungen des Systems mitwächst. Bei herkömmlichen Festplatten muss eine explizite Größe angegeben werden und sollte es zum "Volllaufen" einer Platte kommen, muss diese vergrößert werden. Mit AWS EFS muss bei der Konzeption nicht auf die Datenmengen geschaut werden.
Allein durch ein flexible AWS-Setup in Kombination mit dem Data Center-Deployment von Atlassian können Hosting-Kosten eingespart werden. Zwar können für die Applikationen je nach Bedarf und steigender Last zusätzliche Nodes automatisch hinzugefügt werden, doch zugleich funktioniert dies auch in die andere Richtung. Mit Scaling-Out kommen nur die Ressourcen zum Einsatz, welche tatsächlich benötigt werden.
Wir empfehlen, dass immer mindestens zwei aktive Nodes vorhanden sind und diese auf verschiedene AWS Availability Zones verteilt werden. Dies gewährleistet eine hohe Ausfallsicherheit, da der Load Balancer bei Ausfall einer Availability Zone den Traffic direkt auf einen andere aktive Node umleitet. Parallel hierzu würde eine neue Node hochgefahren werden, welches in etwa 2-5 Minuten dauert, und dem Load Balancer mitgeteilt werden sodass die Lastenverteilung dann wieder auf mehrere Nodes stattfindet. Unsere Erfahrung hat allerdings gezeigt, dass der Ausfall von mehr als einer Zone noch nie vorgekommen ist und somit auch der Ausfall von nur maximal einem Node in der Praxis möglich ist.
Keine Zeit für RTO und RPO - Just in time Recovery
Weiter ist ein Restore der Daten bis auf das letzte ausgeführte Kommando möglich. Keine RTO- und RPO- Zeiten.
Just in time Recovery.
Ein Proof of Concept liefert Ihnen nicht nur theoretische Annahmen, sondern konkrete Resultate. Nach dem ersten Grobkonzept erstellen unsere Cloud Architekten eine für Sie passende Infrastruktur. Die bereitgestellte Installation wird als leere Instanz zur Verfügung gestellt, in der dann getestet und Testdaten eingegeben werden können. Sollten Sie gerne einen Teil oder alle Ihre Daten testweise auf die PoC-Umgebung migrieren wollen so ist dies auch möglich.
Lassen Sie sich vom Proof of Concept überzeugen – die Vorteile liegen auf der Hand:
DEMICON : Dec 4, 2019 12:00:00 AM
Cutting Edge Test Management for Jira - So läuft Ihr Jira mit Xray reibungslos - unabhängig davon, ob Sie 1.000 oder 1.000.000 Testfälle haben. Im...
DEMICON : Oct 14, 2019 12:00:00 AM
In unserem neuen Blogbeitrag geht es um das Thema Testmanagement und QA für Jira. Der Autor des englischen Originaltextes ist Xpand IT-Produktmanager
DEMICON : Jan 10, 2018 12:00:00 AM
Im PMO, Marketing & Sales oder anderen Abteilungen – Die Basis für das Controlling der gesamten Projekt-Prozesskette übernimmt bei der demicon eine...
