Cloud-Architektur Best Practices Januar 2010 Zuletzt aktualisiert im Januar 2011

Transkript

1 Cloud-Architektur Best Practices Januar 2010 Zuletzt aktualisiert im Januar 2011 Jinesh Varia Seite 1 von 26

2 Einführung Über viele Jahre hinweg haben Softwarearchitekten verschiedene Konzepte und Best Practices für den Aufbau hoch skalierbarer Anwendungen getestet und implementiert. In der heutigen "Tera-Ära" sind diese Konzepte aufgrund ständig wachsender Datenbanken, unvorhersehbarer Datenverkehrsmuster und dem Bedarf an kürzeren Antwortzeiten sogar aktueller denn je. In diesem Dokument werden einige dieser traditionellen Konzepte neu betrachtet und ihre mögliche Entwicklung im Kontext von Cloud Computing erörtert. Außerdem werden einige nie dagewesene Begriffe beleuchtet, wie etwa die Elastizität, die aufgrund der Dynamik des Cloud Computing aufgekommen sind. Dieses Dokument richtet sich an Cloud-Architekten, die sich darauf vorbereiten, eine Unternehmensanwendung von einer festen, physischen Umgebung in eine virtualisierte Cloud-Umgebung umzuwandeln. Der Schwerpunkt dieses Dokuments liegt in der Erläuterung von Begriffen, Prinzipien und Best Practices bei der Erstellung neuer Cloud-Anwendungen oder der Migration existierender Anwendungen in die Cloud. Hintergrund Als Cloud-Architekt sollte man sich der Vorteile von Cloud Computing bewusst sein. In diesem Abschnitt stellen wir einige der Geschäftsvorteile und einige technische Vorteile von Cloud Computing sowie verschiedene AWS-Dienste vor, die heutzutage zur Verfügung stehen. Geschäftsvorteile von Cloud Computing Die cloudbasierte Nutzung von Anwendungen bietet einige deutliche Geschäftsvorteile. Nachfolgend sind einige dieser Vorteile aufgeführt: Nahezu keine Investitionen in die Infrastruktur: Der Aufbau eines umfangreichen Systems erfordert einen hohen Kostenaufwand für Investitionen in Räumlichkeiten, physische Sicherheit, Hardware (Schränke, Server, Router, Notstromversorgung), Hardware-Management (Stromversorgung, Kühlung) sowie Bedienpersonal. Aufgrund der hohen Vorfinanzierungskosten müsste ein derartiges Projekt in der Regel mehrere Bewilligungsprozesse auf Managementebene durchlaufen, bevor es erst gestartet werden könnte. Bei der Nutzung von bedarfsorientiertem Cloud Computing entstehen keinerlei Fix- und Einführungskosten. Just-in-Time-Infrastruktur: In der Vergangenheit war es häufig so, dass Systeme bei einem stetigen Wachstum einer Anwendung dessen Anforderungen mit der Zeit nicht mehr gerecht wurden. Umgekehrt hatten hohe Anfangsinvestitionen bei ausbleibendem Erfolg oft verheerende Folgen. Durch die cloudbasierte Nutzung der Anwendungen mit dem Modell des Just-in-Time Self-Provisioning bedürfen umfangreiche Systeme keiner vorzeitigen Kapazitäteneinplanung. Das erhöht die Flexibilität, reduziert das Risiko und senkt die Betriebskosten, da Sie Ihre Kapazitäten nur bei Wachstum erhöhen müssen, und somit nur für die tatsächlich genutzten Kapazitäten zahlen müssen. Effizientere Ressourcen-Nutzung: Albträume bereiten Systemadministratoren mögliche Probleme bei der Bereitstellung von Hardware (bei Kapazitätsmangel) und der Auslastung der Infrastruktur (bei Überdeckung und ungenutzten Kapazitäten). Eine cloudbasierte Bereitstellung ermöglicht eine effizientere und effektivere Verwaltung von Ressourcen, da die Ressourcen für die Anwendungen je nach Bedarf aufgestockt oder reduziert werden können. Nutzungsbasierter Kostenaufwand: Bei nutzungsbasierter Zahlung entstehen lediglich für die tatsächlich verwendete Infrastruktur Kosten. Sie zahlen also nicht für bereitgestellte aber nicht genutzte Infrastruktur. Hierdurch eröffnen sich ungeahnte Möglichkeiten zur Kosteneinsparung. Deutliche Kosteneinsparungen werden bereits bei einer Aktualisierung Ihrer Cloud-Anwendung sichtbar (manchmal sogar bereits bei der nächsten Monatsabrechnung). Falls ein Caching-Layer beispielsweise Ihre Datenanforderungen um 70 % reduzieren kann, profitieren Sie unmittelbar von diesen Einsparungen. Seite 2 von 26

3 Die Kostensenkung wird also bereits auf der nächsten Rechnung sichtbar. Wenn Sie Plattformen auf Basis der Cloud implementieren, können Sie die gleiche flexible, variable nutzungsbasierte Kostenstruktur zudem Ihren Kunden bereitstellen. Verkürzung der Produkteinführungszeit: Parallelisierung ist eine effiziente Möglichkeit zur Prozessbeschleunigung. Während die Verarbeitung eines berechnungs- oder datenintensiven Auftrags, der parallel ausgeführt werden kann, auf einem Gerät 500 Stunden in Anspruch nimmt, ist bei cloudbasierter Architektur [6] eine Aufsplittung in 500 Instanzen und die Verarbeitung des Auftrags in 1 Stunde möglich. Die Verfügbarkeit einer flexiblen Infrastruktur bietet der Anwendung die Möglichkeit der kostengünstigen Parallelisierung und somit der Verkürzung der Markteinführungszeit. Technische Vorteile von Cloud Computing Der Einsatz cloudbasierter Lösungen bietet folgende technische Vorteile: Automation "Skriptfähige Infrastruktur": Sie haben die Möglichkeit, sich wiederholende Aufbau- und Anwendungssysteme zu erstellen, indem Sie eine programmierbare (API-gesteuerte) Infrastruktur nutzen. Automatische Skalierung: Sie können Ihre Anwendungen hochskalieren oder herunterskalieren, und so Ihrem aktuellen Bedarf anpassen, ohne das hierfür Bedienpersonal erforderlich ist. Die automatische Skalierung fördert Automation und Effizienz. Proaktive Skalierung: Skalieren Sie Ihre Anwendung hoch oder herunter, um Ihren antizipierten Bedarf mit angemessener Planung Ihrer Datenverkehrsmuster zu erfüllen, so dass Sie die Kosten während der Skalierung möglichst gering halten. Erhöhung der Effizienz des Entwicklungszyklus: Produktionssysteme können problemlos für den Einsatz als Entwicklungsoder Testsystem geklont werden. Staging-Umgebungen können einfach für die Produktion gefördert werden. Verbesserte Testbarkeit: Keine Hardware-Engpässe bei Testläufen. Führen Sie Testläufe in jeder Phase des Entwicklungsprozesses durch. Sie können eine Testeinrichtung mit voreingestellten Umgebungen eigens für die Dauer der Testphase erstellen. Disaster Recovery und Geschäftskontinuität: Die Cloud bietet die kostengünstigere Alternative für die Wartung von mehreren DR-Servern und Datenspeichern. Mit Cloud Computing können Sie die Vorteile der Geo-Distribution nutzen, und die Umgebung innerhalb von Minuten an einem anderen Ort nachbilden. Leiten Sie den Datenverkehr zur Cloud: Mit wenigen Klicken und effektiven Lastausgleichmaßnahmen können Sie eine komplett überlaufsichere Anwendung erstellen, indem zusätzlicher Datenverkehr zur Cloud geleitet wird. Funktionsweise der Amazon Web Services-Cloud Die Amazon Web Services (AWS)-Cloud bietet eine hochgradig zuverlässige und skalierbare Infrastruktur für die Bereitstellung webbasierter Lösungen zu minimalen Support- und Administrationskosten und deutlich mehr Flexibilität, als Sie es von Ihrer eigenen Infrastruktur gewohnt sind egal ob sie eine Fernzugriffslösung oder eine Infrastruktur am eigenen Standort nutzen. AWS bietet heute eine Vielzahl attraktiver Infrastrukturdienste. Das nachfolgende Diagramm führt Sie in die AWS- Terminologie ein veranschaulicht, wie Ihre Anwendung mit verschiedenen Amazon Web Services interagieren und wie verschiedene Dienste untereinander interagieren können. Seite 3 von 26

