Praktischer Einsatz des Cloud Computing für Shopsysteme am Beispiel von Intershop Enfinity

Transkript

1 Praktischer Einsatz des Cloud Computing für Shopsysteme am Beispiel von Intershop Enfinity Prof. Dr. Volker Herwig, Steve Maaß, Peter Hänsgen University for Applied Sciences Erfurt Building Technologies and Applied Informatics PF , Erfurt Internet: Intershop Communications AG Intershop-Tower Jena Internet: Abstrakt Flexibilität und Skalierbarkeit sind Anforderungen, welche die IT Industrie schon seit langer Zeit beschäftigen. Cloud Computing, als eine Form der elektronischen Datenverarbeitung, bei der skalierbare und elastische IT-basierte Verarbeitungsmöglichkeiten mittels Internet- Technologien als Service an externe Kunden bereitgestellt werden [PSB09], bietet dafür enormes Potential. Der vorliegende Beitrag prüft die Vorteile und Herausforderungen des Cloud Computing am Beispiel eines führenden Online-Shopsystems. Hier ist die Bereitstellung solcher Infrastrukturleistungen notwendig, um die starken zeitlichen Unterschiede in der Nutzung schnell und kostengünstig unterstützen. Nach einer Einführung in das Thema Cloud Computing und einer kurzen Vorstellung der Architektur des Intershop Enfinity ecommerce-systems wird auf die verschiedenen Möglichkeiten der Nutzung des Cloud Computings für Shopsysteme eingegangen. Dies ist neben der Nutzung eines Software-as-a-Service (SaaS) Ansatzes die Möglichkeit der Nutzung von Infrastructure-as-a-Service (IaaS). Aufgrund der komplexen Anforderungen an die Architektur des Shopsystems, um unter Nutzung von IaaS betrieben werden zu können, liegt hier ein Schwerpunkt des Beitrages. Am Beispiel der Amazon Cloud Services wird anschließend eine beispielhafte Implementierung des Enfinity ecommerce-systems in einer Cloud Infrastruktur dargestellt. Cloud Computing Cloud Computing hat sich im vergangenen Jahr zu einem zentralen Trend-Thema der IT Industrie entwickelt. Cloud Computing ist ein betriebliches Modell, welches bei Bedarf einfachen Zugriff auf einen verteilten Pool von konfigurierbaren Computerressourcen bietet. Diese Ressourcen können bei minimalem Aufwand schnell bereitgestellt und freigegeben werden. [SM09a, S. 3] Gartner definiert Cloud Computing als eine Form der elektronischen Datenverarbeitung, bei der skalierbare und elastische IT-basierte Verarbeitungsmöglichkeiten mittels Internet-Technologien als Service an externe Kunden bereitgestellt werden. [PSB09] Sehr ähnlich hierzu ist auch die Definition des National Institut of Standards and Technology (NIST): Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage,

2 applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. [MeGr09, S. 1] Zum jetzigen Zeitpunkt scheint die Technologie so weit fortgeschritten zu sein, dass mittels des Cloud Computing einer großen Anzahl an potentiellen Nutzern Leistungen nach Bedarf zur Verfügung gestellt werden können. Die Nutzendiskussion des Cloud Computing ist dabei in der Regel fokussiert auf der einfachen, schnellen und kostengünstigen Bereitstellung der Leistungen aus der Cloud. Hierdurch entsteht ein enormes Potential für Kostensenkungen, und eine Verlagerung von Fixkosten zu variablen Kosten scheint möglich. Aufgrund der Flexibilität und Skalierbarkeit der IT Ressourcen ist es Unternehmen zudem möglich, Geschäftsideen schneller durch IT unterstützen zu können. [BI09, S. 10 und 24ff.] Die Herausforderungen des Cloud Computings entsprechen in vielem denen des klassischen IT Outsourcing und liegen vor allem in den Themen Sicherheit und Verfügbarkeit. [Me10] Shopsysteme Das Wachstum im Internet-Handel ist ungebrochen, immer mehr Kunden und Händler nutzen des Internet zur Recherche, zum Kauf oder Verkauf von Waren und Dienstleistungen. Abb. 1 Wachstum im E-Commerce in Deutschland (in Mrd. Euro) Shopsysteme bieten Unternehmen die Möglichkeit, ihre Waren im Internet zu verkaufen. [Hö09, S. 19ff.] Sie dienen sowohl als ergänzende Vertriebsplattform zum normalen Handel über den klassischen Laden als auch als einziger Vertriebskanal bei Handelsunternehmen, die völlig auf den Filialverkauf verzichten. Dabei sehen sich die Unternehmen die ihre Waren über ein Shopsystem anbieten (Shopbetreiber) vielfältigen Herauforderungen gegenüber. Die größten Herausforderungen für den Verkauf von Waren und Dienstleistungen im Internet liegen bei: Bekanntmachung des Angebots 80% Pflege des Produktangebots im Shop 49% Kontinuierliche Anpassung an neue rechtliche Rahmenbedingungen 44% Zeitnahe Abarbeitung der Bestellungen 34% Technische Pflege/Weiterentwicklung des Shops 33% Zahlungsabwicklung 22% Gewährleistung ausreichenden Supports 12% Auswahl geeigneter Dienstleister für Zahlungs- und Versandabwicklung 9% Bearbeitung von Retouren 7%

