Teil 1: Warum wechseln?

Migration nach AWS: Wir bringen eine Java-Anwendung in die Cloud

Sascha Möllering, Dennis Kieselhorst

©Shutterstock / phloxii

In einer Serie von mehreren Artikeln werden wir die Migration einer „klassischen“ Java-Webanwendung in die AWS-Cloud beleuchten. Dieser erste Artikel behandelt zunächst mögliche Gründe für einen Wechsel, die aktuelle Architektur und eine Migration nach dem „Lift and Shift“-Ansatz. Alle weiteren Artikel optimieren die Anwendung iterativ durch den Einsatz verwalteter Dienste.

Gewichtige Argumente für die Verlagerung in die Cloud sind die Agilität und Geschwindigkeit, mit der sich Unternehmen bewegen können. Mit Cloud-Computing kann eine Vielzahl von Anwendungen nebst Servern innerhalb weniger Minuten (anstatt wie bei lokalen Rechenzentren innerhalb mehrerer Wochen) eingerichtet werden. Services in der Cloud – von Rechenleistung über Speicher und Datenbanken bis hin zu Continuous Integration, Datenanalysen, künstlicher Intelligenz und vielen mehr – sind jederzeit und sofort verfügbar. Die Zeitspanne von der Idee bis zur Implementierung wird so um ein Vielfaches verkürzt.

Artikelserie

Teil 1: Warum wechseln?

Teil 2: Verwendung von Managed Services

Teil 3: Entkopplung mit Containern

Teil 4: Serverless mit AWS Lambda

Teil 5: Optimierung der Architektur

Teil 6: Sicherheit und Verschlüsselung

Der Entwicklungsprozess mit Ressourcen im eigenen Rechenzentrum greift häufig nur auf jeweils eine Umgebung für Integration, Abnahme, Vorproduktion und Produktion zu. Die Umgebungen werden dabei dauerhaft betrieben. In der Cloud ist es möglich, nach Bedarf und Notwendigkeit neue Umgebungen aufzusetzen und sie nach der Nutzung auch wieder zu entfernen. Während die durchschnittliche Auslastung eigener Rechenzentren relativ gering ist [1], ist es möglich, Parameter wie Speicherkapazität oder Prozessorleistung bei Cloudressourcen so zu variieren, dass deutlich höhere Auslastungen erreicht und dadurch Kosten gespart werden. Typischerweise sind Umgebungen in Form von Infrastructure as Code als AWS-CloudFormation- oder HashiCorp-Terraform-Templates definiert. Diese Templates können und sollten wie Quellcode für Anwendungen behandelt werden, was bedeutet, dass sie dem gleichen Entwicklungs- und Releaseprozess unterliegen und entsprechend getestet werden. Durch dieses Vorgehen – Infrastructure as Code und DevOps in Kombination mit der Cloud – wird die Agilität erhöht und die Einführungszeit für neue Produkte reduziert.


Es gibt auch viele Unternehmen, die im Zuge von Rechenzentrumskonsolidierungs- oder Rationalisierungsprojekten in die Cloud migrieren. Vorteilhaft für geringere Gesamtbetriebskosten (Total Cost of Ownership, TCO) ist das Pay-as-you-go-Modell. Anstatt vorab Kapital in Infrastrukturkomponenten zu investieren, kann die erforderliche Kapazität flexibel angefordert werden. Durch die Möglichkeit, Angebot und Nachfrage aufeinander abzustimmen, ergibt sich eine elastische, transparente Kostenbasis. Sollten sich beispielsweise die Erwartungen an ein Produkt nicht erfüllen, können die dafür bereitgestellten Ressourcen jederzeit abgezogen werden und es fallen ab diesem Zeitpunkt keine Betriebskosten mehr an. Ein weiteres Beispiel sind Entwicklungs- und Testumgebungen, die außerhalb der Arbeitszeit abgeschaltet werden können.

Warum eine Migration nach AWS?