4 Zahlung: Amazon FPS/ DevPay Amazon SimpleDB-Domains Amazon SNS-Themen Amazon SQS-Warteschlangen Amazon Web Services - Cloud-Architektur Best Practices Januar 2010 Der Web-Service Amazon Elastic Compute Cloud (Amazon EC2 1 ) ermöglicht die Anpassung der Rechenkapazität in der Cloud. Sie haben die Möglichkeit, das Betriebssystem, die Anwendungssoftware sowie die entsprechenden Konfigurationseinstellungen in einem Amazon Machine Image (AMI) zu bündeln. Mithilfe dieser AMIs können Sie eine Vielzahl virtualisierter Instanzen bereitstellen oder diese über einfache Web-Service-Anrufe außer Betrieb setzen, um die Kapazität je nach Bedarf schnell hoch oder herunter zu skalieren. Sie können On-Demand Instances, die Sie je genutzter Stunde zahlen, oder Reserved Instances kaufen. Hier zahlen Sie eine geringe Einmalzahlung und erhalten eine geringere Nutzungsrate für die Ausführung der Instanz, als wenn Sie eine On-Demand Instance oder Spot Instances kaufen, wo Sie ungenutzte Kapazitäten anfordern, und somit Ihre Kosten weiter reduzieren können. Instanzen können in einer oder mehreren geografischen Regionen gestartet werden. Jede Region verfügt über mehrere Availability Zones. Availability Zones sind eigenständige Standorte, die so entwickelt wurden, dass sie von Fehlern in anderen Availability Zones isoliert sind. Sie bieten eine kostengünstige Netzwerkverbindung mit geringer Verzögerungszeit zu anderen Availability Zones in derselben Region. Ihre Anwendung Auto Scaling Amazon RDS Elastic Load Balance r Amazon-EC2-Instances (On-Demand, Reserved, Spot) Amazon Elastic MapReduce JobFlows Cloud Watch Amazon S3- Objekte und - Buckets Amazon Cloud Front Amazon Virtual Private Cloud EBS Datenträ ger Snapshots Globale physische Infrastruktur von Amazon (Geografische Regionen, Availability Zones, Edge-Standorte) Abbildung 1: Amazon Web Services Elastische IP-Adressen ermöglichen Ihnen die Zuweisung einer statischen IP-Adresse sowie dessen programmatische Zuweisung zu einer Instanz. Mithilfe von Amazon CloudWatch können Sie eine Überwachungsfunktion in Amazon EC2 aktivieren. 2 So erhalten Sie Einsicht in die Ressourcenauslastung, betriebliche Leistung sowie allgemeine Anforderungsmuster. Dazu zählen auch Kennzahlen wie die CPU-Auslastung, Lese- und Schreibvorgänge auf Speichermedien und der Netzwerk-Traffic. Über die Funktion zur Automatischen Skalierung können Sie eine Autoskalierungsgruppe erstellen 3, um Ihre Kapazitäten bei bestimmten Bedingungen, basierend auf einer von Amazon CloudWatch erstellten Metrik, zu skalieren. Eingangsverkehr können Sie auch durch die Erstellung eines Elastic Load 1 Weitere Informationen zu Amazon EC2 erhalten Sie unter 2 Weitere Informationen zu Amazon CloudWatch finden Sie unter 3 Weitere Informationen zu Autoskalierungsfunktion finden Sie unter Seite 4 von 26

5 Balancer über den Elastic Load Balancing 4 -Dienst verteilen. Amazon Elastic Block Storage (EBS) 5 -Volumina bieten Amazon EC2-Instanzen beständige zentralisierte Speichermöglichkeiten. Zeitpunktkonsistente Schnappschüsse von EBS-Speichervolumina können über den Amazon Simple Storage Service (Amazon S3) erstellt werden 6. Amazon S3 bietet zuverlässige und verteilte Datenspeicherung. Über eine einfache Schnittstelle für Webservices können Sie zu jeder Zeit und überall im Web beliebige Datenmengen über Standard HTTP-Verben als Objekte in Buckets (Containern) speichern und abrufen. Kopien von Objekten können verteilt und an 14 Edge Locations auf der ganzen Welt zwischengespeichert werden, indem über den Amazon CloudFront-Service eineverteilung 7 erstellt wird ein Web- Service für die Bereitstellung von Inhalten (statische Inhalte oder Streaming-Inhalte). Amazon SimpleDB 8 bietet die wichtigsten Funktionen einer Datenbank Echtzeit-Suche und eine einfache Abfrage strukturierter Daten ohne die sonst übliche Komplexität im Betrieb. Sie können den Datensatz in Domänen organisieren und Abfragen zu allen in einer bestimmten Domäne gespeicherten Daten vornehmen. Bei Domänen handelt es sich um Sammlungen von Elementen, die durch Attributwertpaare beschrieben werden. Amazon Relational Database Service 9 (Amazon RDS) ist eine Web- Dienstleistung zum einfachen Einrichten, Betreiben und Skalieren einer relationalen Datenbank in der Cloud. Sie können eine DB-Instanz starten und auf eine voll-funktionsfähige MySQL-Datenbank zugreifen, und sich keine Gedanken über typische Datenbankadministrationsaufgaben, wie beispielsweise Datensicherung, Patch Management etc. machen. Amazon Simple Queue Service (Amazon SQS 10 ) bietet eine zuverlässige, hochskalierbare, gehostete verteilte Warteschlange zum Speichern von Mitteilungen, während diese zwischen Computern und Anwendungskomponenten weitergeleitet werden. Amazon Simple Notifications Service (Amazon SNS) 11 bietet eine einfache Form der Benachrichtigung von Anwendungen oder Personen über die Cloud, indem Themen erstellt und ein Publish/Subscribe Protocol verwendet werden. Amazon Elastic MapReduce 12 verwendet ein Hadoop-Framework, das auf der weboptimierten Infrastruktur von Amazon Elastic Compute Cloud (Amazon EC2) und Amazon Simple Storage Service (Amazon S3) ausgeführt wird, und die Erstellung benutzerdefinierter JobFlows ermöglicht. JobFlow ist eine Sequenz von MapReduce-Schritten. Amazon Virtual Private Cloud (Amazon VPC) 13 ermöglicht Ihnen die Erweiterung Ihres Unternehmensnetzwerks in eine unternehmenseigene Cloud innerhalb AWS. Amazon VPC verwendet den IPSec-Tunnelmodus, in dem Sie eine sichere Verbindung zwischen einer Schnittstelle in Ihrem Rechenzentrum und einer Schnittstelle in AWS erstellen können. Amazon Route53 ist ein enorm skalierbarer Service, mit dem Sie Ihre DNS-Datensätze verwalten können, indem Sie eine HostedZone für jede zu verwaltende Domäne erstellen. 4 Weitere Informationen zur Elastic Load Balancing-Funktion finden Sie unter fhttp://aws.amazon.com/elasticloadbalancing 5 Weitere Informationen zu Elastic Block Store finden Sie unter 6 Weitere Informationen zu Amazon S3 finden Sie unter 7 Weitere Informationen zu Amazon CloudFront finden Sie unter 8 Weitere Informationen zu Amazon SimpleDB finden Sie unter 9 Weitere Informationen zu Amazon RDS finden Sie unter 10 Weitere Informationen zu Amazon SQS finden Sie unter und 11 Weitere Informationen zu Amazon SNS finden Sie unter 12 Weitere Informationen zu Amazon ElasticMapReduce finden Sie unter 13 Weitere Informationen zu Amazon Virtual Private Cloud finden Sie unter Seite 5 von 26