3 Sonstiges 2% [SKBa08, S. 42] Somit sahen rund 45% der Befragten technische Themen im Hinblick auf den Betrieb des Shopsystems als eine Herausforderung an. Gerade auch hier kann durch die Nutzung des Cloud Computing Abhilfe geschaffen werden. Es muss dabei neben dem klaren Vorteil der einfachen, schnellen und kostengünstigen Bereitstellung der Leistungen aus der Cloud vor allem aber auch um das Potential zur Verlagerung von Fixkosten zu variablen Kosten gehen. Nutzungsansätze Die NIST und andere definieren drei verschiedenen Service Modelle für das Cloud Computing. [MeGr09, S. 2] Cloud Software as a Service (SaaS): Die dem Kunden bereitgestellte Leistung ist die durch den Anbieter angebotenen Applikation. Auf diese Applikation kann mittels einer thin-client Schnittstelle (bspw. Webbrowser) zugegriffen werden. Der Kunde hat dabei keine Kontrolle über die darunterliegende Infrastruktur, abgesehen von spezifischen Kundeneinstellungen. Cloud Platform as a Service (PaaS): Die dem Kunden bereitgestellte Leistung beinhaltet die Möglichkeit in einer durch den Anbieter bereitgestellten Umgebung eigene Applikationen bereitzustellen. Diese Applikationen müssen zuvor auf der durch den Anbieter bereitgestellten Programmierplattform erstellt werden, entweder vom Kunden selbst oder von einem Dritten. Der Kunde hat dabei keine Kontrolle über die darunterliegende Infrastruktur, jedoch Kontrolle über seine auf der Infrastruktur erstellte Applikation inklusive möglicher Runtime-Einstellungen. Cloud Infrastructure as a Service (IaaS): Die dem Kunden bereitgestellte Leistung ist die Nutzung von Rechenleistung, Speicherplatz und anderen fundamentalen Infrastruktur-Ressourcen. Der Kunde kann unter Nutzung dieser Ressourcen ohne Einschränkungen Software bereitstellen. Er hat dabei keine Kontrolle über die durch den Anbieter bereitgestellten Infrastruktur-Ressourcen, jedoch Kontrolle über die durch ihn bereitgestellte Software wie Betriebssysteme und Applikationen. Der Kunde hat auch limitierte Kontrolle über ausgewählte Netzwerkkomponenten. Alle drei Modelle können grundsätzlich auch für den Einsatz des Cloud Computing bei Shopsystemen zum Einsatz kommen. Die Bereitstellung von Shopsystemen als Software as a Service wird bereits seit Jahren entweder direkt von den Herstellern der Shopsysteme oder Dritten den Shopbetreibern angeboten. Anstatt sich selbst um die Software des Shops zu kümmern, wird dies einem Dienstleister (entweder der Hersteller oder ein Dritter) überlassen, und der Shopbetreiber kann sich vollständig auf den Verkauf und das Marketing konzentrieren. Darüber hinaus bieten viele Dienstleister Schnittstellen zu Bezahlsystemen und Versanddienstleistungen, der Shopbetreiber muss sich also auch um diese Dinge nicht kümmern und kann beispielsweise die Kosten für einen Programmierer sowie eigene Hardware einsparen. Bezahlt wird dieser Komfort durch eine erhöhte Abhängigkeit, bisweilen mit Einschränkungen in der Erweiterbarkeit und einem möglicherweise langweiligen Design nach Baukastenprinzip. Seit mehreren Jahren existieren Dienste für Plattform as a Service. Marktführer in diesem Bereich sind die Plattformen Force.com (von Salesforce.com), Google App Engine (von Google), Amazon Web Services (von Amazon) und Windows Azure (von Microsoft). Dabei