Genau wie im eigenen Rechenzentrum ist es bei AWS möglich, ein individuelles Netzwerkdesign zu definieren: Eigene logisch isolierte Abschnitte können bereitgestellt werden. Mit den entsprechenden Rechten haben Administratoren die volle Kontrolle über die virtuelle Netzwerkumgebung, um einen sicheren und einfachen Zugriff auf Ressourcen und Anwendungen zu ermöglichen. AWS Shield ist ein verwalteter Distributed-Denial-of-Service-(DDoS-)Schutzdienst für Anwendungen, die auf der AWS-Plattform laufen. Dieser Service bietet eine permanente Überwachung und trifft automatisch Gegenmaßnahmen, um Ausfallzeiten und Latenzzeiten von Anwendungen zu minimieren. Alle AWS-Kunden profitieren automatisch von den AWS-Shield-Standard-Schutzfunktionen – ohne Aufpreis. AWS Shield Standard schützt vor den am häufigsten auftretenden DDoS-Angriffen auf Netzwerk- und Transportschicht. Wenn AWS Shield Standard in Kombination mit Amazon CloudFront und Amazon Route 53 verwendet wird, bietet das umfassenden Verfügbarkeitsschutz gegen alle bekannten Infrastrukturangriffe auf die Layer drei und vier. Die Konfiguration der einzelnen Services findet ausschließlich über APIs statt. Mit AWS CloudTrail können diese API-Kontoaktivitäten protokolliert, kontinuierlich überwacht und aufbewahrt werden. AWS CloudTrail bietet einen Ereignisverlauf der Kontoaktivitäten, einschließlich Aktionen, die über die AWS Management Console, AWS SDKs, Kommandozeilentools und andere AWS-Dienste auseführt werden.

Diese Ereignishistorie vereinfacht die Sicherheitsanalyse, die Verfolgung von Ressourcenänderungen und die Fehlerbehebung. Um auf bestimmte Ereignisse in der Historie automatisiert reagieren zu können, kann AWS CloudTrail mit Amazon CloudWatch Logs kombiniert werden, um bei bestimmten Aktivitäten CloudWatch-Alarme für Ereignisse zu versenden. Bei entsprechender Konfiguration wird beliebiger Programmcode aufgrund dieser Alarme ausgeführt.

Ein wichtiger Aspekt der Ausfallsicherheit: Mit derzeit 22 Regionen, die 69 Availability Zones (AZ) umfassen, besitzt AWS globale Präsenz, um die Verfügbarkeit zu verbessern und die Latenz zu reduzieren. Jede AZ kann mehrere Rechenzentren und bei maximaler Kapazität hunderttausende von Servern umfassen. Es handelt sich dabei um vollständig isolierte Bereiche der globalen AWS-Infrastruktur. Mit ihrer eigenen Strominfrastruktur sind die AZs physisch viele Kilometer von den anderen AZ entfernt, obwohl alle innerhalb einer Distanz von 100 Kilometern liegen. Hinzu kommen 189 Points of Presence, die rund um den Globus in unmittelbarer Nähe zum Anwender für schnelle Antwortzeiten sorgen. Kunden haben immer die volle Kontrolle darüber, wo ihre Daten gespeichert werden. Eine Übersicht ist unter [2] zu finden.

Es existieren noch viele weitere Gründe, warum Unternehmen eine Migration in die Cloud durchführen. Einige möchten so die Produktivität ihrer Mitarbeiter steigern. Üblicherweise wird Produktivität durch zwei wichtige Faktoren angetrieben: zum einen durch den Umstand, nicht auf Infrastruktur warten zu müssen, zum anderen durch den Zugriff auf die Vielfalt und die Bandbreite der mehr als 165 Services von AWS, die andernfalls selbst entwickelt, gewartet und betrieben werden müssten. Tatsächlich lassen sich nach einer Migration häufig Steigerungen der Mitarbeiterproduktivität von 30 bis 50 Prozent [3] beobachten. Services von AWS helfen Entwicklern dabei, sich stärker auf ihre Kernaufgabe fokussieren zu können: die Entwicklung von innovativen neuen Anwendungen und Services.