6 AWS Identity and Access Management (IAM) 14 ermöglicht Ihnen, mehrere Benutzer mit eindeutigen Sicherheitsnachweisen zu erstellen und deren Berechtigungen innerhalb Ihres AWS-Kontos zu verwalten. IAM ist nativ in den AWS-Services enthalten. Keine Service-APIs wurden geändert, um IAM zu unterstützen. Die vorhandenen auf AWS Service APIs beruhenden Anwendungen und Tools funktionieren weiterhin, wenn IAM verwendet wird. AWS bietet zudem verschiedene Zahlungs- und Fakturierungsdienste 15, die Amazons Zahlungsinfrastruktur nutzen. Alle AWS-Infrastrukturdienste bieten nutzungsbasierte Zahlung, die keine langfristig angelegten Verpflichtungen oder Verträge erfordern. So zahlen Sie beispielsweise pro Stunde für die Nutzung einer Amazon EC2-Instanz und zahlen im Falle von Amazon S3 für die genutzten Gigabyte für Speicherplatz und Datentransfer. Weitere Informationen zu jedem dieser Dienste und der jeweiligen Umlagefinanzierung finden Sie auf der AWS-Website. Beachten Sie, dass die Nutzung der AWS-Cloud keine Beeinträchtigung der gewohnten Flexibilität und Kontrolle hinnehmen müssen: Sie können das Programmierungsmodell, die Sprache und das Betriebssystem (Windows, OpenSolaris oder ein Linux-System) Ihrer Wahl verwenden. Wählen Sie die AWS-Produkte aus, die Ihren Bedürfnissen entsprechen Sie haben die Möglichkeit, die verschiedenen Services individuell oder beliebige Kombinationen zu nutzen. Da AWS eine flexible Ressourcennutzung bietet (Speicherplatz, Bandbreite und Computing), zahlen Sie immer nur für das, was Sie auch nutzen. Sie können weiterhin Ihre bisher verwendeten Systemverwaltungsprogramme nutzen, und Ihr Rechenzentrum in die Cloud erweitern. 14 Weitere Informationen zu Amazon Identity and Access Management erhalten Sie unter 15 Weiter Informationen zum Amazon Flexible Payments Service finden Sie unter Informationen zu Amazon DevPay finden Sie unter Seite 6 von 26

7 Konzepte des Cloud Computing Cloud Computing bedient sich einiger bewährter Konzepte des Aufbaus hoch skalierbarer Internet-Architekturen [13], und führt zudem einige neue Konzepte ein, die die Art des Aufbaus und der Bereitstellung von Anwendungen völlig verändern. Auf Ihrem Weg vom Konzept bis hin zur Implementierung könnten Sie also das Gefühl haben, dass sich alles verändert hat, aber dennoch nichts anders ist. Cloud Computing ändert eine Vielzahl an Prozessen, Mustern, Praktiken, Philosophien und setzt weiterhin auf einige traditionelle serviceorientierte Architekturprinzipen, die heute wichtiger denn je sind. In diesem Abschnitt stellen wir Ihnen einige dieser neuen Cloud-Konzepte und sich wiederholende SOA-Konzepte vor. Traditionelle Anwendungen basieren auf architektonischen und ökonomischen Annahmen, die zur Zeit dessen Entwicklung aktuell waren. Das Konzept des Cloud Computing beinhaltet einige neue Philosophien, die es zu verstehen gilt. Nachfolgend werden diese aufgeführt: Aufbau skalierbarer Architekturen Der Aufbau skalierbarer Architekturen ist besonders wichtig, um die Vorteile einer skalierbaren Infrastruktur nutzen zu können. Die Cloud ist so konzipiert, dass sie konzeptuell unendliche Skalierungsmöglichkeiten bietet. Diese können jedoch nicht genutzt werden, wenn Ihre Infrastruktur nicht skalierbar ist. Cloud und Infrastruktur müssen also zusammenarbeiten. Um die skalierbare Infrastruktur und alle Vorteile der Cloud effizient nutzen zu können, müssen die monolithischen Komponenten und Engpässe in Ihrer Architektur sowie die Bereiche, in denen Sie die On-Demand- Bereitstellungsfähigkeiten nicht nutzen können identifiziert, und ein Refactoring Ihrer Anwendung durchgeführt werden. Merkmale einer skalierbaren Anwendung: Wachsende Ressourcen führen zu einem proportionalen Wachstum der Leistung Ein skalierbarer Dienst bietet die Voraussetzungen für Heterogenität Ein skalierbarer Dienst ist operativ effizient Ein skalierbarer Dienst ist stabil Ein skalierbarer Dienst steigert im Wachstum seine Kosteneffektivität (bei steigender Anzahl der Einheiten sinken die Kosten pro Einheit) Diese Überlegungen sollten zu einem festen Bestandteil Ihrer Anwendung werden. Wenn Sie diese Merkmale bei der Entwicklung Ihrer Architektur berücksichtigen, erreichen Sie eine optimale Zusammenarbeit zwischen Architektur und Infrastruktur und somit die gewünschte Skalierbarkeit. Seite 7 von 26

8 Elastizität Der nachfolgende Graph veranschaulicht die unterschiedlichen Ansätze, die einem Cloud-Architekten die bedarfsorientierte Skalierbarkeit seiner Anwendungen ermöglichen. Scale-up-Verfahren: Nichtbeachtung der skalierbaren Anwendungsarchitektur und hoher Investitionsaufwand zur Aufstockung der Kapazitäten (vertikale Skalierung) zur Bedarfsdeckung. Dieser Ansatz ist bis zu einem gewissen Punkt umsetzbar, bedeutet jedoch entweder einen immens hohen Kostenaufwand (siehe "Hoher Investitionsaufwand" im Diagramm) oder der Bedarf übersteigt die Kapazität bevor die neuen Ressourcen implementiert werden können (siehe "Sie haben Ihre Kunden verloren" im Diagramm). Das traditionelle Scale-out-Verfahren: Aufbau einer Architektur mit horizontaler Skalierung und schrittweise Investitionen in die Infrastruktur. Die meisten Geschäftsanwendungen und umfangreichen Webanwendungen folgen diesem Muster durch die Verteilung ihrer Anwendungskomponenten, die Bündelung ihrer Datensätze und die Anwendung eines serviceorientierten Designs. Dieser Ansatz erweist sich zumeist als effektiver als ein Scale-up- Verfahren. Er erfordert jedoch weiterhin eine genaue Prognose bezüglich des Bedarfs in regelmäßigen Abständen sowie eine anschließende schrittweise Bereitstellung von Infrastruktur zur Deckung des Bedarfs. Dies führt oftmals zu einem Kapazitätsüberschuss ("Vergeudung materieller Ressourcen") und regelmäßiger manueller Überwachung ("Vergeudung menschlicher Ressourcen"). Darüber hinaus kann dieser Ansatz in der Regel nicht umgesetzt werden, falls die Anwendung Virenattacken ausgesetzt ist (oftmals als Slashdot-Effekt 16 bezeichnet). Hinweis: Beide Ansätze erfordern anfängliche Investitionskosten und beide Ansätze sind reaktiver Natur Seite 8 von 26

9 Infrastrukturkosten (USD) Zu viel überschüssige Kapazität Opportunitätskosten Hoher Investitionsaufwand Sie haben soeben Ihre Kunden verloren Angenommener Bedarf Tatsächlicher Bedarf Ansatz mit vertikaler Skalierung Herkömmlicher Ansatz mit horizontaler Skalierung Automatisierte Elastizität Automatisierte Elastizität + Abbildung 2: Automatisierte Elastizität Zeit t Traditionelle Infrastrukturen erfordern eine Prognose des Ressourcenbedarfs Ihrer Anwendung für einen Zeitraum über mehrere Jahre. Bei unzureichender Ressourcenplanung können Ihre Anwendungen unerwarteten Datenverkehr nicht verarbeiten, was sich negativ auf die Kundenzufriedenheit auswirken könnte. Bei einer Ressourcenüberdeckung vergeuden Sie wertvolles Kapital durch die Investition in ungenutzte Ressourcen. Die elastische und bedarfsorientierte Natur des Cloud-Ansatzes (Automatisierte Elastizität), ermöglicht somit eine relativ exakte Anpassung der Infrastruktur (durch die Möglichkeiten der Erweiterung und Reduzierung) an den tatsächlichen Bedarf, was die allgemeine Auslastung erhöht und die Kosten senkt. Elastizität ist eine der bedeutendsten Eigenschafen des Cloud Computing. Elastizität ist die Fähigkeit, eine einfache Hochund Herunterskalierung der Computing-Ressourcen mit minimaler Reibung zu ermöglichen. Wichtig ist hierbei die Erkenntnis, dass die meisten Vorteile, die das Cloud Computing bietet auf die Elastizität zurückzuführen sind. Als Cloud- Architekt sollten Sie dieses Konzept verinnerlichen und in Ihrer Anwendungsarchitektur berücksichtigen, um die Vorteile des Cloud Computing optimal zu nutzen. Anwendungen wurden ursprünglich für feste, starre und im Voraus geplante und bereitgestellte Infrastrukturen erstellt. Unternehmen hatten nie den Bedarf einer Bereitstellung und Installation von Servern auf täglicher Basis. Das hat zur Folge, dass die meisten Softwarearchitekturen keine kurzfristige Erweiterung oder Reduzierung von Hardware ermöglichen. Da die Bereitstellungszeit und Vorabinvestitionen für die Anschaffung neuer Ressourcen zu hoch waren, wurde die Optimierung der Hardware-Auslastung lange Zeit vernachlässigt. Unterauslastungen der Hardware, auf der die Anwendungen ausgeführt wurden, wurden billigend in Kauf genommen. Der Begriff der "Elastizität" einer Architektur wurde nicht berücksichtigt, da die Möglichkeit der kurzfristigen Kapazitätsaufstockung innerhalb von Minuten utopisch war. Seite 9 von 26