4 ist auch die Entwicklung von Shopsystemen durchaus im Fokus, wie das folgende Einsatzszenario von Microsoft Azure zeigt. Abb. 2 Windows Azure - Szenario Shopsystem [Mi10] [Ko10, S. 61] Beispielsweise aufgrund von sehr speziellen Produktangeboten, die sich mit herkömmlichen Shopsystemem so nicht abwickeln lassen, ist die Entwicklung eines solchen eigenen Shopsystems durchaus denkbar. Interessant ist dabei immer auch die Verbindung mit speziellen Diensteanbietern zur Unterstützung ausgewählter Geschäftsprozesse. Ein Beispiel hierfür sind die Amazon Fulfillment Services ( Mit ihnen ist es möglich, die sich an den eigentlichen Verkauf anschließenden Prozesse wie Lagerhaltung, Verpackung, Frankierung und Versand vollständig über Amazon abzuwickeln. Durch entsprechende Web Services ist eine Integration in das eigene Shopsystem möglich. Die Bereitstellung von Shopsystemen auf Basis von Infrastructure as a Service ist ein recht neues Konzept, welches die in der Cloud verfügbaren Infrastrukturdienste nutzt, um ein Shopsystem zu betreiben. Dabei kann der Shopbetreiber selbst oder ein Software as a Service Anbieter das Shopsystem unter Einbezug von Infrastructure as a Service betrieben. Diese Form der Nutzung des Cloud Computing soll im Folgenden näher betrachet werden. Anforderungen Um ein Shopsystem in einer Cloud Infrastruktur nutzen zu können und die beschriebenen Vorteile nutzen zu können, muss das Shopsystem selbst einige Anforderungen erfüllen. Das Shopsystem selbst sollte ein verteiltes System sein, die Verarbeitung der Daten sollte also auf mehreren verschiedenen Computern verteilt erfolgen (Verteilbarkeit) [Som07, S.300]. Verteilt laufende Systeme haben den Vorteil der Ressourcenteilung. Das heißt beispielsweise, es können Hard- und Softwareressourcen innerhalb des gleichen Netzwerkes gemeinsam genutzt werden. Nebenläufige Abarbeitung von Prozessen auf unterschiedlichen Computern eines Netzwerkes ist ein weiterer Vorteil. Durch die Verteilung wird eine erhöhte Fehlertoleranz gegenüber Hard- und Softwarefehlern von einzelnen Komponenten des Gesamtsystems erreicht [Som07, S.300]. Daraus resultiert auch die bedarfsgerechte Erhöhung oder Verringerung der Leistungsfähigkeit des Gesamtsystems. Zudem sollte das Shopsystem für den Betrieb in einer Cloud aus möglichst lose gekoppelten Komponenten bestehen (Lose Kopplung). Die lose Kopplung ist sehr wichtig,

5 damit sich Änderungen oder Fehler innerhalb einer Komponente nicht auf die gesamte Anwendung auswirken [SM09b, S. 23]. Um möglichst wenige Abhängigkeiten der Komponenten untereinander zu erreichen ist es nötig, dass die Anwendung nötige Statusinformationen persistent und zentral abspeichert. So gehen im Fehlerfall einer Komponente die Statusinformationen nicht verloren. Eine andere Komponente kann dann gegebenenfalls die Verarbeitung übernehmen. Statusbehaftete Informationen der gesamten Anwendung könnten laut [Ree09, S.75] und [SM09b, S. 23] in einer gemeinsamen Datenbank persistent gesichert werden. Für web-basierte Anwendungen können die Zustandsinformationen eines Nutzers auch in einem Cookie oder in der URL kodiert gespeichert werden [SM09b, S. 23]. Das Shopsystem sollte es auch ermöglichen, seine Leistungsfähigkeit im laufenden Betrieb zu erweitern oder zu verkleinern (Skalierbarkeit) [DJM05, S. 134]. In der Vergangenheit wurden Anwendungen darauf hin entwickelt, dass sie steigende Anforderungen mittels vertikaler Skalierung (Erweiterung/Reduktion durch Dimensionierung der Instanz bspw. CPU, Speicher, etc.) bewältigen [Ree09, S.150] [SM09, S.17]. Der Umstieg zu horizontal skalierenden Systemen (Erhöhung/ Verringerung der Anzahl der Instanzen) ist ein entscheidender Faktor für den effektiven Einsatz einer Cloud-basierten Infrastruktur [Ree09, S.150]. Dabei muss sichergestellt sein, dass reibungslos und zu jedem Zeitpunkt neue Instanzen (z. B. Server mit Komponente der Anwendung) hinzugefügt bzw. entfernt werden können, ohne den Betrieb durch Verzögerungen oder Datenverlust zu beeinträchtigen. Neu angeforderte Instanzen müssen nach Verfügbarkeit automatisch in den Rechnerverbund integriert werden, damit diese das Gesamtsystem leistungsfähiger machen. Die Form der vertikalen Skalierung ist immer möglich. Jedoch ist die horizontale Skalierung wesentlich flexibler und kann besser an ein spezifisches Lastaufkommen angepasst werden. Außerdem steigen Preise für leistungsfähigere Hardware meist überproportional an, so dass es wesentlich effektiver ist mehrere weniger leistungsfähige Ressourcen zu einem Verbund (Cluster) zusammen zu schließen. Außerdem erhöht sich die Ausfallsicherheit enorm gegenüber einer Lösung mit nur einem sehr leistungsfähigen Server. Die Herausforderung beim horizontalen Skalieren besteht in dem nahtlosen Hinzufügen und Entfernen der zusätzlichen Rechenkapazitäten in einer Schicht. Es müssen geeignete Mechanismen vorhanden sein, so dass beim Entfernen einer Instanz zum Beispiel keine Daten verloren gehen. Abb. 3 Horizontale Skalierung der Schicht Anwendungslogik Beim Einsatz einer Mehr-Schichten-Architektur können einzelne Schichten gezielt nach dem tatsächlichen Bedarf dimensioniert werden. Die Anzahl an verfügbaren Applikationsservern kann beispielsweise bei steigender Last erhöht werden (siehe Abb. 3). Dagegen muss die Anzahl an Web-Servern nicht erhöht werden, da dieser mit den eingehenden Anfragen noch nicht ausgelastet ist. Durch die Trennung von Web- und Applikationsserver ist somit in diesem Falle, unter Einsatz der tatsächlich benötigten Ressourcen je Schicht, eine effiziente Verarbeitung möglich.

6 Shopsysteme, die in einer Cloud betrieben werden, sollten verteilbar, skalierbar und mit weitgehend zustandsloser Verarbeitung entwickelt werden, um das Cloud Computing optimal als mögliche Infrastruktur nutzen zu können. Auf unterschiedliche Rechensysteme verteilbare Komponenten eines Shopsystems sind die Grundlage für eine skalierbare Mehr- Schichten-Architektur. Ein Shopsystem kann in funktionale Schichten gegliedert werden, welche wiederum mittels Netzwerken verknüpft sind. Für das effektive Nutzen der flexiblen Ressourcenbereitstellung einer Cloud sollte jede Schicht mittels horizontaler Skalierung dem Bedarf angepasst werden können. Intershop Enfinity Enfinity Suite 6 ist ein ecommerce-system der Firma Intershop Communications AG ( dass auf einer skalierbaren und leistungsfähigen Softwarearchitektur zum Betreiben von aufwendigen ecommerce-anwendungen basiert. Enfinity besitzt eine mehrschichtige Architektur. Sie besteht aus Webschicht, Anwendungsschicht und der Datenschicht. Diese funktional gegliederten Schichten können auf mehrere Rechner verteilt und jeweils nach Leistungsanforderungen skaliert werden [Int08b]. Abb. 4 Intershop Enfinity Architektur Als Teil des Web Server (Apache HTTP Server) läuft als Plugin der Web Adapter. Der Web Server selbst leitet die Requests und Responses von bzw. zu einem Client und dem Web Adapter. Der Web Adapter ist verantwortlich für die Hauptfunktionen bzw. Merkmale Web Caching, Load Balancer, Skalierbarkeit und Redundanz sowie die SSL-Box Unterstützung [Int08a], [Int08b]. Die Anwendungsschicht besteht im Wesentlichen aus den Komponenten Application Server (auf Basis von Apache Jakarta Tomcat), Node Manager und Oracle Client [Int08a], [Int08b]. Die Datenschicht enthält persistent zu speichernde Objekte und besteht aus den Komponenten Datenbank (Oracle 10g) und Shared File System [Int08a], [Int08b]. Die Anzahl der Requests, die an das Shopsystem gerichtet werden, variieren stark und sind schwer vorhersagbar. Mittels Lastverteilung können hochverfügbare Systeme betrieben werden, die performant und fehlertolerant sind. Die einzelnen Enfinity Komponenten Application Server, Web Adapter und Datenbank können skaliert werden. Folgende Maßnahmen für Hochverfügbarkeit und Lastverteilung werden von Enfinity unterstützt [Int08a, S.207ff.]:

7 Application Server Clustering: Damit können mehrere Application Server in einem Enfinity Suite 6 Cluster laufen. Der Cluster kann aus mehreren Application Server Instanzen auf einem Host bestehen oder verteilt auf mehreren Hosts laufen. Mehrere Application Server sind für Seiten mit viel Datenaufkommen, hoher Last und für Session Fail-over nötig. Web Adapter Load Balancing: Im Web Adapter ist ein dynamischer Load Balancing Algorithmus implementiert. Dieser versucht den am besten geeigneten Application Server für jeden Request zu finden. Für die Verteilung der Requests überwacht der Web Adapter die mittlere Bearbeitungszeit für mehrere Requests und leitet daraus Kennzeichen für die Qualität der Beantwortung von Anfragen eines Application Servers ab. Multiple Web Adapters: In einem Enfinity Suite 6 Cluster können, in Kombination mit einem Load Balancer, mehrere Web Server mit Web Adapter zur Verteilung der eingehenden Requests eingesetzt werden. Der Load Balancer kann die Verfügbarkeit und Auslastung der Web Adapter prüfen und die Anfragen gezielt verteilen. Die Web Adapter wenden jeweils eigene Load Balancing Mechanismen auf die verfügbaren Application Server an (siehe oben). Built-in Session Fail-Over: Dieser Mechanismus stellt sicher, dass Informationen einer Session auf einem Application Server im Fehlerfall verfügbar bleiben. Dazu werden die Sessions persistent in einer Datenbank gespeichert. Wenn ein Application Server ausfällt, werden Requests dieser Session an eine anderen Application Server Instanz weitergeleitet. In einem Enfinity-Cluster aus mehreren Anwendungsservern müssen Nachrichten in regelmäßigen Abständen zwischen den einzelnen Instanzen ausgetauscht werden. Diese Nachrichten werden per Multicastmechanismus von einer Instanz an die anderen Server des Clusters in dem gleichen Netzwerksegment gesendet. Die Nachrichten werden zum Beispiel benötigt, um zu erkennen, ob eine Instanz dem Cluster beitritt oder nicht mehr verfügbar ist. Die zuvor beschriebenen, einzelnen Maßnahmen sind je nach Anforderung beliebig kombinierbar. So kann ein individuell zugeschnittenes, hoch verfügbares und sehr ausfallsicheres Shopsystem realisiert werden. Im Hinblick auf die dargestellten Anforderungen erscheint das Enfinity-System geeignet, in einer Cloud Infrastruktur betrieben zu werden. Amazon Web Services Amazon gilt als einer der größten und führenden Anbieter auf dem Gebiet des Cloud Computing. Da Enfinity derzeit nur Datenbanken von Oracle unterstützt, muss die eingesetzte Cloud Computing Umgebung eine Unterstützung für dieses Datenbanksystem gewährleisten. Die Amazon Cloud Infrastruktur wurde ausgewählt, weil sie eine gute Unterstützung des Datenbanksystems von Oracle bieten. Oracle selbst stellt zahlreiche Hinweise, Anleitungen und auch eigene vorkonfigurierte Server zum Download für die Amazon Cloud Infrastruktur bereit. Des weiteren werden von Amazon eine breite Palette von möglichen Betriebssystemen (u.a. Red Hat Enterprise Linux, Windows Server 2003, OpenSolaris, Linux Debian) unterstützt. Als typisches IaaS Angebot stellt die Amazon Cloud Infrastruktur Rechenkapazität, Speicher und andere Dienste zum Aufbau einer Infrastruktur für Anwendungen bereit. Genutzte Dienste werden nach Zeit und verbrauchten Ressourcen abgerechnet.

8 Auf eine Vorstellung der einzelnen Dienste wie Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3) und Amazon SimpleDB soll hier aus Gründen des Umfangs verzichtet sein, verwiesen sei auf die Literatur und die Webseite des Anbieters (u.a. [Mur08], [Ree09]). Der Zugriff auf die Dienste ist durch verschiedene Schnittstellen wie REST, SOAP und HTTP (Query API) möglich. Anfragen an die verfügbaren Schnittstellen können nur per Authentifizierung getätigt werden. SOAP Nachrichten werden per X.509 Zertifikate autorisiert. REST und Query Anfragen werden vom Besitzer des AWS Accounts digital signiert [Mur08, S.27ff.]. Die wichtigsten Bestandteile der Amazon Cloud Infrastruktur sind im Folgenden kurz beschrieben: AMI: Ein AMI (Amazon Machine Image) ist ein Abbild einer EC2 Instanz (virtueller Server) zu einem bestimmten Zeitpunkt mit konfiguriertem Betriebssystem, installierter Software und gespeicherten Daten. Es ist die Grundlage für den Startvorgang eines virtuellen Servers [Mur08, S.163]. Instance: Eine Instanz ist ein gestarteter virtueller Server mit vollen Root- bzw. Administrator-Rechten. Grundlage zum Starten einer Instanz ist ein AMI. Es ist möglich mehrere Instanzen eines AMI zu starten, somit können beliebig viele identische Server gestartet werden. Änderungen an einer Instanz werden nicht persistent gespeichert, d. h. Änderungen sind nur zur Laufzeit an einer Instanz möglich. Um Änderungen dauerhaft zu speichern muss aus einer Instanz ein neues AMI erzeugt werden. Der Vorgang wird als Bundling bezeichnet [Ama09g], [Ree09, S.29]. Region: Ein geografisches Gebiet in dem Instanzen gestartet werden (Bsp.: US- East, EU-West) [Ama09g]. Availability Zone: Abgegrenzter Bereich in einer Region, um Fehler in einer Availability Zone von den Anderen fern zu halten und somit im Fehlerfall die gesamte Region nicht zu stören. Die einzelnen Zonen einer Region sind mit einem schnellen Netzwerk untereinander verbunden [Ama09g]. Zur Zeit gibt es in der Region US drei und in EU zwei Availability Zones. Beim Erzeugen neuer Instanzen kann beim Start optional die gewünschte Availability Zone übergeben werden. Damit kann erhöhte Redundanz für eine Anwendung in einer Region erreicht werden [Ree09, S.30]. Security Group: Bezeichnung für eine Menge von Regeln zur Kontrolle des Netzwerkverkehrs für eine Instanz [Ama09g]. Eine Instanz kann mehreren Security Groups angehören. EBS: Elastic Block Store (EBS) stellt persistenten Speicher für eine Instanz bereit. Dieser Speicher wird blockweise zugewiesen und kann nach dem Start der Instanz als Laufwerk eingebunden werden. EBS ist auf Hochverfügbarkeit und Zuverlässigkeit ausgelegt. Mit mehreren EBS-Laufwerken kann auch ein virtuelles RAID erzeugt werden [Ama09f], [Ree09, S.30]. Snapshot: Ist ein Abbild eines EBS, welches in Amazon Simple Storage Service (S3) abgelegt wird. Snapshots können für Backup- oder Replikationszwecke erzeugt werden. Elastic IP Address: Ist eine statische IP-Adresse, die dem Amazon-Nutzer (Account) zugewiesen ist. Die Adresse kann einer Instanz zugewiesen und entfernt werden. Um zu vermeiden, dass Adressen nicht vorsorglich von Anwendern reserviert oder wenig genutzt werden, müssen sie bei Nichtnutzung, also sobald sie keiner gestarteten Instanz zugewiesen sind, bezahlt werden [Ama09g].

9 Abb. 5 Bestandteile Amazon EC2 nach [Ree09, S.29] Wichtig ist die Unterscheidung zwischen AMI und Instance. Deshalb wird in [Ree09, S.31] auf die Analogie zu einer objektorientierten Programmiersprache hingewiesen. Ein AMI entspricht einer Klasse und eine EC2-Instanz einer Objektinstanz. Zur effektiven Nutzung des EC2 Dienstes werden weitere Funktionalitäten angeboten, mit denen die Instanzen weitestgehend automatisiert verwaltet werden können. So überwacht bspw. CloudWatch registrierte Instanzen in Echtzeit. Es können Parameter wie Prozessorauslastung, Datenverkehr, Festplattenplatz und -aktivität überwacht, aggregiert und ausgewertet werden. [Ama09b] CloudWatch kann als Basis für die eigene Implementierung von Zustandsüberwachung, Skalierung und Lastverteilung von Instanzen dienen. Wie beschrieben, existieren APIs zum Steuern von EC2 und den anderen Diensten. Um die Nutzung zu vereinfachen, existieren verschiedene Möglichkeiten wie EC2 und die anderen AWS Dienste kontrolliert werden können. Diese sind die AWS Management Console (Web- Oberfläche), die Kommandozeilenwerkzeuge, die typica Java Bibliothek ( und Plugins bspw. für Eclipse. Intershop Enfinity als Infrastructure as a Service Das ecommerce-system Enfinity Suite 6 von der Firma Intershop basiert auf einer skalierbaren und leistungsfähigen Softwarearchitektur. Im Idealfall kann eine flexible Cloudbasierte Infrastruktur und ein Shopsystem wie Enfinity den typischen Lastbedingungen eines Online Shops (bspw. im Rahmen des Weihnachtsgeschäftes) bedarfsgerecht angepasst werden, um Überkapazitäten und Engpässe zu vermeiden. Nicht genutzte Ressourcen müssen nicht bezahlt werden, stehen aber bei Bedarf in einem kurzen Zeitraum wieder zur Verfügung. Unter Nutzung der Amazon Web Services wird zunächst unter Nutzung der verfügbaren AMI Basic Microsoft Windows Server 2003 und einer Oracle 10g Datenbank eine Intershop Enfinity Suite 6 installiert. Im Anschluss wird aus dieser Instanz ein AMI erzeugt (Bundling). Ein AMI besteht aus einer XML-Datei (Manifest), die das Image beschreibt. Die Manifest- Datei enthält unter anderem Informationen darüber, wer das AMI erzeugt hat, welches Betriebsystem darin enthalten und in welchen Dateien das eigentliche Image gespeichert ist. Das Image wird in ca. 10 Mbyte große Dateien aufgeteilt und in dem bei der AMI

10 Erzeugung angegebenem Bucket von Amazon S3 gespeichert. Nach dieser einfachen Installation befinden sich alle Komponenten von Enfinity komplett auf einem Amazon Cloud Server. Dies ermöglicht eine vertikale Skalierung durch Veränderung der Leistungsfähigkeit des Servers. Die Potentiale des Cloud Computing im Hinblick auf eine horizontale Skalierung werden also nicht ausgenutzt. Alternativ lässt sich auch ein Szenario aufbauen, in dem die einzelnen Komponenten in mehrere AMIs verteilt sind. Grundsätzlich werden zwei Images benötigt: ein Master- und ein Slave-Image. Abb. 6 Szenario AMI Verteilung Das Master-Image beinhaltet eine Standalone-Enfinity-Installation mit allen benötigten Komponenten. Per PublicDNS können Requests an den Web Adapter gesendet werden. Von diesem Image wird genau eine Instanz gestartet. Wenn die Master-Instanz gestartet wurde, ist der Online Shop bereits mit einer Instanz lauffähig, da sich alle benötigten Komponenten darauf befinden. Von dem Slave-Image können bei Bedarf zusätzlich eine oder mehrere Instanzen zu der Master-Instanz erzeugt werden. Auf den Slave-Instanzen befindet sich jeweils genau ein Application Server. Dadurch kann ein flexibler Application Server Cluster erzeugt werden, der je nach Lastsituation durch eine variable Anzahl von Slave-Instanzen skaliert werden kann. Wenn die Slave-Instanzen erzeugt und gestartet sind, werden diese von der Master-Instanz und einem darauf laufenden zusätzlichen Programm (AmiMaster) konfiguriert. Bei der Konfiguration wird das Shared File System per Netzlaufwerk auf dem Slave von der Master- Instanz eingebunden. Dadurch haben die Master- und die Slave-Instanzen eine

11 gemeinsame Konfiguration. Unter anderem wird damit der Zugriff auf die gemeinsame Datenbank der Master-Instanz konfiguriert, so dass Master und Slave auf der gleichen Datenbasis arbeiten können. In dem Shared File System steht die IP-Adresse und der benötigte Port des Master für die Datenbankverbindung. Außerdem wird beim Erzeugen einer Slave-Instanz die Java Applikation AmiSlave automatisch gestartet. Mit dieser Komponente kann der Master per RMI-Methodenaufruf die Instanz konfigurieren und anschließend den Enfinity Applicationserver einer Slave-Instanz starten. Ebenso übernimmt die Applikation das Sammeln und Senden von Multicastnachrichten, diese Funktionalität wird für den Betrieb eines Enfinity Clusters benötigt. Der Master holt in regelmäßigen Zeitabständen von jeder Slave-Instanz die gespeicherten Multicastnachrichten und verteilt diese an jede Slave-Instanz per RMI-Aufruf. Dieser Mechanismus wird benötigt, da sich die verschiedenen Server eines Enfinity Clusters in der Regel in einem Netzsegment befinden. Dort werden gesendete Multicastnachrichten von jedem Teilnehmer in dem Netzsegment empfangen. Da die Instanzen des Applicationserver Clusters aus diesem Szenario sich nicht in einem physikalischen Netzsegment befinden wird mit den Java Applikationen AmiMaster und AmiSlave der Multicastmechanismus nachgebildet. Ein AmiSlave sammelt die abgehenden Multicastnachrichten eines Applicationservers in einer Slave-Instanz. Der AmiMaster holt von jeder Slave-Instanz die abgefangenen Nachrichten und sendet diese an die anderen Slaves. Die Herausforderungen dieses Szenarios liegen in den Multicastnachrichten und den dynamischen IP-Adressen und DNS-Bezeichnungen. Enfinity nutzt zur Kommunikation in einem Cluster Multicastnachrichten. Diese können aber in EC2 nicht zwischen Instanzen ausgetauscht werden. Es ist zusätzlicher Entwicklungsaufwand nötig, diese Nachrichten zwischen allen Instanzen verfügbar zu machen. In einem Prototyp konnte gezeigt werden, dass dies grundsätzlich möglich ist. Daneben wird beim Starten einer Instanz dieser dynamisch eine IP-Adresse bzw. DNS- Bezeichnung zugeteilt. Daraus resultieren zahlreiche nötige Anpassungen in Konfigurationsdateien bevor Enfinity gestartet werden kann. Basierend auf diesen Erkenntnissen soll im Folgenden kurz ein Konzept vorgestellt werden, wie unter Nutzung der Amazon Cloud Infrastruktur höchstmögliche Verteilbarkeit, Skalierbarkeit und Ausfallsicherheit von Enfinity Suite 6 erreicht wird. Es orientiert sich an der vorgestellten Mehr-Schichten-Architektur von Enfinity. Jede Komponente ist in einem AMI gespeichert. Für die Web Server (WS) und die Application Server (AS) wird jeweils das gleiche AMI verwendet. Jedoch werden, je nach Bedarf, mehrere Instanzen davon erzeugt. Für die erzeugten Instanzen können Security Groups angelegt werden, welche die Instanzen vor unberechtigtem Zugriff schützen. Folgende Komponenten bzw. AMI werden benötigt, siehe dazu auch: Elastic Load Balancing (AWS): Für die Lastverteilung der eingehenden Anfragen an das Anwendungssystem wird der Dienst Elastic Load Balancing von Amazon genutzt. Der Loadbalancer verteilt eingehende Anfragen an eine variable Anzahl von Instanzen. In diesem Falle an die Instanzen mit den Web Servern (WS1 bis WSn). Web Server (WS): Für die Web Server wird ein AMI benötigt. Mit dem Amazon Dienst Auto Scaling werden von dem Image, je nach Ressourcenanforderungen, die benötigten Instanzen erzeugt. Es erfolgt also eine horizontale Skalierung der Web Server Komponente. Um eine erhöhte Ausfallssicherheit zu gewährleisten, kann Auto Scaling so konfiguriert werden, dass mindestens zwei Instanzen jederzeit

12 verfügbar sind, auch wenn der Ressourcenbedarf geringer ist. Skalierung auf dieser Ebene kann ohne Änderungen an Enfinity automatisch ablaufen. Auto Scaling arbeitet mit dem Dienst Elastic Load Balancing zusammen, so dass neu erzeugte Instanzen zur Lastverteilung berücksichtigt werden, sobald diese von Auto Scaling gestartet wurden. Application Server (AS): Auch hier wird ein AMI benötigt, in dem sich der Application Server mit der Anwendung Enfinity Suite befindet. Ebenso wird auf dieser Ebene horizontal mit dem Dienst Auto Scaling die Leistung dem Bedarf angepasst, also skaliert. Eine Skalierung auf dieser Ebene erfordert weitere Aktionen. Die Application Server Instanzen müssen den Web Servern bekannt gemacht werden, damit diese ihren internen Lastverteilungsmechanismus anwenden können. Das kann mit dem AMI Controller erreicht werden. Dieser überwacht die Anzahl an Application Server Instanzen und teilt bei auftretenden Änderungen die neue Konfiguration den Web Servern mit. Dies kann konkret durch die Anpassung einer Konfigurationsdatei in den Web Servern realisiert werden. Datenbank: Die Oracle Datenbank befindet sich in einem separaten AMI. Es wird auch nur eine Instanz davon erzeugt. Horizontales Skalieren einer Datenbank wird bei Oracle mittels Real Application Cluster (RAC) ermöglicht. Jedoch ist dies nach [Ora09] derzeit in EC2 nicht möglich, so bleibt auf dieser Ebene nur die vertikale Skalierung. AMI Controller mit Shared File System: Der AMI Controller wird benötigt, um die dynamische Zuteilung der IP-Adressen für die Instanzen zu verwalten. Folgende Funktionen muss der Controller ausführen: o IP-Adresse des AMI Controller mit Shared File System den Application Servern bekannt machen. o IP-Adresse der Datenbank Instanz den Application Servern bekannt machen. o Verwalten der Application Server Prozesse (starten, neu starten). o IP-Adressen der Application Server den Web Servern bekannt machen. Darin ist ebenso das Shared File System (SF) enthalten, auf welches alle Application Server Zugriff haben müssen und zum Beispiel von den Instanzen per Netzlaufwerk eingebunden werden kann.

13 Abb. 7 Idealtypisches Szenario Die zuvor beschriebenen Probleme mit der dynamischen Zuteilung von IP-Adressen lässt sich mit dem beschriebenen AMI Controller lösen. Dieser muss die IP Adressen der einzelnen Instanzen ermitteln können und den Komponenten mitteilen, die diese benötigen. Zur Lösung des Problems des Multicast-basierten Nachrichtenaustauschs zwischen den Application Server Instanzen könnte der Multicastmechanismus durch zusätzliche Programme nachgebildet werden. Dies könnte auch mit dem AMI Controller umgesetzt werden, der eintreffende Nachrichten eines Application Servers an die anderen weiterleitet. Alternativ ist die Nutzung von Warteschlangen denkbar. Ein Application Server legt eine Nachricht, die an die anderen Server gesendet werden soll, in eine Warteschlange. Der AMI-Controller sendet jede Nachricht in der Warteschlange an die anderen Application Server. Dazu kann Amazon Simple Queue Service (SQS) genutzt werden. Mit dem vorgestellten Konzept ist auf jeder Schicht der Architektur von Enfinity die Anpassung der Ressourcen nach Bedarf durchführbar. Ebenso kann eine hohe Ausfallsicherheit mit der Amazon Cloud Infrastruktur erreicht werden. Durch Verteilung der benötigten Instanzen auf mehrere Availability Zones in einer Region können Störungen beim Cloud-Provider Amazon abgefangen werden. Zusammenfassung und Ausblick Cloud Computing bietet verschiedene Arten von Ressourcen, die bei Bedarf schnell, gezielt und dem Problem entsprechend beschafft und genutzt werden können. Änderungen an den Infrastrukturressourcen können sehr leicht automatisch (z. B. Amazon Auto Scaling) oder manuell (z. B. Amazon Management Console, Kommandozeilenwerkzeuge) dem Bedarf entsprechend vorgenommen werden.

14 Der Betrieb von Enfinity in Verbindung mit einer flexiblen Cloud-basierten Infrastruktur, wie der Amazon Cloud Infrastruktur, ermöglicht die schnelle und gezielte Ressourcenanpassung der einzelnen Schichten des Anwendungssystems nach dem tatsächlichen Bedarf (z. B. Weihnachtsgeschäft, Werbeaktionen, etc.). Je besser die Architektur des Shopsystems die Anforderungen, die speziell die Nutzung der horizontalen Skalierbarkeit ermöglichen, erfüllt, um so einfacher ist sein Betrieb mittels Infrastructure as a Service. Für einen tatsächlichen Betrieb eines Shopsystems wie der Enfinity Suite mittels Infrastructure as a Service muss vor allem das Sicherheitskonzept eingehend untersucht werden. Bedenklich ist zudem, dass Standards für die Portierbarkeit von Anwendungen oder Diensten zwischen verschiedenen Anbietern fehlen. Eine AMI von Amazon kann zum Beispiel derzeit nur bei diesem Anbieter laufen. Spannend wird die zukünftige Entwicklung von Cloud Computing sein und ob ein nachhaltiger Paradigmenwechsel im Umgang mit IT-Ressourcen tatsächlich eingeleitet wird. Das Potential ist vorhanden. Quellen [BI09] BitKom: Cloud Computing, BITKOM-Leitfaden [DJM05] Dostal, W; Jeckle, M.; Melzer, I.: Service-orientierte Architekturen mit Web Services : Konzepte - Standards Praxis, [Hö09] Höschl, P.: Leitfaden für Shop Einsteiger, [Int08a] Intershop Communications AG - Technical Training: Enfinity Suite 6 - System Administration, Version: April 8, [Int08b] Intershop Communications AG - Technical Training: Enfinity Suite 6 - Technical Introduction, Version: Juli 25, [Ko10] Kommalapati, H.: Windows Azure Platform for Enterprises, MSDN Magazin, 02/2010, S [Me10] Messmer, E.: Security of virtualization, cloud computing divides IT and security pros, ( ). [MeGr09] Mell, P.; Grance, T.: The NIST Definition of Cloud Computing, ( ) [Mi10] Microsoft: Szenarien Windows Azure, o6 ( ) [Mur08] Murty, J.: Programming Amazon Web Services, [PSB09] Plummer, D. C.; Schmith, D. M.; Bittman, T. J. u.a.: Five Refining Attributes of Public and Private Cloud Computing, Gartner [Ree09] Reese, George: Cloud Application Architectures, 2009 [SKBa08] Stahl, E.; Krabichler, T.; Breitschaft, M. u.a.: Erfolgreich im elektronischen Handel, [SKBb09] Stahl, E.; Krabichler, T.; Breitschaft, M. u.a.: e-commerce-leitfaden, ibi research, [SM09a] Sun Microsystems Inc.: Kickstart Your Transition to the Cloud, [SM09b] Sun Microsystems, Inc.: Introduction to Cloud Computing Architecture, _0.jsp/, ( ). [Som07] Sommerville, Ian: Software Engineering, 2007.