Cloud Computing erobert längst die Herzen und Budgets von Managern und IT-Bereichen. Kommt da wirklich etwas Neues, oder etikettieren wir nur wieder einmal Produkte und Initiativen um? Ist Cloud Computing mehr als nur die Verlängerung der Innovationen rund um Virtualisierung, Standardisierung und Automatisierung? Wir lernen in diesem Artikel die Architekturklassen ACID und BASE zu unterscheiden, warum und wie uns das CAP-Theorem als Architekten eindeutige Entscheidungen abverlangt und schauen in die Wiege des Cloud Computings sowie hinter die Kulissen großer Websites wie Amazon und Google.

1. magazinJava • Architekturen• SOA • Agile
Geo-Tutorial: Laufen im Kreis »37
www.javamagazin.de
Cloud Computing
Clouds jenseits des Standards
mit BASE »76
Employer Branding
Der Kampf um die besten
Fachkräfte »90
CD-INHALT
Österreich €9,80 Schweiz sFr 16,80Deutschland €8,50 5.2010
Alle CD-Infos ab Seite 3
Neue Sprachen
für die JVM
Video von der
W-JAX 2009
in voller Länge
EuropEan HEadquartErs - LangEn, gErmany
LifEray gmbH — robErt - boscH - strassE 11, 63225 LangEn, gErmany
tEL: +49 - (0) 6103 - 3018570 • fax: +49 - (0) 6103 - 3018571
now get the best of both worlds.
Liferay Enterprise Edition gives you all the benefits of open source with the stability,
security, and reliability of an enterprise subscription.
and with version 5.1, get the latest in soa, social networking, and collaboration
technology, all at a fraction of the cost of oracle®
or ibm®
.
for more information, email us at sales@liferay.com.
you spoke. We listened.you spoke. We listened.y
introducing Liferay Enterprise Edition.
Liferay 5.1 Enterprise Edition
Maintenance Subscription
2.950 Eur/server/year
Platinum Support (24x7)
19.950 Eur/server/year
compare oracle®
Webcenter suite: 125.000 Eur / processor, support 27.500 Eur / yr, as of 6 / 2008
CD
inkl.
JavaMagazin5.2010Build-ToolsimVergleichSilverlightfürJavaTwittermitLiftGoogleMapsundAndroidCloudComputing
JAVAMag
GoogleMapsundAndroid
Standortbestimmung »101
TwittermitLift
MarkeEigenbau »52
Silverlight fürJava
Gehtdas? »45
Alle Infos im Heft
Build-Tools
Maven, Ant und Gradle
im Vergleich »60
„Maven 3 wird das beste Maven”
Interview mit Jason van Zyl »70
WEITERE INHALTE
Gradle 0.8
Maven 2.2.1
OpenLayers 2.8
Moonlight
Ant 1.8
EclEmma
Apache UIMA 2.3
Apache PDFBox 1.0

2. Cloud BASE:InternetanwendungenjenseitsderStandards
76 www.JAXenter.dejavamagazin 5|2010
ittwoch,der29.Juli2000–wel­
che Erinnerungen verknüpfen
Sie mit diesem Tag? Vielleicht
war es ein schöner Sommertag, den Sie
mitPartner(in),Familie,Freundenver­
brachthaben,vielleichtwaresabereher
düsterundgewittrigodereshatwieaus
Eimerngeschüttet...
Der 29. Juli 2000 war jedenfalls
ein geschichtsträchtiger Tag für das
Web. Beim ACM Symposium on the
Principles of Distributed Computing
(PODC)hatEricBrewerandiesemTag
eine Keynote mit dem Titel „Towards
Robust Distributed Systems“ gehalten
[1]. In diesem Vortrag hat er die Emp­
fehlung ausgesprochen, im Umfeld
zunehmend verteilter Systeme und
webbasierter Anwendungen bei den
BemühungenumDatenkonsistenzeine
gewisse Umsicht und Vorsicht walten
zulassen.DennbeiverteiltenSystemen
stehenAvailabilityundConsistencyder
DateninKonkurrenz.
InseinemVortragführteEricBrewer
dieUnterscheidungzwischenACIDund
BASE ein. Dabei steht ACID für Atomi­
city,Consistency,IsolationundDurabi­
lity–dieseAbkürzungistimUmfeldvon
Datenbanken und Transaktionen bes­
tens eingeführt. Die Abkürzung BASE
bedeutet Basically Available, Soft-state
und Eventually consistent. In der Ge­
genüberstellung von Säuren und Basen
verbirgt sich gleichzeitig ein eleganter
Hinweis auf die Verwendung der Ab­
kürzungen.Dahinterstehennichtscharf
abgegrenzteoderauchnurabgrenzbare
Jumping Jack Flash
Cloud Computing erobert längst die Herzen und Budgets von Managern und
IT-Bereichen. Kommt da wirklich etwas Neues, oder etikettieren wir nur wie-
der einmal Produkte und Initiativen um? Ist Cloud Computing mehr als nur die
Verlängerung der Innovationen rund um Virtualisierung, Standardisierung und
Automatisierung? Wir lernen in diesem Artikel die Architekturklassen ACID und
BASE zu unterscheiden, warum und wie uns das CAP-Theorem als Architekten
eindeutige Entscheidungen abverlangt und schauen in die Wiege des Cloud
Computings sowie hinter die Kulissen großer Websites wie Amazon und Google.
von Lothar Wieske
Teil 1: Amazon Web Services: Flagg-
schiff des Cloud Computings
Teil 2: Elastic Compute Cloud: Darf
es noch ein Server mehr sein?
Teil 3: BASE: Internetanwendun-
gen jenseits der Standards
Artikelserie

3. CloudBASE:InternetanwendungenjenseitsderStandards
www.JAXenter.de
Anwendungsklassen–vielmehrumrei­
ßenbeideKonzepteeinKontinuumvon
Abwägungen und Entscheidungen. In
diesem Kontinuum muss der Architekt
denpH-Wertseiner„Lösung“zwischen
Availability (BASE) und Consistency
(ACID)einpegeln.
EricBrewerfassteinseinemVortrag
gemeinsame Erkenntnisse und Erfah­
rungen aus der Arbeit einer Reihe von
Menschenderakademischenundindus­
triellen Welt zusammen. Zu jener Zeit
war er zum einen Professor an der UC
BerkeleyundzumanderenGründervon
Inktomi Corporation. Inktomi hatte als
Ausgründung der UC Berkeley damals
etwa 700 Mitarbeiter und baute Search
EnginesundWebCaches.ImDezember
2002wurdeInktomivonYahoo!gekauft.
Auf der eigentlichen Schlüsselfolie
desVortragsschalteteEricBrewerjedoch
von zwei auf drei um. Denn in Gänze
geht es um drei systemische Merkmale:
Availability, Consistency und Partition
Tolerance.Undkurzundtrockenhießes
dann:„Youcanhaveatmosttwoofthese
properties for any shared-data system.“
DieseBeziehungistimJahr2000alsBre­
wer-Hypothese (Brewer Conjecture) in
die Annalen eingegangen. Zwei Jahre
später haben dann Seth Gilbert und
Nancy Lynch vom MIT die Hypothese
formalbewiesen[2],unddamitentstand
eigentlich erst im Jahr 2002 das Brewer-
TheoremoderauchCAP-Theorem,weil
Consistency, Availability und Partition
ToleranceinBeziehunggesetztwerden.
Heute stehen Websites wie Amazon
und Google genau in der Nachfolge der
grundsätzlichen Abwägung zwischen
AvailabilityundConsistency.Deswegen
soll es in diesem Artikel um einige der
PhänomeneimUmfelddesBrewer-The­
orems und im Vorfeld des Cloud Com­
putingsgehen.
Wirtschaftliche Bedeutung des
CAP-Theorems
Die Aberdeen Group hat Ende 2008 ei­
ne interessante Untersuchung mit dem
vielsagenden Titel „Customers are Won
or Lost in One Second“ veröffentlicht
[4]. Darin wurden 160 Organisationen
hinsichtlich ihrer Best Practices bei der
Optimierung der Antwortzeiten ihrer
unternehmenskritischen Webanwen­
dungen befragt. Die Kernaussagen die­
serUntersuchungwaren:
… business performance (as measured■■
by customer satisfaction, conversions,
etc.)beginstosufferat5.1secondsofde-
layinresponsetimesofwebapplications
…
… only one second of additional delay■■
intheresponsetimesofwebapplication
could significantly impact some of the
topbusinessgoals…
…onesecondofdelayinreponsetimesof■■
web applications can impact customer
satisfactionbyupto16 %…
MitihrenEinsichtenundZahlenhatdie
Aberdeen Group einen wichtigen Im­
puls für die gemeinschaftliche Arbeit
vonBusinessanalystenundtechnischen
Architektengegeben.Gemeinsamsoll­
ten beide Funktionsträger fachliche
Mengengerüste und technische Platt­
formunterstützung mit den Geschäfts­
zielen (bspw. Kundenzufriedenheit)
vordemHintergrundvonKosten,Um­
satz und Gewinn ausbalancieren. Klar
wird aus den angesprochenen Zahlen
undEffekten,dassdieGeschäftsmodel­
le von Amazon (Internethandel) und
Google (Internetwerbung) auf Availa­
bility fokussieren, und das hat Auswir­
kungen in den Infrastruktur­en dieser
Websites.
Es gibt übrigens für die Auswir­
kungen verzögerter Antwortzeiten bei
Amazon und Google interessante Zah­
len [4]. Amazon hat herausgefunden,
dass jeweils 100 Millisekunden Verzö­
gerung zu einem einprozentigen Um­
satzrückgang führen. Untersuchungen
von Google weisen für zusätzliche 500
MillisekundenbeiderGenerierungvon
Suchergebnisseneinenzwanzigprozen­
tigenRückgangderAnfragennach.
Technische Bedeutung des
CAP-Theorems
Bisher sind die Konzepte Availability,
Consistency und Partition Tolerance
eher informell in Erscheinung getreten.
Gerade vor dem Hintergrund zitierter
Beweisführungen ist das natürlich pro­
blematisch,weildasmathematischeRe­
sultat auf präzise und formale Definiti­
onen aufbaut. Keine Angst, es wird jetzt
nicht unnötig kompliziert und es geht
nicht um die Wiedergabe der formalen
Beweisführung in ihren Tiefen. Aber es
geht um ein Verständnis wichtiger Ent­
wicklungslinien in der konzeptuellen
DurchdringungvonKonsistenz.
Brewer deutet ein Kontinuum Avail­■■
ability/Consistencyanundformuliert
dasCAP-Theorem
GilbertundLynchbeweisendasCAP-■■
Theorem und unterscheiden Strong/
WeakConsistency
Abb. 1: CAP-Theorem
Anzeige

4. Cloud BASE:InternetanwendungenjenseitsderStandards
78 www.JAXenter.dejavamagazin 5|2010
Vogels (Amazon) verdeutlicht Even­■■
tualConsistencyalsUnterkonzeptvon
WeakConsistencyunddieBedeutung
für Amazon Dynamo als Storage Sys­
teminderUmsetzungbeiAmazon
Pritchett(eBay)entwickeltConsisten­■■
cyPatternszurschrittweisenOptimie­
rung von Availability bei gleichzeiti­
ger Relaxierung von Consistency im
ÜbergangvonACIDzuBASE
Gilbert und Lynch sprechen eigent­
lich nicht von Consistency, sondern
von Atomic Consistency. Sie fordern
eine totale Ordnung aller Operatio­
nen, sodass sie wie eine Perlenkette
auf der Zeitschnur aufgefädelt werden
können. Und dann soll jede Leseope­
ration, die nach einer Schreiboperati­
on beginnt, entweder den Wert dieser
oder einer späteren Schreiboperation
liefern. Für Continuous Availability
fordern Gilbert und Lynch, dass jeder
Request an das System eine Response
liefern muss. Für die Präzisierung von
Partition Tolerance wird dem Netz­
werk zunächst der Verlust beliebig
vieler Nachrichten von einem Kno­
ten zu einem anderen Knoten erlaubt.
Partitionierung (in Komponenten)
bedeutet dann, dass alle Nachrichten
von Knoten in einer Komponente zu
Knoten in einer anderen Komponen­
te verloren gehen. Und mit Partition
Tolerance macht dieser Verlust von
Nachrichten eigentlich nichts weiter
aus. Mit der Begriffsbildung Atomic
Consistency werden die Gemeinsam­
keiten und Unterschiede zu „A“ und
„C“ elegant herausgearbeitet und neu
gefasst. Denn Database Atomicity
und Database Consistency beziehen
sich auf Transaktionen als Operati­
onsfolgen, während im Kontext des
CAP-Theorems mit Atomic-Consis­
tency-Eigenschaften einer einzigen
Request-/Response-Operation be­
schrieben werden.
Auf dieser Grundlage beweisen
GilbertundLynchdannihreerstenbei­
den Theoreme: „It is impossible in the
... network model to implement a read/
write data object that guarantees the …
properties ... Availability (and) Atomic
consistencyinallfairexecutions(inclu­
ding those in which messages are lost.“
Für die Ellipse vor dem Netzwerkmo­
dell steht beim ersten Theorem „asyn­
chronous“ und beim zweiten Theorem
„partiallysynchronous“.Beim„partially
synchronous Network“ verfügen die
Knoten im Netzwerk noch über Timer.
Im Gedankengang des Artikels spielt
die Unterscheidung der beiden Netz­
werktypeneineRolle,indiesemArtikel
werden wir sie jedoch übergehen. We­
sentlich scheint für die hiesigen Belan­
ge der Abschnitt mit der Überschrift
„Weaker Consistency Conditions“. Da­
mitwurdedietiefereBeschäftigungmit
EventualConsistencyalspraxisfähigem
Ausschnitt von Weak Consistency ein­
geläutet.
Eventual Consistency bei
Amazon
Werner Vogels, CTO bei Amazon, ver­
tieftimArtikel„EventuallyConsistent“
fürACMQueueimDezember2008die
Rolle von Amazon Dynamo für die
Infrastruktur [5]. Im Untertitel stellt
er seinen Ausführungen voran: „Buil­
ding reliable distributed systems at a
worldwide scale demands trade-offs
– between consistency and availabili­
ty“. Bei Amazon, Google & Co. gibt es
ein Credo: Fehler sind der Normalfall.
DahinterverbirgtsichnichtetwaDefä­
tismus oder Sarkasmus. Vielmehr wird
aus dieser Einsicht ein klarer Architek­
tur- und Designauftrag abgeleitet. He­
runtergebrochen auf die Themenstel­
lungdiesesArtikelsheißtdas:Network
Partitions sind sicher – deswegen kann
es Consistency und Availability nicht
gleichzeitiggeben.
Abhängigdavon,wasdieServerseite
bietet,mussderEntwickleraufClientsei­
tedamitumgehen.WenndieServerseite
den Schwerpunkt auf Consistency legt,
wird es Abstriche im Bereich von Avail­
ability geben, und der Entwickler wird
StrategienentwickelnmüssenfürDaten,
die zwar geschrieben werden müssen,
aber nicht geschrieben werden können.
Wenn die Serverseite der Availability
den Vorrang gibt, wird es Abstriche im
BereichvonConsistencygebenundder
Entwickler wird Strategien entwickeln
müssen, ob und wie er gegebenenfalls
auchmitleichtüberaltertenDatenarbei­
tenkann.
FürdenclientseitigenUmgangmüs­
sen zunächst einmal die unterschied­
lichen Arten und Eigenschaften von
ConsistencygeordnetundinBeziehung
gesetzt werden. Bei Strong Consistency
garantiert das System, dass nach einer
Schreiboperation alle nachfolgenden
Leseoperationen diesen geschriebenen
Wert sehen. Bei Weak Consistency ga­
rantiert das System nach einer Schreib­
operationerstnachdemEintreteneiner
ReihevonBedingungen,dassallenach­
folgenden Leseoperationen diesen ge­
schriebenen Wert sehen. Der Zeitraum
zwischen dem Abschluss der Schreib­
operation und dem Eintreten aller Be­
dingungenwirddabeialsInconsistency
Window bezeichnet. Eventual Consis­
tency stellt eine Sonderform von Weak
ConsistencydarindemSinne,dassohne
weitere Schreiboperationen letztend­
lich alle Leseoperationen diesen zuletzt
geschriebenen Wert sehen. Wenn keine
Fehler eintreten, kann die maximale
Größe der Inconsistency Window auch
aus unterschiedlichen Kenngrößen des
Systems errechnet und angegeben wer­
den.
Wahrscheinlich gestaltet sich Even­
tual Consistency auch deswegen etwas
sperrig, weil es zumindest deutsche In­
formatiker etwas schaudert, wenn sie
einfachihremintuitivenSprachgebrauch
folgen.Dannheißt„eventual“eheretwa­
ig und möglich und nicht letztendlich
undschließlich.DasSystemrauschtalso
nichtineinnichtdeterministischesNir­
wana von dannen, sondern folgt einer
zeitlichenEntwicklungimSinnevont->
∞.ZusätzlichbenenntVogelsnocheini­
geVariationenundKombinationenvon
EventualConsistency:
CausalConsistency■■
Read-your-writesConsistency■■
SessionConsistency■■
MonotonicreadConsistency■■
MonotonicwriteConsistency■■
Auf der Serverseite haben Vogels und
seineMitarbeitermitAmazonDynamo
ganzeUmsetzungsarbeitgeleistet.Ama­
zon Dynamo ist ein Key/Value Storage
System, das von vielen internen Diens­
tengenutztwird.JedernutzendeDienst
von Dynamo bekommt seine eigene

5. Anzeige

6. Anzeige

7. CloudBASE:InternetanwendungenjenseitsderStandards
www.JAXenter.de 81javamagazin 5|2010
Instanz, die möglicherweise mehrere
Rechenzentren umspannt. Entwurfs­
zielvonDynamoistdieMöglichkeitder
Kontrolle seines Verhaltens entlang der
Vorgaben der systemischen Merkmale
der Gesamtanwendung. Der Architekt
kann sich seine Dynamo-Instanz damit
so parametrieren, dass er die Entwick­
lungsvorgabenhinsichtlichAvailability,
ConsistencyundKostenerfüllt.
Eventual Consistency bei eBay
Dan Pritchett, Technical Fellow bei
eBay, entwickelt im Artikel „BASE: An
ACID Alternative“ für ACM Queue im
Juli 2008 einige Consistency Patterns,
die über relaxierte Consistency zu op­
timierter Availability führen [6]. Der
Untertitel macht die Motivation klar:
„In partitioned databases, trading so­
meconsistency for availabilitycanlead
to dramatic improvements in scalabi­
lity“.
Es gibt zwei grundsätzliche Strategien
fürdasSkalierenvonDatenbanken:ver­
tikaleundhorizontaleSkalierung.Verti­
kale Skalierung hebt die Datenbank auf
leistungsfähigereHardware.Horizonta­
leSkalierungerlaubtmitDatabaseNor­
malization (Zerlegung in unterschied­
liche Spalten) und Database Sharding
(Zerlegung in unterschiedliche Zeilen)
zwei Taktiken, die miteinander kom­
biniert werden können. Offensichtlich
erfordert eine Strategie der horizonta­
len Skalierung grundsätzlich die Eigen­
schaftPartitionTolerance.NachBrewers
Theorem müssen deswegen für die Ei­
genschaftenConsistencyundAvailability
Abwägungen stattfinden und Entschei­
dungengetroffenwerden.
Pritchett illustriert einige Consis­
tency-Überlegungen an einem stark
vereinfachten Schema mit zwei Ta­
bellen für ein Auktionssystem. Die
Tabelle User enthält grundlegende
Benutzerinformationen und jeweilige
SummenbeträgefürKaufundVerkauf.
Die Tabelle Transaction enthält für je­
de Transaktion ihren Einzelbetrag und
setzt die IDs für Käufer und Verkäufer
in Beziehung. Mit jedem Kauf/Verkauf
wird eine Zeile in die Tabelle Transac-
tion eingefügt und in der Tabelle User
werden die entsprechenden Summen
aktualisiert:
Begintransaction
Insertintotransaction(xid,seller_id,buyer_id,
amount);
Updateusersetamt_sold= ...whereid=$seller_id;
Updateusersetamt_bought=...whereid=$buyer_id;
Endtransaction
Möglicherweise kann das Consistency
Constraint relaxiert werden, dass beide
TabellenUserundTransactiondasfinan­
zielle Ergebnis sofort und übereinstim­
mendwiedergeben(müssen).Wennzu­
gelassenwird,dassdieUser-Tabellenmit
ihren Summenbeträgen erst in einem
zweiten Schritt verzögert aktualisiert
werden, dann wird die Consistency der
Tabellen User und Transaction kurzzei­
tig geopfert und verzögert wiederher­
gestellt. So entsteht folgende gesplittete
Transaktion:
Begintransaction
Insertintotransaction(id,seller_id,buyer_id,
amount);
Endtransaction
Begintransaction
Updateusersetamt_sold= ...whereid=$seller_id;
Updateusersetamt_bought=...whereid=$buyer_id;
Endtransaction
Nun sind die Updates und damit auch
die Consistency für die Tabellen User
und Transaction entkoppelt. Die weite­
ren Transformationen sind im Artikel
detaillierter beschrieben, hier soll eine
Skizze der zugrunde liegenden Ideen
genügen. Im nächsten Schritt kommt
Persistent Messaging zum Einsatz, um
dieUpdatesderTabellenUserundTran-
sactionauchtransaktionellabzusichern.
Die bisherige Lösung ist bislang nur
dann fachlich korrekt, wenn die Sum­
menbeträge letztlich nur als Schätzun­
genverstandenwerden,dieauchdieeine
oderandereTransaktionauslassen.
Eine technisch korrekte Umsetzung
genauer – und nicht nur geschätzter
– Summenbeträge könnte von einer ei­
genständigen Komponente für Persis­
tent Messaging ausgehen. Dann käme
jedoch über 2PC (Two Phase Commit)
eine Kopplung von Database und Mes­
sagingzustande,diedieEffektederEnt­
kopplung der Updates in den Tabellen
User und Transaction kannibalisieren
würde.
Die Verfügbarkeit errechnet sich
aus dem Produkt der Verfügbarkeiten
von Komponenten. Eine Transaktion,
die zwei Datenbanken in einem 2PC
einbindet, hat bei einer Verfügbarkeit
der Einzeldatenbanken von 99,9 % ei­
ne Verfügbarkeit von nur noch 99,8 %.
Die reduzierte Verfügbarkeit von
0,1 % bedeutet in der Umrechnung auf
den Monat 43 Minuten weniger. Also
liegen die Nachrichten genau wie die
Tabellen User und Transaction in der­
selben Datenbank, um ohne 2PC aus­
kommen zu können und damit keine
AuswirkungenhinsichtlichAvailabili­
ty zu haben.
Nun gibt es zwei Verarbeitungspro­
zesse zum Einstellen einer Transakti­
on in die Tabelle Transaction und zum
Nachziehen der Summenbeträge in der
Tabelle User. Der Prozess zum Nach­
ziehen der Summenbeträge liest Nach­
richten aus und verändert Werte für die
Summenbeträge. Eigentlich läuft das
wieder auf eine 2PC-Situation hinaus.
FürdieLösungdieserProblematikwird
das Konzept einer idempotenten Ope­
rationbenötigt.Diesekanneinmaloder
mehrere Male mit gleichem Resultat
angewendet werden. Eine idempotente
Operation erlaubt deswegen auch par­
tielle Fehler. Denn wenn sie wiederholt
ausgeführtwird,ändertdasdenEndzu­
stand des Systems nicht in unzulässiger
Weise.NunsindaberUpdatesimRegel­
fallnichtidempotent.
Im Beispiel der Auktion muss also
eine Buchführung (Tabelle) her, die
genau mitschreibt, welche Updates
bereits erfolgreich durchgeführt wor­
den sind und welche noch ausstehen.
Wenn diese Tabelle ein erfolgreiches
Update verzeichnet, wird die zuge­
hörige Nachricht als Arbeitsauftrag
gelöscht. Dieses Vorgehen ist tolerant
gegenüber partiellen Fehlern, kommt
aber ohne 2PC-Mechanismen und da­
mitverschlechterteAvailabilityaus.Im
Artikel von Pritchett werden weitere
Ideen zur Entkoppelung von Opera­
tionen (Ordnung von Nachrichten
und Transaktionen) vorgestellt, die im
Zusammenspiel in einer optimierten
Availability auf Kosten einer relaxier­
ten Consistency resultieren. BASE mit
dem Konzept der Eventual Consisten­

8. Cloud BASE:InternetanwendungenjenseitsderStandards
82 www.JAXenter.dejavamagazin 5|2010
cybietethierfüreinenleistungsfähigen
Arbeits-undDenkansatz.
Bedeutung in der und für die
Praxis
Bei Amazon, Google und Yahoo! sowie
vielen anderen sind Infrastrukturen
entstanden, die die soeben vorgestellten
IdeenimUmfeldvonBASEundEventual
Consistency aufnehmen, weiterentwi­
ckeln und umsetzen. Die Systeme Ama­
zon Dynamo, Google File System, Goo­
gle Bigtable und Yahoo! PNUTS sind in
wissenschaftlichen Veröffentlichungen
vorgestelltworden.UnddieseVeröffent­
lichungen haben auch zu Nachbauten in
der Open-Source-Welt geführt. Es gibt
also unterschiedliche Zugänge für eine
praktischeVertiefungdieserThemenund
indennächstenAbsätzensollendiepro­
minentenVertreterimSinneeinerersten
Orientierung kurz vorgestellt werden.
Open-Source-SystemefüreigeneExperi­
mentesindbeispielsweiseCassandra,Dy­
nomite,HBase,Hypertable,Voldemort.
Amazon Dynamo
VielfachzitiertsinddieEinsatzbedingun­
genvonApacheDynamo:„...evenifdisks
arefailing,networkroutesareflapping,or
datacentersarebeingdes­troyedbytorna­
dos.…“.ApacheDynamoistein„highly
available key-value storage system“. Dy­
namo besteht aus einem Netz von voll­
ständiggleichberechtigtenRechnern.Es
gibt keine zentrale Steuerung und jeder
KnotenkannjedeAufgabewahrnehmen.
DamitskaliertdieArchitekturvonAma­
zonDynamoineinfachsterWeisedurch
das Hinzufügen weiterer Knoten. Um
diegewünschtenEigenschaftenzuerrei­
chen, werden eine Reihe von bekannten
Verfahren genutzt. Consistent Hashing,
Gossip,HintedHandoff,SloppyQuorum
und Vector Clocks sind relevante Stich­
worte, die zeigen, dass für ein vertieftes
VerständnisvonAmazonDynamoeinige
Vorarbeitenerforderlichsind[7].
Google File System und
Bigtable
Google hat mit dem Google File System
(GFS) ein verteiltes Dateisystem gebaut,
das für große Dateien mit mehreren GB
optimiert ist. Inhalte werden nur selten
gelöscht oder überschrieben – sie wer­
den aber oft mit hohen Durchsatzanfor­
derungen gelesen – außerdem werden
oft Inhalte angehängt. Ein GFS Cluster
besteht aus einem Master und vielen
Chunk-Servern. Mehrere hundert oder
tausendChunk-ServerspeichernChunks
als64 MBgroßeAusschnittevonDateien.
Der Master erhält alle Anfragen für eine
DateiundliefertalsAntwortdiedazuge­
hörigen Chunk-Server. Der Client holt
danndirektvondenChunk-Serverndie
benötigten Chunks für seinen Dateizu­
griff.GoogleBigtableisteinperformanter
skalierbarerData­storeaufderGrundlage
einer „sparse distributed multi-dimen­
sional sorted map“. Er baut u. a. auf dem
GoogleFileSystemaufundliegtu. a.der
GoogleAppEnginezugrunde[8],[9].
Yahoo! PNUTS
PNUTS (Platform for Nimble Universal
TableStorage)ist„amassivelyparalleland
geographically distributed data­base sys-
tem“fürdieWebanwendungenbeiYahoo!.
PNUTSwurdefürdenBetriebinmehre­
renundübermehrereRechenzentrenent­
worfenundbietetdafür„per-recordtime­
lineconsistency“,d. h.alleReplikeneines
RecordswerdeninderselbenReihenfolge
aktualisiert. Recordssindversioniert–ein
ClientkannbeiLeseoperationennachder
neuestenVersionfragenoderaucheinen
leicht veralteten Record zulassen. Damit
lässtsichclientseitigdiebenötigteConsis­
tencywählenundeinstellen[10].
Zusammenfassung
CAP-TheoremundCloudComputing–
washatdasmiteinanderzutun?Nun,Eric
Brewer hat in seinem Vortrag eine Tür
aufgestoßen und ein Kontinuum aufge­
spannt.ACIDvs.BASEbzw.Consistency
vs.Availability.ImCAP-Theoremwurde
diesesKontinuumumeinedritteDimen­
sionerweitert:PartitionTolerance.
Größe,VerteilungundWachstumge­
hörenzudenzentralenHerausforderung
fürdieWebsitesundCloudsvonAmazon,
Google und Co. Größe und Verteilung
führen zu einem veränderten Umgang
mit Ausfällen und Fehlern – Wachstum
erforderteineinArchitekturundDesign
verankerteFähigkeitzurSkalierung.Aus
den Arbeiten von Brewer, Gilbert und
Lynchwirdklar,dassdieVerfügbarkeits-
(Availability) und Verteilungsanforde­
rungen (Partition Tolerance) auch im
CloudComputingzueinemveränderten
UmgangmitConsistencyführenmüssen.
„A“ und „P“ werden nur auf Kosten von
„C“möglich.NunhabenAmazon,Goog­
le und Co ihre Hausaufgaben gemacht.
MitAmazonDynamoundGoogleBigta­
ble sind In­frastrukturen mit neuartigen
AnsätzenfürConsistencyundScalability
entstanden. Diese Infrastrukturen kön­
nenundmüssenineinfacherWeisedurch
das Hinzufügen zusätzlicher Compute-/
Network-/Storage-Ressourcen wachsen
–ihreArchitekturliefertdieMöglichkeit,
undihreGrößeschafftdieNotwendigkeit.
UnddamitkanndieeigeneInfrastruktur
dann auch für die Mitnutzung geöffnet
werden. Der Ausbau des eigenen Ge­
schäftsmodells auf der Grundlage neuer
Availability- und Scalability-Dimensi­
onen schafft so die Grundlage für den
Einstieg in einweiteresGeschäftsmodell
–CloudComputing.
Lothar Wieske ist Enterpri-
se Architect. Als Architekt
hat er Anwendungsland-
schaften entworfen, und
als Coach hat er Teams bei
Veränderungen begleitet.
Seine Themen sind Cloud Computing,
Model-driven Development sowie
systemisches Coaching und agile Ent-
wicklung.
Links & Literatur
[1] http://www.cs.berkeley.
edu/~brewer/cs262b-2004/
PODC-keynote.pdf
[2] http://lpd.epfl.ch/sgilbert/pubs/
BrewersConjecture-SigAct.pdf
[3] http://www.gomez.com/download/
Aberdeen_WebApps.pdf
[4] http://highscalability.com/latency-
everywhere-and-it-costs-you-
sales-how-crush-it
[5] http://queue.acm.org/detail.
cfm?id=1466448
[6] http://queue.acm.org/detail.
[7] http://www.allthingsdistributed.
com/files/amazon-dynamo-
sosp2007.pdf
[8] http://labs.google.com/papers/
gfs-sosp2003.pdf
[9] http://labs.google.com/papers/
bigtable-osdi06.pdf
[10] http://www.brianfrankcooper.net/
pubs/pnuts.pdf

9. www.entwickler.de
Java-Magazin-Abonnement abschließen auf www.entwickler.de
Jetzt abonnieren und
3 TOP-VORTEILE sichern!
Alle Printausgaben
frei Haus erhalten1
Im entwickler.kiosk
immer und überall
online lesen – am
Desktop und mobil
2
Mit vergünstigtem
Upgrade auf das
gesamte Angebot
im entwickler.kiosk
zugreifen
3