10 Das Konzept des Cloud Computing bietet heute diese Möglichkeiten und erfordert somit ein Umdenken in diesem Bereich. Cloud Computing rationalisiert die Beschaffung der erforderlichen Ressourcen; vorzeitige Ressourcenplanungen und ungenutzte Hardware gehören damit der Vergangenheit an. Stattdessen können Cloud-Architekten heutzutage Ressourcen anfordern, wenige Minuten bevor diese benötigt werden oder den Beschaffungsprozess gar automatisieren, und die Vorteile der hohen Skalierbarkeit und kurzen Antwortzeiten der Cloud nutzen. Gleiches gilt für die Auflösung nicht benötigter oder nicht voll ausgelasteter Ressourcen. Falls Sie eine derartige Umstellung nicht umsetzen und Ihre Anwendungsarchitektur nicht elastisch gestalten können, können Sie eventuell nicht alle Vorteile der Cloud nutzen. Der Aufbau einer Cloud-Architektur erfordert Kreativität und Ideen zur Implementierung von Elastizität in Ihrer Anwendung. So wurde beispielsweise eine Infrastruktur, die täglich Nightly Builds ausgeführt und in jeder Nacht um 2.00 Uhr für zwei Stunden Regressions- und Einheitstests durchgeführt hat (oftmals als "QA/Build-Box" bezeichnet) für den Rest des Tages auf Standbystatus gesetzt. Elastische Infrastrukturen bieten jetzt die Ausführung von Nightly Builds über Ressourcen, die nur für die zwei Stunden der Nutzung in der Nacht bezahlt werden müssen. Ein weiteres Beispiel bietet eine Webanwendung für internes Trouble-Ticketing, die stets bei höchster Auslastung (5 Server, 24 x 7 x 365) ausgeführt wurde, um die Anforderungen während des Tages zu erfüllen. Eine solche Anwendung kann heute je nach Datenverkehrsmuster bedarfsabhängig bereitgestellt werden (z. B. 5 Server von 9:00 bis Uhr und 2 Server von bis 9.00 Uhr). Der Aufbau einer intelligenten elastischen Cloud-Architektur, dessen Infrastruktur nur bei Bedarf ausgeführt wird, ist eine Kunst für sich. Elastizität sollte eine der Anforderungen des architektonischen Aufbaus oder eine Systemeigenschaft sein. Stellen Sie sich die Frage: Welche Komponenten oder Layers in meiner Anwendungsarchitektur können elastisch gestaltet werden? Wie kann die entsprechende Komponente elastisch gestaltet werden? Welche Auswirkungen wird die Implementierung von Elastizität auf die Gesamtarchitektur meines Systems haben? Im nächsten Abschnitt werden die spezifischen Techniken zur Implementierung von Elastizität in Ihren Anwendungen erläutert. Um die zahlreichen Vorteile des Cloud Computing effektiv nutzen zu können, ist es wichtig, diese Überlegungen in den Aufbau der Architektur einzubeziehen. Seite 10 von 26

11 Keine Angst vor Hindernissen! Wenn Sie sich dazu entschließen, Ihre Anwendungen in die Cloud zu implementieren, und versuchen, Ihre Systemspezifikationen den Spezifikationen der Cloud zuzuordnen, werden Sie feststellen, dass die Cloud eventuell nicht über die exakte Spezifikation der internen Ressource verfügt. Beispielsweise "stellt die Cloud nicht X RAM auf einem Server bereit" oder "Meine Datenbank benötigt mehr IOPS, als eine einzelne Instanz ermöglichen würde". Bedenken Sie, dass eine Cloud abstrakte Ressourcen bereitstellt, dessen Leistungsfähigkeit genutzt werden kann, wenn Sie sie mit dem On-Demand-Bereitstellungsmodell kombinieren. Cloud-Ressourcen können Sie bedenkenlos nutzen. Auch wenn Sie keine exakte Abbildung Ihrer Hardware in der Cloud-Umgebung erhalten, sollte Ihnen stets bewusst sein, dass Sie stets die Möglichkeit haben, weitere Ressourcen in der Cloud nutzen zu können, um Ihren tatsächlichen Bedarf zu decken. Falls Ihnen die Cloud also beispielsweise nicht mindestens den gleichen RAM auf einem Server zur Verfügung stellt, versuchen Sie, einen verteilten Cache-Server wie memcached 17 zu nutzen oder Ihre Daten auf mehrere Server zu verteilen. Falls Ihre Datenbanken mehr IOPS benötigen, und diese nicht direkt mit dem Wert der Cloud übereinstimmen, werden Ihnen je nach Datentyp und Verwendungsart verschiedene Empfehlungen unterbreitet. Falls es sich um eine Read-Heavy-Anwendung handelt, können Sie die Read-Last auf eine Flotte synchronisierter Slaves verteilen. Alternativ können Sie einen Sharding [10]-Algorithmus verwenden, der die Daten an die gewünschten Stellen leitet, oder verschiedene Datenbank-Lösungen einsetzen. Rückblickend werden Sie bei einer Kombinierung der On-Demand-Bereitstellungsfähigkeiten mit der Flexibilität feststellen, dass scheinbare Hindernisse sogar eine Verbesserung der Skalierbarkeit des Gesamtsystems zur Folge haben können. Virtuelle Administration Mit der Einführung des Cloud Computing hat sich die Rolle des Systemadministrators in einen "virtuellen Systemadministrator" geändert. Das bedeutet, dass die täglichen Administrator-Aufgaben noch interessanter geworden sind, da diese nun deutlich mehr über Anwendungen erfahren und Entscheidungen zum Wohle des Geschäfts als Ganzes treffen müssen. Der Systemadministrator muss nicht länger Server bereitstellen, Software installieren und Netzwerkgeräte anschließen, da all diese Routineaufgaben nun durch einige Klicks und Befehlszeileneingaben erledigt werden können. Die Cloud fördert durch die Programmierbarkeit der Infrastruktur Automation. Systemadministratoren müssen den Technology Stack erhöhen und lernen abstrakte Cloud-Ressourcen über Skripte zu verwalten. Auch der Datenbankadministrator wird zu einem "virtuellen Datenbankadministrator", der Ressourcen nun über eine webbasierte Konsole steuert, Skripts ausführt, die neue Kapazitäten programmatisch hinzufügen, falls es zu Engpässen bei der Datenbank-Hardware kommt, und die Tagesprozesse automatisiert. Der virtuelle DBA muss sich an neue Anwendungsmethoden gewöhnen (Bilder virtueller Geräte), neue Modelle einbeziehen (Abfrage-Parallelisierung, Geo-Redundanz und asynchrone Replizierung [11]), den architektonischen Ansatz der Datenverarbeitung überdenken (Sharding [9], horizontale Aufteilung [13], Bündelungen [14]) und verschiedene Speicheroptionen nutzen, die in der Cloud für verschiedene Datensatztypen zur Verfügung stehen. In traditionell operierenden Unternehmen besteht oftmals keine besonders enge Zusammenarbeit zwischen Entwicklern und Netzwerkadministrator, so dass diese die eingesetzten Anwendungen nicht ausreichend kennen. Das führt dazu, dass viele Optimierungsmöglichkeiten im Netzwerk-Layer und Architektur-Layer übersehen werden. Mit der Einführung des Cloud Computing sind beide Rollen teilweise zu einer Rolle verschmolzen. Bei dem Aufbau zukünftiger Architekturen müssen Unternehmen den Wissensaustausch zwischen den beiden Rollen stärker in den Vordergrund rücken und Überschneidungen der Aufgabenbereiche berücksichtigen Seite 11 von 26