Des Weiteren werden Kosten für die Aktualisierung von Hardware vermieden. Ist der Lebenszyklus bestimmter Komponenten am Ende angelangt, entstehen beim notwendigen Aktualisierungszyklus häufig hohe Aufwände, da neben der Hardware oft auch Software individuell angepasst und aktualisiert werden muss.

Infrastruktur und Anwendung

In unserem Beispiel (Abb. 1) werden wir eine Three-Tier-Java-Anwendung betrachten, die in dieser oder ähnlicher Form in vielen Rechenzentren zu finden ist. Basis dieser Architektur auf Ebene der Infrastruktur ist eine Virtualisierungslösung, die beispielsweise auf Basis von VMware [4] (Kasten: „VMware Cloud on AWS“), Xen [5], KVM [6] oder ähnlich läuft.

VMWare Cloud on AWS

In vielen Unternehmen wird bereits virtualisierte Serverinfrastruktur auf Basis von VMware genutzt. Wenn keine Änderung an den bestehenden Betriebsmodellen vorgenommen werden soll, kann es sinnvoll sein, einen Migrationspfad ausgehend vom bestehenden Set-up im On-Premises-Rechenzentrum nach AWS mit Hilfe der bestehenden Virtualisierungstechnolgie durchzuführen. Dafür bietet sich VMware Cloud on AWS an, denn es bietet Kunden eine dedizierte Cloudinfrastruktur mit Unterstützung für vSphere-Cluster mit bis zu 16 Hosts. Die Basis dafür ist die AWS-Bare-Metal-Infrastruktur, die auf den aktuellsten speicheroptimierten Amazon-EC2-High-I/O-Instanzen mit NVMe-SSDs aufsetzt. Bestehende Workloads können zwischen der bereits vorhandenen VMware-Umgebung und VMware Cloud on AWS mittels Cold-Migration, VM-Template-Migration und Live-Migration über vMotion unterbrechungsfrei während der Workload-Ausführung verschieben.

Die Anwendung selbst wird auf verschiedenen virtuellen Servern auf Basis der Apache Tomcat Servlet Engine [7] ausgerollt. Um die Last gleichmäßig zu verteilen, wird ein Load Balancer wie F5 [8], Apache HTTP Server [9] oder NGINX [10] eingesetzt. Um die Anwendung vor unerwünschten Netzwerkzugriffen zu schützen, wird eine Firewall eingesetzt. Die Anwendung speichert ihre Daten in einem MySQL Galera Cluster [11]. Ein Redis Cluster [12] dient als Zwischenspeicher für häufig angefragte Daten, um die Datenbank zu entlasten.

Abb. 1: Infrastruktur im eigenen Rechenzentrum

Abb. 1: Infrastruktur im eigenen Rechenzentrum

Lift and Shift

Wenn eine Organisation ihr Migrationsvorhaben schnell implementieren und skalieren möchte, ermöglicht der Lift and Shift oder auch Rehosting genannte Ansatz, viele Anwendungen in großen Migrationsszenarien zu migrieren. Die meisten Rehosting-Vorgänge können durch Tools wie AWS Server Migration Service [13] oder CloudEndure [14] automatisiert werden, häufig wird der Vorgang aber dennoch manuell durchgeführt, um zu lernen, wie das bestehende System in der Cloud aufgesetzt wird.

Die dabei gewonnenen Erkenntnisse und Fähigkeiten können dazu genutzt werden, um Anwendungen für die Cloud umzugestalten. Wenn einmal in die Cloud migriert wurde und die Anwendungen dort ausgeführt werden, können Optimierungen – agil und in iterativen Schritten – einfacher durchgeführt werden.

