(Load) Scaling Fortsetzung:

Transkript

1 (Load) Scaling Fortsetzung: Parallelität / Dependencies Ausflug Verteilte Systeme Web Services (Verteilte) Daten Patterns / Anti Patterns Algorithmen Einführung 1

2 Parallelisierung Verschiedene Granularitäten: Bitlevel Instruktionen / Daten SISD (Single Instruction Single Data) 1 Kern SIMD (Single Instruction Multiple Data) GPU MISD eher exotisch MIMD Mehrkern CPUs Tasks / Threads Jobs Einführung 2

3 Spielverderber der Parallelisierung Amdahls Law: wenn p = der O(n) parallelisierbare Teil eines Programmes s = der sequenzielle (nicht parallelisierbare) Teil des Programmes ist dann ist der Maximale Geschwindigkeitsgewinn durch: s+p / s+p/n bei N Cores/CPUs gegeben. Das gilt selbst wenn der Kommunikationsoverhead etc. vernachlässigbar ist Darin nicht berücksichtigt: CPU Caches (wenn der limitierende Faktor nicht die Cycles sondern der Speicher ist), Branch Prediction, etc. Einführung 3

4 Spielverderber der Parallelisierung Datenabhängigkeiten Flow Dependency (read after write): a=1; b=a; c=b; Anti Dependency (write after read): a=1; b=a+1; a=2; Output Dependency (write after write) gleiches Beispiel Control Dependencies Einführung 4

5 Spielverderber der Parallelisierung Wir benötigen: Locks Synchronisation Critical Sections Und haben (meist schwer zu findende): Race Conditions Deadlocks Dirty Caches Einführung 5

6 Web Services CAP Theorem ACID vs. BASE Konsistenz Ausflug/ Auffrischung: Verteilte Systeme Einführung 6

7 SOA Service Oriented Architecture Frontend Business Logik Persistenz Service Consumer Service Provider Div. Design Prinzipien Lose Kopplung Abstraktion Wiederverwendbarkeit Zustandslosigkeit Web Services Einführung 7

8 SOAP Entstanden 1999 XML basiert HTTP typisch als Transport, aber nicht erforderlich Struktur: Envelope, Header, Body WSDL als Beschreibungssprache (tot: UDDI) Einführung 8

9 SOAP Nachrichtenaufbau SOAP Envelope SOAP Header Headers <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockprice> <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> SOAP Body XML Content SOAPFault <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getstockpriceresponse> <m:price>34.5</m:price> </m:getstockpriceresponse> </soap:body> </soap:envelope> Einführung 9

10 WSDL Quelle: W3C Einführung 10

11 Beispiel: SoapUI Einführung 11

12 SOA mit REST -> ROA REST (REpresentational State Transfer) Erdacht 2000 von Roy Fielding als Doktorarbeit Stark an HTTP gebunden, URL adressierbar Response Encodings: XML, JSON, HTML, andere denkbar Zustandslos, CRUD Einführung 12

13 HTTP Methoden bei REST Primitive GET POST PUT PATCH DELETE HEAD OPTIONS Bedeutung Ressource lesen, ohne Status zu verändern Ressource anlegen und sonstige Operationen Ressource anlegen/ändern Teilweise Änderung einer Ressource Ressource löschen Metadaten zu einer Ressource erfragen Methoden zum Ressourcenzugriff abfragen Einführung 13

14 REST Beispiel Einführung 14

15 REST Encoding JSON, XML, YAML, HTML oder beliebig { id :23, nachname : Magschok, vorname : Georg, alter :23} <?xml version="1.0" encoding="utf-8" standalone="yes"?> <person id= 23"> <alter>23</alter> <vorname>georg</vorname> <nachname>magschok</nachname> </person> Chunking Compression Multipart Einführung 15

16 Beispiel: Enunciate Einführung 16

17 REST in MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public class GreetingService public Response message() { return new Response("Hi REST!"); public Response lowercase(final Request message) { return new Response(message.getValue().toLowerCase()); } } Einführung 17

18 REST: WADL Einführung 18

19 HATEOAS & RMM Rest Maturity Model (Leonard Richardson) Quelle: Martin Fowler HATEOAS (Hypermedia as the Engine of Application State): Dynamische Ressource Links, weg von der statischen Interfacedefinition Einführung 19

20 Andere Mechanismen zur verteilten Kommunikation RPC DCOM CORBA RMI XML-RPC DCE RMI-IIOP Thrift Einführung 20

21 CAP / Brewer's Theorem Ein Verteiltes System kann nur zwei der folgenden drei Eigenschaften erfüllen: Konsistenz (C): Alle Knoten sehen zur selben Zeit die selben Daten Verfügbarkeit (A): Alle! Anfragen an das System werden stets beantwortet Partitionstoleranz (P): Das System setzt keine perfekte Kommunikationsinfrastruktur voraus. Nachrichten können verloren gehen das Netz kann Partitioniert werden. Einführung 21