12 Best Practices des Cloud Computing In diesem Abschnitt werden die Best Practices für den Aufbau einer Anwendung in der Cloud aufgeführt. Berücksichtigen Sie sämtliche mögliche Fehlerquellen Faustregel: Seien Sie bei dem Aufbau einer Cloud ein Pessimist; gehen Sie davon aus, dass alle erdenklichen Fehler auftreten. Anders ausgedrückt: Berücksichtigen Sie bei der Entwicklung, Implementierung und Anwendung die Einbindung automatisierter Recovery-Prozesse für mögliche Fehler. Gehen Sie insbesondere davon aus, das Ihre Hardware ausfallen wird. Planen Sie Ausfallzeiten ein. Gehen Sie von der größten anzunehmenden Katastrophe für Ihre Anwendung aus. Gehen Sie davon aus, dass Sie eines Tages deutlich mehr als die erwartete Anzahl an Anfragen pro Sekunde verarbeiten müssen. Gehen Sie davon aus, dass auch Ihre Anwendungssoftware irgendwann ausfallen wird. Mit einer pessimistischen Grundeinstellung werden Recovery- Strategien in der Regel bereits während der Entwicklungsphase berücksichtigt, was der Entwicklung des Gesamtsystems zugute kommt. Wenn Sie realisieren, dass bestimmte Abläufe irgendwann fehlschlagen, und dieses Bewusstsein in Ihre Architektur einfließen lassen und Prozesse implementieren, die diese Fehler beheben, bevor die skalierbare Infrastruktur einer Katastrophe ausgesetzt ist, erstellen Sie eine fehlertolerante Architektur, die optimal für die Einsatz in der Cloud geeignet ist. Stellen Sie sich folgende Fragen: Was passiert, wenn ein Knoten in Ihrem System ausfällt? Wie erkennen Sie diesen Ausfall? Wie ersetzen Sie diesen Knoten? Auf welche Art von Szenarios muss ich vorbereitet sein? Welches sind meine potenziellen einzelnen Fehlerquellen (Single Points of Failure)? Was passiert, wenn ein Load Balancer für eine Reihe von Anwendungsservern ausfällt? Falls in Ihrer Architektur Master- und Slave-Knoten eingesetzt werden: Was passiert, wenn ein Master-Knoten ausfällt? Wie wird die Ausfallsicherung aktiviert, und wie wird ein neuer Slave instanziiert und mit dem Master synchronisiert? Ebenso wie Sie Hardware-Ausfälle während der Entwicklung berücksichtigen sollten, müssen Sie auch Software-Ausfälle einplanen. Stellen Sie sich folgende Fragen: Was passiert mit meiner Anwendung, wenn die abhängigen Dienste die Schnittstellen wechseln? Was passiert, wenn der Downstream Service abläuft oder einen Fehler ausgibt? Was passiert, wenn die Cache Keys die maximale Speicherkapazität einer Instanz überschreiten? Implementieren Sie Mechanismen, die möglichen Ausfällen entgegenwirken. Bei einem Ausfallszenario können folgende Strategien angewandt werden: 1. Verfolgen Sie eine kohärente Strategie zur Sicherung und Wiederherstellung Ihrer Daten und automatisieren Sie diese 2. Implementieren Sie Prozess-Threads, die bei einem Neustart fortgesetzt werden 3. Ermöglichen Sie die Resynchronisierung des Systemstatus durch erneutes Laden aus Warteschlangen 4. Setzen Sie vorkonfigurierte und voroptimierte virtuelle Bilder zur Unterstützung (2) und (3) während des Systemstarts ein 5. Vermeiden Sie In-Memory-Sitzungen oder zustandsbehaftete Benutzerkontexte, verschieben Sie diese in Datenspeicher. Seite 12 von 26

13 Gute Cloud-Architekturen sollten für Neustarts undurchdringbar sein. In GrepTheWeb (siehe Dokument "Cloud Architectures" [6]) ist die Gesamtsteuerungsarchitektur durch eine Kombination aus Amazon SQS und Amazon SimpleDB äußerst belastbar hinsichtlich der in diesem Abschnitt aufgeführten Arten von Fehlern. Falls beispielsweise die Instanz, auf der der Controller-Thread ausgeführt wurde ausfällt, kann dieser wiederhergestellt werden und den vorherigen Status wieder aufnehmen, als wäre nichts passiert. Dies wird durch die Erstellung eines vorkonfigurierten Amazon Machine Image ermöglicht, welches beim Start seiner Ausführung alle Nachrichten aus der Amazon SQS-Warteschlange entfernt, und dessen Status bei einem Neustart über eine Amazon SimpleDB-Domain liest. Die Einplanung von Ausfällen der eingesetzten Hardware schützt Sie vor tatsächlichen Ausfallszenario. Dieses Designprinzip hilft Ihnen dabei, bedienfreundliche und intelligente Anwendungen zu entwickeln, wie sie auch in den Ausführungen von Hamilton [11] beschrieben werden. Wenn Sie dieses Prinzip erweitern können, um proaktive dynamische Lastenausgleiche und -messungen durchführen zu können, ist es Ihnen vielleicht möglich, Varianzen in der Netzwerk- und Festplattenleistung, die aufgrund der Multi-Tenant-Eigenschaften der Cloud bestehen, besser zu bewältigen. AWS-spezifische Taktiken zur Implementierung dieser Best Practices: 1. Ausfallsicherung dank Elastic IPs: Eine Elastic IP ist eine statische IP, die sich dynamisch neu zuordnen lässt. Sie ermöglicht eine Ausfallsicherung und schnelle Neuzuordnung zu einem anderen Serversatz, so dass Ihr Datenverkehr zu neuen Servern geleitet wird. Der Einsatz eignet sich besonders bei Upgrades von alten auf neue Versionen oder bei Hardware-Ausfällen. 2. Verwendung mehrerer Availability Zones: Availability Zones basieren auf dem gleichen Konzept wie logische Rechenzentren. Die Einrichtung mehrerer Availability Zones in Ihrer Architektur erhöht dessen Verfügbarkeit. Nutzen Sie die Funktionalität von Amazon RDS Multi-AZ [21]um Datenbank- Updates automatisch für mehrere Availability Zones zu wiederholen. 3. Nutzen Sie ein Amazon Machine Image zur einfachen Wiederherstellung und Duplizierung von Umgebungen in einer anderen Availability Zone; Setzen Sie mehrere Datenbank-Slaves innerhalb der Availability Zones ein, und richten Sie eine Hot Replication ein. 4. Nutzen Sie Amazon CloudWatch (oder verschiedene Open-Source-Echtzeitüberwachungstools) um die Sichtbarkeit zu erhöhen, und bei einem Hardware-Ausfall oder Leistungsabfall die angemessenen Maßnahmen zu ergreifen. Richten Sie eine Auto Scaling-Gruppe ein. So erhalten Sie eine feste Flottengröße und können nicht funktionsfähige Amazon EC2-Instanzen durch Neue ersetzen lassen. 5. Nutzen Sie Amazon EBS, und richten Sie Cronjobs ein, so dass stufenweise Speicherauszüge automatisch auf Amazon S3 hochgeladen werden, und Daten unabhängig von Ihren Instanzen bleiben. 6. Nutzen Sie Amazon RDS, und richten Sie den Aufbewahrungszeitraum für Sicherungskopien ein, dass automatisch Sicherungskopien erstellt werden. Seite 13 von 26