Abb. 2: Infrastruktur in AWS

Abb. 2: Infrastruktur in AWS

Eine oft gestellte Frage beim Start einer Migration ist: Wie kann ich Ressourcen, die in meinem Rechenzentrum laufen, in AWS abbilden?

Üblicherweise beginnt eine Migration mit der Netzwerkkonfiguration in einer Amazon Virtual Private Cloud (VPC). Kunden haben die volle Kontrolle über die virtuelle Netzwerkumgebung, einschließlich der Auswahl eines eigenen IP-Adressbereichs, der Erstellung von Subnetzen und der Konfiguration von Routingtabellen und Netzwerkgateways. Es können beispielsweise ein öffentlich zugängliches Subnetz für einen Webserver mit Internetzugang, und für Backend-Systeme wie Datenbanken oder Anwendungsserver ein privates Subnetz ohne Internetzugang erstellt werden. Kunden können mehrere Sicherheitsebenen nutzen (Kasten: „Sicherheit in AWS“), einschließlich Sicherheitsgruppen (Security Groups) und Netzwerkzugriffskontrolllisten (NACLs), um den Zugriff auf Amazon EC2-Instanzen in jedem Subnetz zu kontrollieren.

Eine wesentliche Eigenschaft – speziell bei Anwendungen, die nicht für die Cloud entwickelt worden sind – ist der Zustand einer Anwendung. Wenn wir uns zum Beispiel eine Java-Enterprise-Anwendung anschauen, die in einem JBoss-Server läuft, dann repliziert JGroups den Zustand bzw. die Sessions über UDP mit Hilfe von Buddy Replication an die benachbarten Knoten. Eine Möglichkeit, eine solche Anwendung in die Cloud zu migrieren, besteht darin, die Session-Informationen über JGroups mit einem Amazon S3-Bucket als Ziel über TCP zu replizieren. Wenn die Infrastruktur aber eine gewisse Größe erreicht hat, wird der Kommunikationsaufwand zu hoch und begrenzt die Performance. Eine deutlich bessere Lösung besteht darin, die Anwendung zustandslos zu implementieren und den Zustand in einem externen Service wie einem Redis Cluster abzulegen.

Sicherheit in AWS

AWS bietet in Bezug auf die Sicherheit diverse Möglichkeiten und Dienste, um den Datenschutz zu erhöhen und den Netzwerkzugriff zu kontrollieren. Dazu zählen:

  • Netzwerkfirewalls, die in Amazon VPC integriert sind, und Firewallfunktionen für Webanwendungen durch die AWS Web Application Firewall, mit denen private Netzwerke erstellt und der Zugriff auf Ihre Instances und Anwendungen kontrolliert werden kann

  • Verschlüsselung der Daten zwischen allen Services (in Transit)

  • Verbindungsoptionen für VPNs und dedizierte Leitungen zum eigenen Datacenter

  • automatische Verschlüsselung des gesamten Datenverkehrs in den globalen und regionalen AWS-Netzwerken zwischen von AWS abgesicherten Standorten

Darüber hinaus bietet die AWS-Cloud Funktionen zur Definition, Durchsetzung und Verwaltung von Benutzerzugriffsrichtlinien für alle AWS-Dienste. Dazu gehören:

  • AWS Identity and Access Management (IAM) zum Definieren individueller Benutzerkonten mit Berechtigungen für AWS-Ressourcen

  • AWS-Multi-Faktor-Authentifizierung für privilegierte Nutzer, einschließlich Optionen für hardwarebasierte Authentifikatoren

Zusätzlich existiert die Möglichkeit, in der Cloud gespeicherte Daten effizient zu verschlüsseln. Die technischen Details zur Verschlüsselung in AWS werden in einem späteren Artikel näher beleuchtet. Hier ein paar Beispiele:

  • Datenverschlüsselungsfunktionen, die in AWS-Speicher- und -Datenbankdiensten verfügbar sind.

  • Flexible Schlüsselverwaltungsoptionen, einschließlich des AWS Key Management Service; abhängig vom Bedarf nach eigener Kontrolle (und Verantwortung) kann aus mehreren Möglichkeiten zur Schlüsselverwaltung gewählt werden