22 ACID / BASE Die klassische DB Anforderung ist ACID: Atomic: Alles oder nichts Consistent: Vorsicht hier im Sinne von Integrität der Daten untereinander bei CAP im Sinne der Daten innerhalb verteilter Systeme! Isolated: um Transaktionen zu parallelisieren Durable: im Sinne von persistent Verwendet Dinge wie: D.H: Locks Commit / 2Phase Commit Rollbacks Transaktions-Logs Systeme welche ACID unterstützen sind nicht Partitionstolerant Einführung 22

23 ACID / BASE Viele NoSQL DBs unterstützen BASE verzichten auf Consistency von CAP Basically available Soft State Eventual Consistentcy! Der Übergang kann auch fließend zwischen A/C Consistency vs Availability gewählt werden Einführung 23

24 Arten der Konsistenz in verteilten Systemen Client Sicht: Monotonic Read Consistency: System liefert niemals ältere Version bei Leseanfragen an den gleichen Schlüssel. Monotonic Write Consistency: System garantiert die gleiche Schreib- Reihenfolge für alle Knoten (Replikas) Read Your Writes Consistency: System liefert einem Client der eine Schreiboperation ausgeführt hat keine ältere Version des Datums. Write Follows Reads Consistency: Das System garantiert, dass ein Schreibvorgang auf ein Datum in Version X auf anderen Knoten (Replikas) nur ausgeführt wird wenn dort das Datum auch in Version X vorliegt. Strict Consistency: Leseoperation liefert immer den neusten Wert (Ergebnis der Letzten Schreiboperation) Einführung 24

25 Arten der Konsistenz in verteilten Systemen Daten Sicht: Causal Consistency: Die Reihenfolge von Operationen wird (bei der Anwendung in Replikas) garantiert wenn die Operationen sich in einem Kausalen Zusammenhang befinden Sequencial Consistency:Alle Operationen werden in der gleichen Reihenfolge in allen Replikas angewendet Linearizability: Wie Sequencial Consistency nur wird die korrekte chronologische Reihenfolge gefordert. Einführung 25

26 Multiversion Concurrency Control Löst das Problem des Konkurrierenden Zugriffs ohne Locks Daten sind Immutable : Schreibzugriffe erzeugen neue Version. Publikumsfrage welche Probleme machen Locks in Bezug auf Skalierung? Lesen: funktioniert immer eventuell bekomme ich eine alte Version Schreiben: Eine Transaktion kennt die dafür gelesene Version des Objekts. Ist diese nicht mehr aktuell wird die Transaktion abgebrochen. Einführung 26

27 Patterns / Anti Patterns Shared Nothing / Shared Disk Thread Pool Reactor / Proactor Einführung 27

28 Cluster: Shared Disk Architecture Adaptiert schnell bei unterschiedlichen Last Szenarien (dynamisches Loadbalancing) Failover / HA ist einfach Schlecht bei hoher schreibe Last (dirty Caches in den Knoten) NAS NAS Einführung 28

29 Cluster: Shared Nothing (unendlich) skalierbar Billiger (HW Kosten) Daten sind partitioniert (Sharding) Gut bei hoher Lese/Schreibe Last Schlecht bei Transaktionen über das Cluster Schlecht bei Datenverknüpfungen A-E F-J K- Einführung 29

30 Cluster: Shared Nothing Setup (für HA/Failover) Z.B. DRBD Boot Boot Prim Sec Prim Sec Einführung 30

31 Request Handling: Thread Pool Pattern Vorteile: Optimiert den Zyklus: Request CreateThread Process DestroyThread Systemunabhängige Programmierung Systemabhängige Konfiguration (Größe) Isolation! Nachteile: (Speicher) Overhead Synchronisation der Queues Feeding slow Clients! Beispiel: Apache prefork (default) Quelle: Wikipedia - Einführung 31

32 Request Handling: Reactor Pattern Reactor: Annahme und Dispatchen Asynchroner Requests Serialisierte Abarbeitung Vorteile: Blockiert nicht Kosten für weitere Requests billig (keine Kontext Switche) Nachteile: Non-Preemptive => kein Blocking I/O in den Event Handlern Wenig Isolation Schwer zu debuggen Beispiele: Nginx, Gui- Event Loop / Game Loop Quelle: Einführung 32

33 Request Handling: Proactor Pattern Proactor: Wie Reactor nur für lang laufende asynchrone Operationen Completion Handler wird am Ende der Operation aufgerufen Quelle: Wikipedia - Einführung 33

34 Request Handling: Proactor Pattern Initiator Completion Handler Request Request Queue Threadpool Completion Dispatcher Async Operation Processor Completion Queue Einführung 34

35 Resilienz: Stabilitäts Patterns Retrys / Timeouts Beschränkt die Belegung von Ressourccen Circuit Breaker Verschwende keine Ressourcen Handshaking /Flow Control passt die Load an die Ressourceverfügbarkeit an 'Bulkheads' Isoliert die Ressourcen um Seiteneffekte zu verringern Client-Throtteling, Server controlled scheduling Details: Tafel und Einführung 35