14 Entkoppeln Sie Ihre Komponenten Die Cloud stärkt das SOA-Designprinzip, so dass die Systemkomponenten besser skalierbar sind, je loser diese gekoppelt sind. Der Schlüssel liegt in der Erstellung von Komponenten, zwischen denen keine engen Abhängigkeiten bestehen. Falls also eine Komponente ausfällt, nicht antwortet oder aus irgendeinem Grund durch eine andere Verarbeitungsaktivität belegt ist (lange Antwortzeiten), so arbeiten die übrigen Komponenten des Systems weiter, als sei kein Ausfall aufgetreten. Im Wesentlichen führt eine lose Kopplung zur Isolierung der verschiedenen Layer und Komponenten Ihrer Anwendung, so dass jede Komponente asynchron mit den anderen Komponenten interagiert, und diese wie Black Boxes behandelt. So können Sie bei einer Webanwendungsarchitektur beispielsweise den Anwendungsserver vom Webserver und von der Datenbank isolieren. Der Anwendungsserver hat keinerlei Verbindung zu Ihren Webserver und umgekehrt; so können diese beiden Layer entkoppelt werden. Außerdem bestehen keinerlei codebasierte Abhängigkeiten oder funktionale Perspektiven. Bei einer Batchverarbeitungs-Architektur können Sie asynchrone, voneinander unabhängige Komponenten erstellen. Stellen Sie sich folgende Fragen: Welche Geschäftskomponente oder -funktion könnte von der aktuellen monolitischen Anwendung isoliert werden, und separat einzeln ausgeführt werden? Dann überlegen Sie, wie Sie mehr Instanzen dieser Komponente hinzufügen, ohne Ihr derzeitiges System zu modifizieren, und gleichzeitig mehrere Benutzer zuzulassen können. Wie viel Aufwand ist erforderlich, um die Komponenten zu verkapseln, so dass diese mit anderen Komponenten asynchron interagieren kann? Im Kontext des Cloud Computing spielen die Entkopplung Ihrer Komponenten, der Aufbau asynchroner Systeme und eine horizontale Skalierung eine bedeutende Rolle. Das ermöglicht Ihnen nicht nur das horizontale Skalieren durch Hinzufügen weiterer Instanzen der gleichen Komponente, sondern auch die Entwicklung innovativer Hybrid-Modelle, in denen einige Komponenten weiterhin intern ausgeführt werden können, während andere die Vorteile der Cloud- Skalierung zur Erhöhung der Rechenleistung und Bandbreite nutzen könnten. Auf diese Weise können Sie mit minimalem Aufwand und intelligenten Lastenausgleichsmaßnahmen überschüssigen Datenverkehr in die Cloud leiten. Ein lose gekoppeltes System kann über Nachrichten-Warteschlangen erstellt werden. Falls eine Warteschlange/Puffer für die Verbindung von zwei Komponenten eingesetzt wird, können hierdurch gleichzeitige Zugriffe, hohe Verfügbarkeit und Belastungsspitzen unterstützt werden. Dadurch wird die fortlaufende Leistungsfähigkeit des Gesamtsystems sichergestellt, auch wenn Teile von Komponenten zeitweise nicht zur Verfügung stehen. Falls eine Komponente ausfällt oder zeitweise nicht zur Verfügung steht, sammelt das System die Nachrichten, und fährt mit dessen Verarbeitung fort, sobald die Komponente wieder funktionsfähig ist. Seite 14 von 26

15 Tatsächlic her Herkömml icher Ansatz mit Feste Kopplung (Verfahrensprogrammierung) Wartesc hlange A Wartesc hlange B Wartesc hlange C Controll er A Controll er B Controll er C Lose Kopplung (unabhängige Phasen mit Warteschlangen) Abbildung 3: Entkoppeln von Komponenten mithilfe von Warteschlangen Eine verstärkte Verwendung von Warteschlangen wird in der GrepTheWeb-Architektur im Dokument Cloud Architectures [6] dargestellt. Damit Verzögerungen keine Auswirkungen auf andere Komponenten haben, werden in GrepTheWeb die Anfragen dauerhaft in Amazon SQS-Warteschlangen gesetzt, wenn eine Vielzahl an Anfragen in kurzer Zeit den Server erreichen (eine internet-induzierte Overload-Situation) oder die Verarbeitung regulärer Ausdrücke länger dauert als der Median (lange Antwortzeiten einer Komponente). AWS-spezifische Taktiken zur Implementierung dieser Best Practices: 1. Nutzen Sie Amazon SQS, um Komponenten zu isolieren [18] 2. Setzen Sie Amazon SQS als Puffer zwischen Komponenten ein [18] 3. Erstellen Sie jede Komponente so, dass sie eine Service-Schnittstelle darstellt und für ihre eigene Skalierbarkeit in sämtlichen angemessenen Dimensionen verantwortlich ist, und mit anderen Komponenten asynchron interagiert 4. Bündeln Sie den logischen Aufbau einer Komponente in einem Amazon Machine Image, so dass Sie diese öfters anwenden können 5. Machen Sie Ihre Anwendungen so zustandslos wie möglich. Speichern Sie den Sitzungsstatus außerhalb der Komponente (ggf. in Amazon SimpleDB) Seite 15 von 26

16 Implementieren Sie Elastizität Die Cloud bietet Ihren Anwendungen ein völlig neues Konzept der Elastizität. Elastizität kann auf drei unterschiedlichen Weisen implementiert werden: 1. Proaktive zyklische Skalierung: Periodische Skalierung, die in fixen Intervallen ausgeführt wird (täglich, wöchentlich, monatlich, vierteljährlich) 2. Proaktive ereignisbasierte Skalierung: Skalierung, die nur in Erwartung großer Datentransfermengen bezüglich eines besonderen Geschäftsereignisses ausgeführt wird (bei Produkteinführungen, Marketingkampagnen) 3. Bedarfsabhängige automatische Skalierung: Mithilfe eines Überwachungsdienstes kann Ihr System Trigger versenden, um entsprechende Maßnahmen ergreifen zu können, und eine automatische Hoch- oder Herunterskalierung basierend auf Metriken einzuleiten (z. B. Verwendung der Server oder Netzwerk- Interoperabilität) Die Implementierung von Elastizität erfordert zuvor die Automatisierung des Bereitstellungsprozesses sowie die Anpassung des Konfigurations- und Erstellungsprozesses. Dadurch wird die Skalierungsfähigkeit des Systems ohne menschliches Eingreifen sichergestellt. Dies ermöglicht unmittelbare Kosteneinsparungen durch die Steigerung der Gesamtauslastung. Dies wird vor allem erreicht, da Ihre Ressourcen eng an den tatsächlichen Bedarf geknüpft sind und so keine ungenutzten Ressourcen unterhalten werden müssen. Automatisieren Sie Ihre Infrastruktur Einer der bedeutendsten Vorteile der Nutzung einer Cloud-Umgebung ist die Möglichkeit, die APIs der Cloud zur Automatisierung Ihres Bereitstellungsprozesses nutzen zu können. Wir empfehlen Ihnen, sich ausreichend Zeit zu nehmen, und bereits in einer frühen Phase des Migrationsprozesses einen automatisierten Bereitstellungsprozess zu erstellen. Die Erstellung eines automatisierten und sich wiederholenden Bereitstellungsprozesses trägt zur Reduzierung von Fehlern bei und ermöglicht einen effizienten und skalierbaren Aktualisierungsprozess. So automatisieren Sie den Bereitstellungsprozess: Erstellen Sie eine Bibliothek mit Rezepten kleinen, häufig benötigten Skripts (für die Installation und Konfiguration) Verwalten Sie den Konfigurations- und Bereitstellungsprozess über Agents, die innerhalb eines AMI gebündelt sind Bootstrappen Sie Ihre Instanzen Bootstrappen Sie Ihre Instanzen Lassen Sie Ihre Instanzen während des Boot-Prozesses abfragen, wer sie sind, und was ihre Rolle ist. Jede Instanz sollte in der Umgebung eine Rolle (bei einer Web-Anwendung DB-Server, Anwendungsserver, Slave-Server ) bekleiden. Diese Rolle sollte während des Systemstarts als Argument ausgegeben werden, dass der AMI nach der Instanziierung die erforderlichen Schritte nach dem Systemstart vorgibt. Während des Systemstarts sollten die Instanzen, basierend auf ihrer Rolle, die erforderlichen Ressourcen belegen (Codes, Skripte, Konfiguration), und sich selbst an ein Cluster anhängen, um dessen Funktion zu übernehmen. Vorteile des Instanzen-Bootstrapping: 1. Erneuerung der (Dev, Staging, Produktions)-Umgebung mit wenigen Klicks und minimalem Aufwand 2. Mehr Kontrolle über Ihre abstrakten cloud-basierten Ressourcen 3. Reduzierung vom Menschen verursachter Entwicklungsfehler 4. Erstellung einer sich selbst heilenden und regenerierenden Umgebung, die resistenter gegen Hardware-Ausfälle ist Seite 16 von 26