Für Anfragen der Browser und deren Verteilung auf die Apache HTTP Server nutzen wir den Application Load Balancer [15]. Dieser nimmt HTTP- und HTTPS-Anfragen an, terminiert TLS und reicht die Anfragen dann weiter. Der AWS Certificate Manager [16] stellt öffentliche TLS-Zertifikate für den Application Load Balancer kostenlos zur Verfügung.

In unserem Beispiel (Abb. 2) werden anstelle der bisherigen virtualisierten Maschinen nun Amazon-EC2-Instanzen eingesetzt. Amazon EC2 [17] ist eine virtuelle Compute-Umgebung. Mit APIs können Instanzen mit einer Vielzahl von Betriebssystemen gestartet, verwaltet und gestoppt werden. Amazon EC2 bietet eine große Auswahl von Instanztypen, die für unterschiedliche Anwendungsfälle optimiert sind. Instanztypen unterstützen verschiedene Kombinationen von CPU, Arbeitsspeicher, Speicher und Netzwerkkapazität. Instanztypen gibt es meist in mehreren Größen. Auf den EC2-Instanzen können beliebige Anwendungen ausgerollt werden. Netzwerkzugriffsberechtigungen müssen explizit freigeschaltet werden. Bei der Nutzung von Amazon EC2 fallen nur für die tatsächlich verbrauchten Ressourcen Kosten an, wie z. B. Instanzstunden oder Datentransfervolumen.

Am Beispiel von Amazon-EC2-Instanzen schauen wir uns exemplarisch an, wie schnell und unkompliziert Ressourcen verwendet werden können:

  1. Wir wählen ein vorkonfiguriertes Amazon Machine Image (AMI) aus, um sofort mit der Arbeit beginnen zu können. Alternativ kann ein eigenes AMI erstellt werden, in dem das Betriebssystem, Bibliotheken, Anwendungen und unter Umständen Daten enthalten sind.

  2. Wir konfigurieren Sicherheitsgruppen und den Netzwerkzugriff auf der Amazon-EC2-Instanz.

  3. Wir wählen einen passenden Instanztyp.

  4. Wir legen fest, ob EC2-Instanzen in mehreren Availability Zones ausgeführt werden sollen, statische IPs verwendet werden oder persistenter Blockspeicher benötigt wird.

Für die Verwaltung der MySQL-Datenbank für Daten der Anwendung nutzen wir den Amazon Relational Database Service (RDS) [18]. Dieser Service macht es einfach, eine relationale Datenbank in der Cloud einzurichten, zu betreiben und zu skalieren. Er stellt kosteneffiziente und skalierbare Kapazität zur Verfügung. Zeitaufwendige Administrationsaufgaben wie Hardwarebereitstellung, Datenbank-Set-up, Patching und Back-ups werden automatisiert durchgeführt. Dadurch bietet RDS die Möglichkeit, sich auf die Anwendungen zu konzentrieren. Amazon RDS ist für verschiedene Datenbankinstanztypen verfügbar – jeweils optimiert für Workloads, die mehr Arbeitsspeicher, Prozessorleistung oder I/O-Durchsatz benötigen. RDS unterstützt Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database und Microsoft SQL Server. Für die Datenmigration verwenden wir den AWS Database Migration Service (DMS) [19], der auch für die Replikation zwischen Datenbanken verwendet werden kann.

