Überblick

Cloud ComputingBegriffsklärungGrundeigenschaftenTechnologie und AlgorithmenFormen

Cloud-Computing-SystemeAmazon Web ServicesTwitter

VS-Übung (SS12) Cloud Computing 9 – 1

Cloud Computing: Der Anfang. . .

»We call it cloud computing (. . . ) «

Eric Schmidt (Google)Search Engine Strategies Conference, San Jose,

9. August 2006

VS-Übung (SS12) Cloud Computing –Begriffsklärung 9 – 2

Cloud Computing: Der Anfang. . .

»We call it cloud computing (. . . ) «

Eric Schmidt (Google)Search Engine Strategies Conference, San Jose, 9. August 2006

VS-Übung (SS12) Cloud Computing –Begriffsklärung 9 – 2

Cloud Computing: . . . und seine Folgen.

2007 2008 2009 2010 2011

0

1000

2000

3000

12 167

1063

2331

3289

Jahr

Clo

ud-C

ompu

ting

-Pub

likat

ione

n

Gravierende Auswirkungen des Modeworts „Cloud Computing”ForschungWirtschaft

Cloud ComputingFokus auf TechnikCloud =̂ Internet, Cloud Computing =̂ Internet + ?

VS-Übung (SS12) Cloud Computing –Begriffsklärung 9 – 3

Cloud Computing: Zeitpunkt, Grundeigenschaften

Wieso entstand Cloud Computing zu dieser Zeit? Wieso nicht früher?

Infrastruktur, Hard- und Software-Technologie XCommodity-HardwareVirtualisierung

Systemsoftware, Verteilte Systeme und deren Algorithmen XParallele, verteilte DatenverarbeitungSchlüssel-Wert-Datenbank (Key-Value-Store)Verteilter KoordinierungsdienstVerteilte, dezentrale Datenhaltung

Dienstleistungsprinzip, Geschäftsmodell („. . . as-a-Service”) XService-Oriented Architecture (SOA)Infrastructure-as-a-ServicePlatform-as-a-ServiceSoftware-as-a-Service

VS-Übung (SS12) Cloud Computing –Grundeigenschaften 9 – 4

Cloud Computing: Zeitpunkt, Grundeigenschaften

Erfüllbarkeit der Grundeigenschaften von Cloud-Computing-Systemen

Skalierbarkeit, unter Wahrung von:Konsistenz (Consistency)Verfügbarkeit (Availability)Partitionstoleranz (Partition tolerance)

→ CAP-Theorem

On-Demand, zum Ermöglichen von:dynamischer Zuordnung von RessourcenAbrechnung nach tatsächlichem Verbrauch

Robustheit, zur Vermeidung von:Inkonsistenzen im Datenbestand(unkontrollierter) Fehlerausbreitung im System

VS-Übung (SS12) Cloud Computing –Grundeigenschaften 9 – 5

Systeme aus Commodity-Hardware

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 6

Systeme aus Commodity-Hardware

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 6

Systeme aus Commodity-Hardware

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 6

Systeme aus Commodity-Hardware

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 6

Systeme aus Commodity-Hardware

Charakteristikhoher Grad der Verteiltheit„unbegrenzte” Speicherkapazität

Herausforderungen für verteilte SystemeAusfälle sind nicht die Ausnahme sondern der RegelfallSystem muss trotz vieler, regelmäßig ausfallender Knoten die gefordertenKriterien (→ CAP-Theorem) gewährleisten

Offene StandardsVerwendung heterogener Knoten fordert Verwendung offener StandardsAdressiert Problem der Anbieterabhängigkeit („Vendor Lock-In”)Gilt sowohl für Soft- als auch Hardware

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 7

Commodity-Hardware, Virtualisierung

Cloud-Computing-Infrastruktur aus Commodity-Hardware

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 8

Commodity-Hardware, Virtualisierung

VM1 VM2 VMn

Virtual Machine Monitor (VMM)

Hardware

Physikalische Maschine

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 8

Virtualisierung

VM1 VM2 VMn

Virtual Machine Monitor (VMM)

Hardware

Physikalische Maschine

App

likation1

App

likation2

App

likationn

Betriebssystem 1

Virtuelle Hardware

Virtuelle Maschine 1 (VM1)

App

likation1

App

likation2

App

likationn

Betriebssystem 2

Virtuelle Hardware

Virtuelle Maschine 2 (VM2)

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 9

Systemkomponenten einer Cloud-Computing-Infrastruktur

System-EigenschaftenMassiver Grad an Verteiltheit (→ „Who owns the most servers”)Dynamische Anpassung verfügbarer Rechen- und SpeicherressourcenHäufiger Ausfall einzelner Komponenten des Gesamtsystems

Typische Anwendungsszenarien in einer Cloud-UmgebungAbarbeitung sehr großer ProblemeVerarbeitung riesiger DatenmengenBeispiele: Suchindex-Erstellung, Graph-Operationen in sozialen Netzen

Algorithmische AbbildungBetriebsumgebung verlangt angepasste Systeme und AlgorithmenAufteilung großer Aufgaben in kleinere, verteilbare und damit parallelzu verarbeitende Teilaufgaben (→ teile und herrsche)Neue Konzepte zwingend notwendig um Cloud-Computing-Infrastrukturüberhaupt effizient zu nutzen

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 10

Verteilte Datenverarbeitung: MapReduce, Hadoop

MapReduceFramework zur parallelen Bearbeitung großer Datenmengen„MapReduce: Simplified Data Processing on Large Clusters” (OSDI’04)Wichtige, einfache Datenstruktur: Schlüssel-Wert-Paare (Key-Value)

AblaufMap- und Reduce-Phase(n)Anwendungs-Programmierer implementiert Map- und Reduce-FunktionenJede Phase hat Schlüssel-Wert-Paare als Ein- und AusgabeMehrmalige Ausführung von Jobs zur Reduktion von Verzögerungen

Apache Hadoop (→ http://hadoop.apache.org), u.a.:Hadoop MapReduceHadoop Distributed File System (HDFS)

Jeffrey Dean and Sanjay GhemawatMapReduce: Simplified Data Processing on Large ClustersIn Proceedings of 6th Symposium on Operating Systems Design andImplementation (OSDI’04), pp.137–149, 2004http://www.usenix.org/events/osdi04/tech/dean.html

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 11

Skalierbare Schlüssel-Wert-Datenbanken

Schlüssel-Wert-Datenbanken (Key-Value-Stores)Key-Value-Stores haben keine relationalen Datenbeziehungen undbesitzen kein DatenbankschemaAuslagerung großer Teile der Logik (Datenbank → Applikation)Extrem effizienter Datenzugriff auf Schlüssel-Wert-PaareBeispiele: Amazon DynamoDB, Apache Cassandra, Google BigTable

Abgrenzung zu SQL-DatenbankenAufweichen von Garantien ermöglicht SkalierbarkeitBASE (Basically Available, Soft state, Eventual consistency) → NoSQLACID (Atomicity, Consistency, Isolation, Durability) → SQL

Apache CouchDB (Cluster of Unreliable Commodity Hardware)Schemafreie Schlüssel-Wert-DatenbankDatenverwaltung in JSON (Java Script Object Notation)Peer-to-Peer für verteilte Datenverwaltung

→ Demo CouchDB

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 12

Verteilte Dateisysteme, Verteilte Koordination

Verteilte DateisystemeUnkonventionelle Schnittstellen, sehr verschieden im Vergleich mitherkömmlichen (verteilten) Dateisystemen → kein POSIXReplikation gewährleistet Fehlertoleranz beim Ausfall von KnotenBeispiele: Amazon S3, Google Filesystem

Verteilte KoordinationProgrammier-Schnittstelle ähnelt der von DateisystemenUmsetzung von Sperrmechanismen (Locking), AnführerwahlFehlertoleranz durch aktive ReplikationBeispiele: Google Chubby, Yahoo ZooKeeper

Patrick Hunt, Mahadev Konar, Flavio P. Junqueira and Benjamin ReedZooKeeper: Wait-free Coordination for Internet-scale SystemsIn Proceedings of the 2010 USENIX Annual Technical Conference (ATC’10), 2010

http://www.usenix.org/events/atc10/tech/full_papers/Hunt.pdf

VS-Übung (SS12) Cloud Computing –Technologie und Algorithmen 9 – 13

Cloud-Computing-Modelle: „Everything as a Service”

Infrastruktur: „Infrastructure-as-a-Service” (IaaS)Anmieten von Ressourcen (virtuelle Maschinen, Speicherkapazität)Beispiele: Amazon Elastic Cloud Computing (kurz: Amazon EC2),Amazon S3, Microsoft Azure, Google Compute Engine

Plattform: „Platform-as-a-Service” (PaaS)Anmieten von Laufzeitumgebung um Applikationen auszuführenBeispiele: AWS Elastic Beanstalk, Google App Engine

Software/Anwendung: „Software-as-a-Service” (SaaS)Statt starrer Lizenzierung von Anwendungen wird nur für denBenutzungszeitraum abgerechnetBeispiele: Google Gmail, Auslagerung ganzer Geschäftsprozesse

GemeinsamkeitenAbrechnung nach tatsächlichem Verbrauch („pay what you use”)Garantierte Skalierbarkeit, keine langfristige Bindung („on demand”)Prozessauslagerung auf entfernte Systeme → Problematik „VendorLock-In”

VS-Übung (SS12) Cloud Computing – Formen 9 – 14

Ist das alles neu? Exkurs: Timesharing-Systeme

„How to Consider a Computer” (1959)Erste wissenschaftliche Arbeit zum Thema Timesharing von BobBemer (IBM)„The Father of ASCII”: hat u.a. Backslash und Escape beigetragenWeitblick: Erste Veröffentlichung zur Jahr-2000-Problematik imJahre 1971 („Time and the Computer”)

„Utility Business Model” (1961)Rede von John McCarthy (Stanford University) am MassachusettsInstitute of Technology (MIT)Rechenleistung und Spezialanwendungen sollen verkauft werden wieandere Ressourcen — wie Wasser und Strom

Timesharing-System mit Virtualisierung (1967)IBM Cambridge Scientific Center, MIT Computer Science and ArtificialIntelligence Laboratory (CSAIL): IBM CP-40Native Virtualisierung

VS-Übung (SS12) Cloud Computing – Formen 9 – 15

Vergleich: Timesharing, Cloud Computing

GemeinsamkeitenTeilen von RessourcenAbrechnungsmodellAufteilung von Anwendungslogik und Benutzerschnittstelle

UnterschiedeTransparenter Zugriff, ortsunabhängigUnendlichkeit der RessourcenGrad der Verteilung, Netzstruktur

VS-Übung (SS12) Cloud Computing – Formen 9 – 16

Amazon Web Services (AWS)

Idee: Ungenutzte Ressourcen der Amazon-Rechenzentrengewinnbringend vermieten

Dienste ermöglichen den Aufbau eigener, komplexer Systeme in einerCloud-Infrastruktur (Auszug):

Elastic Compute Cloud (EC2) – Betrieb virtueller MaschinenSimple Storage Service (S3) – Netzwerkbasierter Speicher-DienstElastic Load Balancing – Lastverteilung für EC2Elastic Map Reduce – MapReduce-Framework basierend auf EC2 und S3DynamoDB – Key-Value-Store basierend auf Dynamo

Die Abrechnung erfolgt nach tatsächlichem Verbrauch und StandortBetriebsstunden, SpeicherbedarfTransfervolumen, Anzahl verarbeiteter AnfragenStandorte in Nord- und Südamerika, Europa und Asien

→ AWS Preisübersicht: https://aws.amazon.com/pricing

VS-Übung (SS12) Cloud-Computing-Systeme –Amazon Web Services 9 – 17

Amazon Web Services (AWS)

VS-Übung (SS12) Cloud-Computing-Systeme –Amazon Web Services 9 – 18

Twitter

Twitter und Cloud ComputingAls junges Start-Up-Unternehmen zunächst keine eigene Infrastruktur→ ohne Cloud Computing würde Twitter nicht existierenNutzt Cloud-Dienste (z. B. Amazon S3) und Projekte wie ZooKeeper

Zahlen zu Twitter24 Milliarden Suchanfragen pro Monat

Google: 88 MilliardenYahoo: 9.4 MilliardenBing (Microsoft): 4.1 Milliarden

Über 400 Millionen Tweets pro TagÜber 100 Millionen aktive Benutzer (pro Monat)Etwa 900 Mitarbeiter

Rekorde (Tweets-pro-Sekunde, TPS)25.088 TPS: Ausstrahlung „Castle in the Sky” in Japan (Dezember 2011)etwa 10.000 TPS: Super-Bowl-Finale (Februar 2012)6.049 TPS: Todesfall Steve Jobs (Oktober 2011)

VS-Übung (SS12) Cloud-Computing-Systeme –Twitter 9 – 19

Probleme komplexer Cloud-Computing-Systeme

ProblemeStändig steigende Systemkomplexität → stets neue FehlerquellenFehler müssen so früh wie möglich erkannt werdenEntkopplung von Teilsystemen um Fehler-Ausbreitung zu verhindern

Twitter-Ausfall am 21. Juni 2012

Amazon-Web-Services-Ausfall (North Virginia) am 29. Juni 2012Ereigniskette:Starke Unwetter → Stromausfall → Notstromversorgung fehlgeschlagenVerfügbarkeit großer Firmen, die auf Amazon Web Services angewiesensind, war stark eingeschränkt (z. B. Instagram, Netflix, Pinterest)

VS-Übung (SS12) Cloud-Computing-Systeme –Twitter 9 – 20

Cloud Computing: Chancen und Tücken

Cloud Computing ist das Resultat paralleler, teilweise unabhängigerEntwicklung; nicht geplant, aber auch kein Zufall

Heutige Cloud-Projekte sind erste Prototypen; nicht weniger, aberauch nicht mehr

Cloud Computing bildet die Grundlage für Unternehmen ohneInfrastruktur; ansatzweise wie Twitter

Nicht zu vernachlässigen: Risiken durch Abhängigkeiten vonSoftwarekomponenten und Firmen („Vendor Lock-In”)

Hinweis: Cloud-Computing-Vorlesung am Lehrstuhl 4Wintersemester 2012/2013: Middleware – Cloud Computing

VS-Übung (SS12) Cloud-Computing-Systeme –Twitter 9 – 21