17 AWS-spezifische Methoden zur Automatisierung Ihrer Infrastruktur 1. Definieren Sie automatische Skalierungsgruppen für verschiedene Clusters mithilfe der Amazon Autoskalierungsfunktion in Amazon EC2. 2. Überwachen Sie Ihre Systemmetriken (CPU, Speicher, Festplatten- und Netzwerk-Interoperabilität) mithilfe von Amazon CloudWatch, und ergreifen Sie entsprechende Maßnahmen (Dynamisches Starten neuer AMIs über den Autoskalierungsdienst) oder senden Sie Nachrichten. 3. Erfassen und speichern Sie Konfigurationsinformationen zu Ihren Geräten dynamisch: Erfassen Sie Konfigurationsdaten während des Boot-Vorgangs einer Instanz mithilfe von Amazon SimpleDB (z. B. Datenbankverbindungs-Strings). Mit SimpleDB können Sie außerdem Information zu einer Instanz, wie beispielsweise dessen IP-Adresse, den Gerätenamen oder die Rolle speichern. 4. Erstellen Sie die Prozesse so, dass die letzten Builds in einem Bucket in Amazon S3 gespeichert werden; Laden Sie die neueste Version einer Anwendung während des Systemstarts herunter. 5. Investieren Sie in die Erstellung von Ressourcenmanagementtools (Automatisierte Skripte, vorkonfigurierte Bilder) oder nutzen Sie intelligente Open-Source-Konfigurationsmanagementtools wie Chef 18, Puppet 19, CFEngine 20 oder Genome Bündeln Sie Just Enough Operating System (JeOS 22 ) und Ihre Software-Abhängigkeiten in einem Amazon Machine Image, um dessen Verwaltung und Pflege zu erleichtern. Übertragen Sie Konfigurationsdateien und Parameter während des Starts und rufen Sie Benutzerdaten 23 und Instanz- Metadaten nach dem Start ab. 7. Reduzieren Sie die Bündelungs- und Startzeit durch eine Ausführung des Boot-Prozesses über Amazon EBS-Speichermedien 24 und das Hinzufügen mehrerer Amazon EBS-Speichermedien zu einer Instanz. Erstellen Sie Speicherauszüge gemeinsamer Speichermedien und nutzen Sie Speicherauszüge 25 ggf. für mehrere Accounts. 8. Anwendungskomponenten sollten nicht die Integrität oder den Standort der genutzten Hardware übernehmen. So sollte die IP-Adresse eines neuen Knotens beispielsweise dynamisch an den Cluster angehängt werden. Führen Sie eine automatische Ausfallsicherung aus und starten Sie bei einem Ausfall einen neuen Klon. Denken Sie parallel Die Cloud macht eine Parallelisierung zu einem Kinderspiel. Egal ob Daten aus der Cloud abgerufen werden, in ihr gespeichert werden, oder in ihr verarbeitet werden (oder ob Aufträge ausgeführt werden) als Cloud-Architekt müssen Sie für die Entwicklung einer Architektur das Konzept der Parallelisierung verinnerlichen. Der Prozess der Parallelisierung sollte nicht nur bei jeder Gelegenheit implementiert, sondern zudem automatisiert werden, da Sie in der Cloud problemlos wiederholbare Prozesse erstellen können. 18 Weitere Informationen zu Chef finden Sie unter 19 Weitere Informationen zu Puppet finden Sie unter 20 Weitere Informationen zu CFEngine finden Sie unter 21 Weitere Informationen zu Genome finden Sie unter (Engl.) 23 Informationen zu Instanz-Metadaten und Benutzerdaten finden Sie unter (Engl.) 24 Weitere Informationen zur Funktion des Boot-Prozesses über Amazon EBS finden Sie unter 25 Informationen über die gemeinsame Nutzung von Speicherauszügen finden Sie unter Seite 17 von 26

18 Bei der Datenerfassung (Abrufen und Speichern) ist die Cloud in der Lage umfangreiche Parallel-Operationen auszuführen. Um maximale Leistung und maximalen Durchsatz zu erreichen sollten Sie die Möglichkeiten der Abfrage- Parallelisierung nutzen. Das Multithreading Ihrer Abfragen über mehrere gleichzeitige Threads ermöglicht ein schnelleres Abrufen oder Speichern der Daten, als die sequentielle Abfrage. Daher sollten die Prozesse einer Cloud- Anwendung durch die Anwendung einer Share-Nothing-Philosophie und die Nutzung des Multithreading-Prozesses threadsicher gemacht werden. Bei der Verarbeitung oder Ausführung von Abfragen in der Cloud spielt die Nutzung des Parallelisierungsprozesses eine noch bedeutendere Rolle. Als allgemeines Best Practice im Falle einer Webanwendung gilt die Verteilung der eingehenden Abfragung auf mehrere asynchrone Webserver mithilfe eines Lastausgleichs. Im Falle einer Batchverarbeitungsanwendung können Sie einen Master-Knoten in mehrere Slave-Knoten aufsplitten, die die Aufgabe parallel ausführen (wie in verteilten Verarbeitungs-Frameworks wie Hadoop 26 ). Am effektivsten kann die Cloud genutzt werden, wenn Sie Elastizität und Parallelisierung sinnvoll kombinieren. Über Ihre Cloud-Anwendung können Sie innerhalb von Minuten mit einigen API-Aufrufen ein Cluster aus Berechnungsinstanzen bereitstellen, Aufträge mithilfe parallelisierter Verarbeitung bearbeiten, die Ergebnisse speichern und alle Instanzen beenden. Ein Beispiel hierfür stellt die in [6] aufgeführte GrepTheWeb-Anwendung dar. AWS-spezifische Parallelisierungsmaßnahmen: 1. Nutzen Sie Multithreading für Ihre Amazon S3-Abfragen (siehe Best Practices [2]) 2. Nutzen Sie Multithreading für Ihre Amazon SimpleDB GET- und BATCHPUT-Abfragen [3][4] [5] 3. Erstellen Sie einen JobFlow. Verwenden Sie hierbei für jeden Ihrer täglichen Batch-Prozesse (Indexierung, Protokollanalyse etc.) den Amazon Elastic MapReduce Service. Dieser ermöglicht eine parallele Bearbeitung des Auftrags, was zu deutlichen Zeiteinsparungen führt. 4. Setzen Sie den Elastic Load Balancing-Dienst ein, und verteilen Sie Ihre Daten dynamischauf mehrere Webanwendungsserver Speichern Sie dynamische Daten möglichst am Standort der Verarbeitung und statische Daten am Standort der Endnutzung Allgemein gilt der Grundsatz, dass Ihre Daten möglichst verarbeitungsnah gespeichert werden sollten, um Latenzzeiten zu vermeiden. Dieser Best-Practice-Grundsatz gewinnt gerade aufgrund der häufig auftretenden Probleme mit Internet- Latenzzeiten an Bedeutung. Darüber hinaus zahlen Sie beim Cloud Computing für Bandbreiten für die genutzten Gigabyte bei Datenübertragungen, so dass diese Kosten schnell sprunghaft ansteigen können. Falls eine große Datenmenge, die verarbeitet werden muss, außerhalb der Cloud gespeichert ist, ist es unter Umständen günstiger und schneller, die Daten zunächst in die Cloud zu übertragen, und anschließend die Verarbeitung durchzuführen. Bei einer Data-Warehousing-Anwendung ist es beispielsweise empfehlenswert, den Datensatz in die Cloud zu übertragen, und anschließend parallele Abfragen gegen den Datensatz auszuführen. Bei Webanwendungen, die Daten aus relationalen Datenbanken erfassen und speichern, sollte die Datenbank wie auch der Anwendungsserver auf einmal in die Cloud verschoben werden. Falls die Daten in der Cloud generiert werden, sollten auch die Anwendungen, die diese Daten verarbeiten in der Cloud bereitgestellt werden, so dass diese den kostenlosen Datentransfer innerhalb der Cloud nutzen können und zusätzlich 26 Seite 18 von 26

19 von kürzeren Latenzzeiten profitieren. Für E-Commerce-Webanwendungen, die Protokolle und Clickstream-Daten generieren, ist es beispielweise empfehlenswert, den Log Analyzer und die Reporting Engines in der Cloud auszuführen. Umgekehrt sollten bei statischen Daten, die nicht oft verändert werden (z. B. Bild-, Video-, Audio-, PDF-, JS-, CSS- Dateien) die Vorteile eines Content Delivery Services nutzen, so dass die statischen Daten an einem Speicherort in Endnutzernähe (Abfrager) gecached werden, wodurch die Zugriffslatenz reduziert wird. Aufgrund der Cache- Speicherung bietet ein Content Delivery Service schnelleren Zugriff auf häufig benötigte Daten. AWS-spezifische Maßnahmen zur Implementierung dieses Best-Practice-Grundsatzes: 1. Senden Sie Ihre Datenlaufwerke mittels des Import/Export-Services 27 an Amazon. Bei der Übertragung größerer Datenmengen stellt Sneakernet 28 eventuell eine kostengünstigere Alternative zum Upload via Internet dar. 2. Nutzen Sie die gleiche Availability Zone, um ein Geräte-Cluster zu starten. 3. Erstellen Sie eine Verteilung Ihres Amazon S3 Buckets, und lassen Sie Amazon CloudFront Inhalte über alle 14 Edge-Locations auf der Welt in diesem Bucket zwischenspeichern. Best Practices bei Sicherheitsmaßnahmen In einer Multi-Tenant-Umgebung äußern Cloud-Architekten nicht selten Sicherheitsbedenken. Sicherheitsmaßnahmen sollten in jedem Layer der Cloud-Anwendungsarchitektur implementiert werden. Physische Sicherheit bietet Ihnen in der Regel Ihr Service Provider (Security Whitepaper [7], Engl.), was einen zusätzlichen Vorteil des Cloud Computing darstellt. Die Sicherheit auf Netzwerk- und Anwendungsebene liegt dagegen in Ihrer Verantwortung. Sie sollten daher die Best Practices je nach Bedarf in Ihrem Unternehmen anwenden. In diesem Abschnitt werden einige spezifische Tools, Funktionen und Richtlinien für den Schutz Ihrer Cloud-Anwendung in der AWS-Umgebung vorgestellt. Es wird empfohlen, die Vorteile, die diese Tools und Funktionen bieten, zu nutzen, um zunächst die grundlegende Sicherheit, und anschließend zusätzliche Best Practices zur Sicherheit mithilfe von Standardmethoden zu implementieren. Hierzu werden je nach Bedarf und Durchführbarkeit entsprechende Standardmethoden angewandt. Schützen Sie Ihre Daten während der Übertragung Falls Sie sensible oder vertrauliche Daten zwischen einem Browser und einem Webserver übertragen müssen, konfigurieren Sie SSL auf Ihrer Server-Instanz. Hierzu benötigen Sie ein Zertifikat einer Zertifizierungsstelle, wie beispielsweise VeriSign 29 oder Entrust 30. Der in dem Zertifikat enthaltene öffentliche Schlüssel authentifiziert Ihren Server für den Browser und bildet die Grundlage für die Erstellung des gemeinsamen Sitzungsschlüssels, der zur Verschlüsselung der Daten in beide Übertragungsrichtungen dient. Erstellen Sie mit einigen Befehlszeilenabrufen (über Amazon VPC) eine Virtual Private Cloud. Mit ihr können Sie Ihre eigenen isolierten Ressourcen innerhalb der AWS Cloud nutzen und diese Ressourcen dann über verschlüsselte IPsec- VPN-Verbindungen nach Industriestandard direkt mit Ihrem eigenen Rechenzentrum verbinden. Sie können außerdem einen OpenVPN-Server auf einer Amazon EC2-Instanz einrichten [15] und den OpenVPN-Client auf allen Benutzer-PCs installieren. 27 Weitere Informationen zu den Amazon Import/Export Services finden Sie unter Seite 19 von 26

20 Schützen Sie Ihre Daten während der Lagerung Falls Sie Bedenken haben, sensible und vertrauliche Daten in der Cloud zu speichern, sollten Sie die Daten (einzelne Dateien) verschlüsseln, bevor Sie sie in der Cloud speichern. Eine Verschlüsselung können Sie mit einem beliebigen Open-Source-Tool 31 oder kommerziellen 32 PGP-basierten Tools durchführen, bevor Sie die Daten als Amazon S3-Objekte speichern. Nach dem Download können Sie sie dann wieder entschlüsseln. Dieses Vorgehen stellt oftmals eine Good Practice dar, wenn HIPPA-fähige Anwendungen [8] erstellt werden, um geschützte Gesundheitsdaten zu speichern. Bei Amazon EC2 ist die Verschlüsselung abhängig vom Betriebssystem. Amazon EC2-Instanzen, die Windows ausführen, können die integrierte Funktion Encrypting File System (EFS) nutzen [16]. Diese Funktion führt die Ver- und Entschlüsselung von Daten und Ordnern automatisch aus, und macht den Prozess transparent für den Benutzer [19]. EFS verschlüsselt jedoch nicht, wie der Name vermuten lässt, das gesamte Dateisystem sondern stattdessen einzelne Dateien. Falls Sie ein vollständig verschlüsseltes Speichermedium benötigen, ist es empfehlenswert, das Open-Source- Produkt TrueCrypt 33 zu verwenden, das eine problemlose Integration mit NTFS-formatierten EBS-Speichermedien ermöglicht. Amazon EC2-Instanzen, die Linux ausführen, können EBS-Speichermedien mithilfe verschlüsselter Dateisysteme einbinden, die eine Vielzahl verschiedener Ansätze verwenden (EncFS 34, Loop-AES 35, dm-crypt 36, TrueCrypt 37 ). Ebenso können Amazon EC2-Instanzen, die OpenSolaris ausführen, die Vorteile der ZFS 38 -Verschlüsselung [20] nutzen. Ganz gleich, für welchen Ansatz Sie sich entscheiden, die Verschlüsselung von Dateien und Ordnern in Amazon EC2 trägt zur Gewährleistung der Sicherheit von Dateien und Protokolldaten bei, so dass lediglich die Benutzer und Prozesse auf dem Server die Daten als Klartext sehen können. Außerhalb des Servers sind jedoch nur verschlüsselte Daten sichtbar. Unabhängig von dem eingesetzten Betriebssystem oder der genutzten Technologie beinhaltet die Verschlüsselung von Daten während der Lagerung jedoch eine Herausforderung: Die Verwaltung der Schlüssel, mit denen die Daten verschlüsselt werden. Falls Sie die Schlüssel verlieren, verlieren Sie auch für immer Ihre Daten; falls die Sicherheit Ihrer Schlüssel gefährdet ist, sind auch Ihre Daten gefährdet. Informieren Sie sich daher eingehend über die Möglichkeiten der Schlüsselverwaltung von Produkten, und implementieren Sie Verfahren, das die Gefahr des Verlustes der Schlüssel minimiert. Neben Datendiebstahl sollten Sie sich auch vor sonstigen möglichen Datenverlusten schützen. Nutzen Sie regelmäßige Speicherauszüge der Amazon EBS-Speichermedien, um sicherzustellen, dass diese hochgradig widerstandsfähig und verfügbar sind. Speicherauszüge werden in der Regel schrittweise ausgeführt, in Amazon S3 (separate Geo-Position) gespeichert, und lassen sich mit wenigen Klicks oder Befehlszeileneingaben wiederherstellen. Schützen Sie Ihre AWS-Zugangsdaten AWS bietet zwei Arten von Sicherheitszugangsdaten: AWS-Zugangsschlüssel und X.509-Zertifikate. Ihr AWS- Zugangsschlüssel besteht aus zwei Teilen: Ihrer Zugangsschlüssel-ID und Ihrem geheimen Zugangsschlüssel. Wenn Sie die REST- oder Abfrage-API verwenden, müssen Sie über Ihren geheimen Zugangsschlüssel eine Signatur erstellen, die in Ihrer Authentifizierungsanfrage enthalten sein wird. Um eine Verfälschung während der Anfrage zu verhindern, sollten Alle Anfragen via HTTPS gesendet werden Seite 20 von 26