Redis provisionieren wir mit Hilfe von Amazon ElastiCache [20]. Verwaltungsaufgaben wie Hardwarebereitstellung, Software-Patching, Einrichtung, Konfiguration, Überwachung, Fehlerbehebung und Back-ups werden mit Amazon ElastiCache automatisiert durchgeführt. Amazon ElastiCache for Redis basiert auf Open-Source-Redis und ist mit den Redis APIs kompatibel. Der Service verwendet das offene Redis-Datenformat zur Speicherung von Daten. Selbst geschriebene Redis-Anwendungen können ohne Codeänderungen nahtlos mit Amazon ElastiCache for Redis zusammenarbeiten.

Hilfsmittel bei der Migration

Im vorigen Abschnitt haben wir die einzelnen Services näher betrachtet, die bei der Migration als Ziel dienen, doch wie wird die eigentliche Migration durchgeführt und welche Hilfsmittel existieren?

AWS Migration Hub [21] bietet einen zentralen Ort, um den Fortschritt der Migration von Anwendungen mit verschiedenen AWS- und Partnerlösungen zu verfolgen. Migration Hub gibt darüber hinaus – ungeachtet der verwendeten Migrationstools – Auskunft über wichtige Kennzahlen und den Fortschritt einzelner Anwendungen.

Eins der integrierten Tools ist der AWS Application Discovery Service [22]. Rechenzentrumsmigrationen können tausende Workloads umfassen, die oft stark voneinander abhängig sind. Serverauslastungsdaten und die Abbildung dieser Abhängigkeiten sind daher wichtige erste Schritte im Migrationsprozess. Der AWS Application Discovery Service sammelt Daten zur Konfiguration, Nutzung und zum Verhalten der Server und stellt sie dar, um Workloads besser verstehen zu können.

Eine Alternative zum Application Discovery Service ist TSO Logic [23]. Hier werden präzise datenbasierte Empfehlungen zur richtigen Bemessung und Kostenkalkulation der Umgebungen bereitgestellt. Abbildung 3 zeigt ein Beispielszenario, bei dem die aktuellen Infrastrukturkosten (pink gefärbt) sowohl in gleicher Dimensionierung (orange gefärbt) als auch „Right Sized“ (gelb gefärbt) auf Grundlage der ermittelten Datenbasis gegenübergestellt werden. TSO Logic hilft somit, die Migrationsplanung durch einen Business Case schneller voranzubringen und berücksichtigt im Vergleich zum AWS Application Discovery Service auch Lizenzthemen (wie z. B. Bring Your Own License, BYOL).

Abb. 3: Cost Modeler UI von TSO Logic

Abb. 3: Cost Modeler UI von TSO Logic

Fazit

Im ersten Teil unserer Artikelserie haben wir näher betrachtet, wie eine typische Lift-and-Shift-Migration aus dem eigenen Rechenzentrum nach AWS aussieht und welche Tools und Services dabei unterstützen. Hierbei steht im Vordergrund, die Flexibilität im IT-Betriebsbereich zu erhöhen und den Zugriff auf Infrastrukturressourcen zu beschleunigen und zu vereinfachen.

Für viele Anwendungen ist Lift and Shift der erste Schritt, auf den weitere Optimierungen hinsichtlich Sicherheit, Verfügbarkeit, Leistung, Betreibbarkeit und Kosten folgen. Im nächsten Artikel werden wir uns weiteren Services widmen, die das Aufsetzen und den Betrieb der Infrastruktur vereinfachen.

 

Geschrieben von
Sascha Möllering
Sascha Möllering
Sascha Möllering arbeitet als Solutions Architect bei der Amazon Web Services Germany GmbH. Seine Interessen liegen in den Bereichen Automation, Infrastructure as Code, Distributed Computing, Container und JVM.
Dennis Kieselhorst
Dennis Kieselhorst
Dennis Kieselhorst ist Solutions Architect bei der Amazon Web Services EMEA SARL. Er hat fünfzehn Jahre Erfahrung mit Java und verteilten, heterogenen Systemlandschaften. Dennis unterstützt verschiedene Open-Source-Projekte und ist Committer/PMC-Mitglied bei der Apache Software Foundation.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: