class: center, middle # Cloud Computing Pattern Tim Steven Meier | FH Bielefeld --- # Gliederung 1. Availability und Performance 2. Data Management 3. Design und Implementation 4. Messaging 5. Ausfallsicherheit 6. Management und Monitoring 7. Security --- class: center, middle # Availability und Performance --- # Availability und Performance - Bei der Availability wird gemessen, wie lange der Server oder das System verfügbar ist - Die Verfügbarkeit kann durch Systemfehler, hoher Nutzeranzahl und Angriffe beeinflusst werden - Bei der Performance eines Systems geht es nicht nur darum, dass das System überhaupt läuft, sondern dass es möglichst schnell läuft - Um eine bessere Performance zu erreichen, kann man versuchen das System zu skalieren und die Anzahl der Server und somit die Rechenleistung zu erhöhen --- ### Deployment Stamps - Kontext: - Ein einzelne Instanz eines Servers kann zu Problemen mit der Performance und Verfügbarkeit führen - Ein Server in Amerika führt dazu, dass Nutzer in anderen Teilen der Welt schlechte Latenz haben - Lösung: - Das System kopieren und mehrmals deployen - Vorteile: - Mehrere Server innerhalb einer Region erhöhen die Performance und Verfügbarkeit - Verteilt auf der ganzen Welt verbessert die Latenz von Nutzern der ganzen Welt - Probleme und Überlegungen: - Mehr Server erfordern mehr Maintainance und Kosten - Routing zu den richtigen Stamps muss eingerichtet werden --- ### Geoden - Kontext: - Eine einzelne Serverregion führt dazu, dass Nutzer auf der ganzen Welt schlechte Latenz haben - Lösung: - __Ge__ographical n**oden** - Ein globaler Load Balancer verteilt die Aufgaben an die einzelnen Geoden - Replizierte Datenbanken, die in allen Geoden untereinander konsistent sind - Vorteile: - Niedrige Latenz für Nutzer auf der ganzen Welt - Wenn eine Geode abstürzt, dann übernehmen andere dessen Tasks - Probleme und Überlegungen: - Mehr Server bedeuten mehr Kosten - Man muss überlegen, in welchen Regionen sich Geoden lohnen - Vielleicht lohnen sich Deployment Stamps mehr, da eine gemeinsame Datenbank nicht immer erwünscht ist und die Nutzer häufig nicht global verteilt sind --- ### Throttling (Drosselung) - Kontext: - Die Anzahl an Requests an einen Service sind nicht konstant gleich, manchmal werden sie zu groß und der Service wird überlastet - In einem solchen Fall wird der Service in der Regel hochskaliert, aber das benötigt Zeit, da die zusätzlichen Server erst hochfahren müssen - Lösung: - In dem Zeitfenster zwischen der hohen Anzahl an Anfragen und dem Hochfahren zusätzlicher Server werden die Anfragen gedrosselt - Mehrere Möglichkeiten: - Mit dem Queue Based Load Leveling kann es nicht zu einer Überlastung kommen - Einen Teil der Funktionalität abschalten, damit der Rest funktioniert - Vorteile: - Der Server stürzt nicht wegen Überlastung ab und funktioniert weiter - Probleme und Überlegungen: - Throttling zu implementieren ist nicht schwer, muss allerdings schon bei der Planung des Services beachtet werden - Es muss schnell gehandelt werden, um Throttling einzuleiten --- ### Queue-Based Load Leveling - Kontext: - Die Anzahl an Requests und Aufgaben pro Sekunde ist sehr variabel - Bei Peaks können die Aufgaben nicht schnell genug abgearbeitet werden - Lösung: - Eine Queue zwischen den Requests und den Services, die diese bearbeiten - Die Anzahl an Aufgaben bleibt konsistenter - Vorteile: - Es sind weniger Services nötig, da nicht eine Anzahl an Services benötigt wird, die mit dem Peak zurecht kommt, sondern mit dem durchschnittlichen Aufkommen - Probleme und Überlegungen: - Wenn die Queue zu lang wird, es also ein langen Peak an Requests gibt, dann kann man die Anzahl an Services hochskalieren - Queues sind eine einseitige Kommunikation und es gibt keine Response --- ### Queue-Based Load Leveling .center[] --- class: center, middle # Data Management --- # Data Management - Bei dem Data Management geht es darum die Performance und Verfügbarkeit bei Operationen mit Daten wie beim Downloaden und Uploaden von der Datenbank zu gewährleisten - Konsistenz der Daten ist wichtig, wenn die Datenbank mehrmals existiert --- ### Cache-Aside - Kontext: - Bei wiederholtem Zugriff auf Daten in einem Datenspeicher lohnt es sich diese in einen Cache zu speichern - Lösung: - Wenn eine Applikation Daten lädt, dann schaut es zuerst im Cache nach, ob diese bereits vorhanden sind - Wenn nicht, dann werden diese aus dem Datenspeicher geladen und in den Cache gespeichert - Vorteile: - Schnellerer Zugriff auf die Daten im Cache - Weniger Requests auf die Datenbank - Probleme und Überlegungen: - Cache ist nicht immer aktuell - Ablaufdatum des Caches - Lang genug um nicht die gleichen Daten mehrmals aus dem Datenspeicher zu lesen - Kurz genug um keine veralteten Daten zu haben --- ### Static Content Hosting - Kontext: - Webserver enthalten statische Inhalte, wie zum Beispiel Bilder, welche vom Client geladen werden müssen. Dies belastet den Webserver - Lösung: - Ein Speicher für statische Inhalte kann die Requests übernehmen. - Vorteile: - Die Kosten eines Speichers sind viel geringer als die für einen Server - Probleme und Überlegungen: - Die statischen Daten können von dem Webserver nicht mehr bearbeitet werden - Bei wenigen statischen Inhalten lohnt sich das Pattern nicht - Es muss beachtet werden, dass nicht jeder Nutzer beliebige Daten aus dem Speicher downloaden kann; Abhilfe mit dem Valet Key Pattern --- ### Static Content Hosting .center[] --- ### Valet Key - Kontext: - Häufig müssen große Dateien vom Server an den Client gesendet werden, oder andersherum - Dabei wird der Webserver allerdings stark belastet - Client uploadet/downloadet Daten zu einem Datastore - Allerdings sind die Daten im Datastore nicht mehr sicher, da jeder Client auf diese zugreifen kann - Lösung: - Client fragt Ressource beim Webserver an - Server validiert die Anfrage und sendet einen Key und die Adresse der Ressource - Client kann mit den Informationen die gewünschte Ressource vom Datastore bekommen - Vorteile: - Performance und Stabilität des Webservers werden geschont - Probleme und Überlegungen: - Der Key muss verschlüsselt an den Client gesendet werden - Der Key sollte nur einen kurzen Zeitraum funktionieren und nur wenige Rechte(z.b Read/Write) geben - Die Daten können nicht mehr verändert werden, bevor der Client sie herunterlädt --- ### Valet Key .center[] --- ### Sharding - Kontext: - Ein einzelner Server hat nicht unendlich Speicherplatz - Die Zugriffsgeschwindigkeit eines einzelnen Servers auf den Datenspeicher ist limitiert - Ein Server ist durch die Geschwindigkeit des Internets limitiert - Daten aus unterschiedlichen Ländern dürfen wegen Gesetzen und sollten aus Latenz und Performance Gründen nicht auf einem Server gespeichert sein - Den Datenserver zu kopieren reicht nicht aus, um jeden der Punkte zu beheben - Lösung: - Sharding: Aufteilen des Datenspeichers in Shards, welche einen Teil der Daten halten - Mehrere Varianten: - Eine zentrale Lookup-Tabelle, welche weiß, in welchem Shard die Daten gespeichert sind - Nachschauen, wo die Daten stehen, kostet etwas Zeit - Aufteilen der Shards nach Zeiten: Shard A enthält nur Daten aus dem Januar 2020, Shard B enthält Daten aus Februar 2020, etc. - Einfaches Management - Shards sind wahrscheinlich nicht gleich groß und werden unterschiedlich oft benutzt --- ### Sharding - Vorteile: - Möglichkeit, einen Datenspeicher zu vergößern, wenn ein einzelner Server, bzw. mehrere Kopien des Servers nicht mehr ausreichen - Probleme und Überlegungen: - Beim Aufteilen auf Shards muss man aufpassen, dass Daten die zusammengehören oder häufig zusammen gebraucht werden in die gleichen Shards gepackt werden - Wenn Queries auf mehrere Shards zugreifen müssen und deswegen langsam sind, kann man das Index Table Pattern verwenden - Viele Shards zu managen kann sehr aufwändig werden - Datenkonsistenz kann ein Problem werden --- ### Index Table - Kontext: - Für gewöhnlich haben Datenbanken nur einen Primärschlüssel - Wenn Daten abgefragt werden, werden diese über den Primärschlüssel abgefragt - Was ist aber, wenn man die Daten häufig über andere Felder abfragen möchte? - Lösung: - Mehrere Möglichkeiten --- ### Index Table - Komplette Tabelle kopieren und mit anderem Feld als Primärschlüssel umbauen - Diese Methode ist bei häufigen Änderungen in den Daten oder großen Datenmengen ungeeignet .center[] --- ### Index Table - Neue Tabelle(Index Tabelle) mit dem Primärschlüssel und dem gewünschten Feld - Das gewünschte Feld wird in der neuen Tabelle als Primärschlüssel verwendet - Weniger Speicher und weniger doppelte Daten - Allerdings müssen zwei Queries gemacht werden um die gewünschten Daten zu bekommen .rigth[] --- ### Index Table - Eine Mischung aus beidem - Indextabelle mit dem gewünschten Schlüssel als Primärschlüssel, dem originalen Primärschlüssel zum Nachschauen von Daten in der Originaltabelle und die am häufigsten verwendeten Felder - Häufig benutzte Daten können mit einer Query geholt werden - Andere Daten können über zwei Queries erreicht werden .center[] --- ### Index Table - Vorteile: - Erhöhte Performance beim Zugriff auf Daten über einen Anderen als den Primärschlüssel - Probleme und Überlegungen: - Mehraufwand durch Managen mehrerer Tabellen - Mögliche Konsistenzprobleme - Erhöhte Speicherkosten --- ### Materialized View - Kontext: - Komplexe Queries, bei der Daten aus verschiedenen Tabellen zusammengebaut werden benötigen viel Zeit - Lösung: - Eine Materialized View erstellen - Eine Materialized View baut automatisch eine neue Tabelle zusammen, welche für die komplexe Query optimiert ist - Vorteile: - Eine Query der Daten ist wesentlich schneller - Probleme und Überlegungen: - Die View muss bei Änderungen der Datenbank neu erstellt werden, was bei vielen Änderungen in der Datenbank zu einem Performance Problem führen kann - In diesem Fall kann die View auch zu regelmäßigen Zeiten erstellt werden, hierbei Konsistenz beachten --- ### Materialized View .center[] --- ### Event Sourcing - Kontext: - CRUD(create, read, update, and delete) wird in der Regel benutzt, um Daten zu ändern - Wenn zwei Instanzen gleichzeitig auf eine Datei zugreifen und diese ändern, dann gibt es Konflikte - Mit CRUD wird die Datenbank mit jeder Operation belastet - Lösung: - Speichere(append) Events in einem Speicher - Wenn man den aktuellen Zustand haben möchte, dann wendet man alle Events auf den Ursprung an. - Häufig mit CQRS implementiert - Vorteile: - Durch gespeicherte Events ist Monitoring schon gegeben - Weniger oder keine Konflikte in den Daten - Probleme und Überlegungen: - Events sind unveränderlich und in der Vergangenheit passiert - Auf Dauer wird die Anzahl an Events immer größer und der aktuelle Zustand wird schwerer zu berechnen -> regelmäßige Snapshots - Der jetzige Zustand muss immer wieder neu berechnet werden, wodurch es aufwändig ist ,diesen oft auszugeben - Rollback ist kaum möglich -> Compensating transaction --- ### Command and Query Responsibility Segregation (CQRS) - Kontext: - Unstimmigkeit zwischen der Lese- und Schreibdarstellung der Daten - Konflikte bei gleichzeitigen Aktualisierungen - Rechte kann man nicht nur für Lesen verteilen (Sicherheit) - Lösung: - Read(Query) und Write(Command) durch seperate Interfaces trennen - Vorteile: - Man kann die Interfaces getrennt skalieren - Die Interfaces lassen sich auf ihre Operation feintunen - Probleme und Überlegungen: - Konsistenz zwischen Read und Write Model - Komplexere Applikation --- class: center, middle # Design und Implementierung --- # Design und Implementierung - Gutes Design umfasst Faktoren, wie Wartbarkeit der Software und Wiederverwendbarkeit einzelner Komponenten - Während der Implementierung können diese Muster helfen eine bessere Softwarequalität zu erreichen --- ### Backends for Frontends - Problem: - Ein Backend für mehrere Frontends(Desktop Browser, Mobile Browser) mit unterschiedlichen Anforderungen - Interfaces für Frontends behindern einander und Änderungen am Backend werden zu komplex - Lösung: - Für jedes Frontend ein eigenes Backend - Vorteile: - Das Backend kann auf das Frontend optimiert werden - Unterschiedliche Technologien möglich - Probleme: - Duplizierter Code ist sehr wahrscheinlich - Umstieg von einem Backend auf mehrere spezialisierte Backends zeitaufwändig --- ### Anti Corruption Layer - Kontext: - Bei der Migration eines alten Systems auf ein neues System werden noch alte Teile der API/DB benötigt - Das alte System verwendet jedoch veraltete Technologien und ist nicht mit dem modernen System vereinbar - Lösung: - Eine Schicht, welche das alte System von dem neuen System trennt - Das Anti Corruption Layer fungiert als Brücke zwischen den Systemen - Vorteile: - Es ist möglich, mit dem neuen System auf die alten Daten zuzugreifen - Probleme und Überlegungen: - Höhere Latenz - Das Anti Corruption Layer muss erstellt und gewartet werden --- ### Anti Corruption Layer .center[] --- ### Strangler - Kontext: - Ein System, welches über Jahre erstellt wurde, wird schwer zu warten und veraltet - Das System in einem Stück komplett neu aufzubauen ist eine viel zu große Aufgabe - Lösung: - Nach und nach Teile des Systems austauschen - Eine neue Schicht, die "Strangler Facade", verbindet den neuen und alten Code - Vorteile: - Die Migration auf ein modernes System kann während des normalen Betriebs laufen - Probleme und Überlegungen: - Die Strangler Facade kann zu einem Performance Bottleneck werden --- ### Strangler .center[] --- ### External Configuration Store - Kontext: - Lokale Konfigurationsdateien sind auf eine einzelne Applikation limitiert - Lösung: - Externe Konfigurationsdatei - Vorteile: - Die Datei kann von ähnlichen Servern mehrfach benutzt werden - Die Konfiguration ist einfacher einzusehen, da die Dateien an der gleichen Stelle liegen - Probleme und Überlegungen: - Der Speicherort muss robust und verfügbar sein - Die Dateien müssen geschützt werden, da häufig wichtige Informationen in der Konfiguration stehen --- ### Leader Election - Kontext: - Häufig arbeiten mehrere (gleiche) Instanzen zusammen an den gleichen Aufgaben, zum Beispiel bei komplexen Berechnungen - Die Instanzen sind durch Scaling kopiert worden - Wenn die Instanzen an den gleichen Ressource arbeiten, ist es möglich, dass diese ihre Ergebnisse gegenseitig überschreiben - Lösung: - Eine Instanz wird zum Anführer gewählt, welcher die anderen koordiniert. - Der Code der einzelnen Instanzen ist der gleiche und jede Instanz kann zum Leader werden - Es gibt mehrere Wahlmöglichkeiten, zum Beispiel wird die Instanz mit der niedrigsten Prozess ID der Anführer - Vorteile: - Komplexe Aufgaben können koordiniert effizienter und weniger fehleranfällig ausgeführt werden - Probleme und Überlegungen: - Wenn der Anführer eine Fehlfunktion hat, muss dieser durch einen neuen Anführer ersetzt weden - Wenn das System durch Scaling wieder kleiner wird, dann muss beachtet werden, keinen Leader zu terminieren --- ### Compute Ressource Consolidation - Kontext: - Aufteilen von Aufgaben in mehrere Serverinstanzen kann viel Geld kosten, da nicht jede Instanz permanent laufen muss - Lösung: - Versuchen Idle-Time der Instanzen zu verringern, indem man jeder Instanz mehr Aufgaben gibt - Tasks, die unterschiedliche Ressourcen verwenden können dabei in eine Instanz gefasst werden - Vorteile: - Spart Geld - Aufgaben innerhalb einer Instanz haben eine schnellere Kommunikationsgeschwindigkeit - Probleme und Überlegungen: - Durch hohen Traffic müssen Instanzen skaliert werden; nicht jede Aufgabe ist gleich skalierbar und darf somit nicht in der gleichen Instanz laufen - Wenn eine Aufgabe innerhalb einer Instanz fehlschlägt, können die anderen Aufgaben der gleichen Instanz mitbetroffen sein - Die Instanzen werden komplexer und schwerer zu maintainen --- class: center, middle # Messaging --- # Messaging - Im Cloud Computing gibt es in einem System häufig viele verschiedene Instanzen, die miteinander kommunizieren müssen - Eine gute Infrastruktur ist wichtig, um diese Dienste effizient zu verbinden --- ### Asynchronous Request Reply - Kontext: - Für gewöhnlich bekommt man bei Backend Calls innerhalb kürzester Zeit eine Antwort, wodurch die Requests in der Regel synchron sind - Manche Requests an das Backend dauern zu lange, um synchron zu funktionieren - Lösung: - HTTP Polling - Vorteile: - Alternative zu Verbindungen, die nicht über eine lange Zeit aufrecht erhalten werden können - HTTP als einzige Technologie, wodurch es ohne moderne Technologien in alte Systeme eingebaut werden kann - Probleme und Überlegungen: - Wenn eine Ressource nicht nach einem Get-Befehl zurückgegeben werden sollte, dann wird ein 404 als Antwort erwartet - Man kann als Statuscode ein 202 zurückgeben, sollte dabei aber den Ort und eine geschätzte Wartezeit mitgeben, damit der Nutzer die Ressource erreichen kann --- ### Asynchronous Request Reply .center[] --- ### Scheduler Agent Supervisor - Kontext: - Wenn in einer Applikation mit Remote Services oder Remote Ressourcen gearbeitet wird, dann kann es häufig zu Fehlern kommen - Viele dieser Fehler sind kurzfristiger Natur und können mit dem Retry Pattern erneut versucht werden - Wenn das Problem längerfristig besteht, dann kann sich die Applikation nicht erholen und stürzt ab - Bei einem Absturz sind einige Schritte vielleicht schon geschehen, welche noch rückgängig gemacht werden müssen - Lösung: - Mehrere Aktoren, die Zugriffe regeln --- ### Scheduler Agent Supervisor .center[] --- ### Scheduler Agent Supervisor - Vorteile: - Fehler werden effektiver behandelt - Wenn ein Aktor ausfällt, können neue gestartet werden, wodurch sich das System selbst heilt - Probleme und Überlegungen: - Schwer zu implementieren - Viele Tests erforderlich --- ### Choreography - Kontext: - Für gewöhnlich steuert ein Orchestrator die Verteilung von Aufgaben an die einzelnen Services - Der Orchestrator hat dadurch eine enge Bindung an alle Services und muss umgeschrieben werden, wenn sich die Services ändern - Lösung: - Publisher Subscriber Pattern - Client Requests werden in einer Queue gepublished - Die einzelnen Services können subscriben und den Request verarbeiten, bei Erfolg wird das Ergebnis wieder für die anderen Services in der Queue gepublished - Vorteile: - Es ist ohne großen Aufwand möglich Services hinzuzufügen, zu ändern oder zu entfernen - Der Orchestrator kann kein potenzielles Bottleneck mehr sein - Probleme und Überlegungen: - Fehlerhandling ist komplizierter, weil es keine zentrale Steuereinheit gibt, welche in diesem Fall eingreift --- ### Choreography .center[] --- ### Claim Check - Kontext: - In einer auf Messages basierten Architektur werden viele Messages über einen Message Broker verschickt - Zu große Dateien verlangsamen den Service - Lösung: - Inhalt der Message in einen Datenspeicher hochladen und einen Claim Check(Abholschein) verschicken - Services, die die Message verarbeiten, können über den Abholschein den Inhalt selber abholen - (nur bei großen Messages) - Vorteile: - Message Broker wird nicht überlastet - Es ist möglich Authentifizierungsregeln einzubringen, sodass die Inhalte im Datenspeicher sicherer sind als im Message Broker - Probleme und Überlegungen: - Datenspeicher wird benutzt und kostet Geld - Speichern und Laden von Daten kostet Zeit --- ### Claim Check .center[] --- ### Competing Consumers - Kontext: - Die Anzahl an Nutzer eines Webservices variieren - Der Service kann eventuell nicht mit der Menge an Nutzern mithalten - Lösung: - Message Queue - Der Nutzer gibt seine Anfrage in eine Queue, mit der alle Nutzer nacheinander bearbeitet werden können - Vorteile: - Der Service wird nicht überlastet, da er immer so viele Requests aus der Queue bearbeiten kann, wie es dem Service möglich ist - Die Anzahl an Nutzern, die Requests in die Queue geben und die Anzahl Services, die die Requests aus der Queue bearbeiten ist beliebig skalierbar - Wenn ein Service fehlschlägt, wird der Request wieder der Queue hinzugefügt, sodass ein anderer Service diese übernehmen kann - Probleme und Überlegungen: - Requests, die Services zum Absturz bringen müssen entfernt werden - Je nach Anzahl an Nutzern kann eine Message Queue zu einem Bottleneck werden --- ### Competing Consumers .center[] --- ### Sequential Convoy - Kontext: - Häufig müssen mehrere Messages von einem Nutzer in einem einzelnen System bearbeitet werden - Das übliche Competing Consumers Pattern würde die einzelnen Messages auf unterschiedliche Services verteilen, um diese schneller zu verarbeiten, wodurch diese aber fehlschlagen würden, da die Messages zueinander gehören - Lösung: - Messages, die zueinander gehören werden mit Kategorien versehen, sodass diese von einem einzelnen Service bearbeitet werden - Vorteile: - Messages werden in korrekter Reihenfolge bearbeitet - Probleme und Überlegungen: - Wie kategorisiert man die ankommenden Messages? --- ### Priority Queue - Kontext: - Für gewöhnlich werden Requests nacheinander abgearbeitet, zum Beispiel mit einer Queue - Wenn es Kunden mit besonderem Status gibt, ist es nötig, diesen Priorität zu geben - Lösung: - Man kann in der Queue den einzelnen Requests Prioritäten zuweisen und bei neuen Requests die Queue sortieren .center[] --- ### Priority Queue - Alternativ kann man für jede Priorität eine eigene Queue einrichten. - Jede Queue besitzt eigene Services, wobei die Queue mit der höchsten Priorität die höchste Rechenpower erhält - Als Variation kann man mehrere Queues haben, bei denen die abarbeitenden Services zuerst die Queue mit der höchsten Priorität bedienen .center[] --- ### Priority Queue - Vorteile: - Nutzer oder Tasks mit hoher Priorität werden schneller abgearbeitet - Probleme und Überlegungen: - Mehrere Queues bedeuten potenziell mehr Wartungsbedarf --- ### Publisher/Subscriber - Kontext: - Einzelne Komponenten eines Systems müssen im Falle eines Events andere Komponenten informieren - Mit asynchronen Messages kann man die Informationen verteilen, ohne auf Antworten warten zu müssen, wobei diese aber nicht für jeden bestimmt sind - Lösung: - Services publishen Messages asynchron an einen Channel im Message Broker - Der Message Broker verteilt die Messages an die Services, welche den Channel subscribed haben - Vorteile: - Da bei asynchonen Messages nicht auf eine Antwort gewartet wird, können die Services schneller an anderen Aufgaben weiterarbeiten - Monitoring und Logging ist durch die Messages vereinfacht - Probleme und Überlegungen: - Für die Sicherheit muss beachtet werden, dass nicht jeder jeden Channel subscriben kann - Da die Messages asynchron sind, kann man nicht antworten - Messages werden vielleicht zu spät verarbeitet, wodurch diese bereits veraltet sein können --- ### Publisher/Subscriber .center[] --- class: center, middle # Ausfallsicherheit --- # Ausfallsicherheit - Bei der Ausfallsicherheit geht es darum, dass im Falle eines Fehlers das System nicht vollständig versagt, sondern es möglich, ist sich von solchen Fehlern zu erholen - Dabei ist es wichtig, einen Fehler zu erkennen und angemessen zu handeln --- ### Retry - Kontext: - Services und Datenbanken können überlastet oder kurz disconnected sein, wodurch der Service nicht erreichbar ist - Lösung: - Wenn die Verbindung zu einem Service nicht funktioniert, kann man es erneut versuchen - Linear Retry: alle X Sekunden ein weiterer Versuch - Exponential Retry: 1 Sekunde warten, 5sek, 20sek... - Vorteile: - Der Service ist nach weiteren Versuchen vielleicht wieder erreichbar - Probleme und Überlegungen: - Wenn zu viele Retries an einen überlasteteten Service gesendet werden, benötigt dieser länger, um sich zu erholen - Es ist nie sicher, ob sich der Service tatsächlich erholt, wodurch Retries nicht erfolgreich sind --- ### Circuit Breaker - Kontext: - Ein Fehler eines Services kann länger dauern und wiederholtes Versuchen kostet nur Zeit, führt aber nicht zum Erfolg - Lösung: - Der Circuit Breaker ist ein Proxy, der die letzten Failures des Services überwacht - 3 Zustände, welche vom Circuit Breaker gesetzt werden, abhängig von den letzten (Miss-)Erfolgen - Vorteile: - Weniger unerfolgreiche Retries - Mehr Chancen für den Service sich zu erholen, bevor er neue Anfragen erhält - Mit geloggten Daten kann man Timeouts neu anpassen, sodass der Server sich besser erholt - Probleme und Überlegungen: - Der Circuit Breaker kann ein Problem falsch einschätzen und Anfragen für längere Zeit blockieren, obwohl der Service nur kurz überlastet war - Circuit Breaker sollten nur einen Service überwachen, sodass Anfragen auf intakte Services nicht ebenfalls abgeblockt werden --- ### Circuit Breaker .center[] --- ### Compensating Transaction - Kontext: - Große Transaktionen dauern lange - Wenn diese am Ende fehlschlagen, dann muss in der Regel jeder Schritt rückgängig gemacht werden - Zurücksetzen auf den Ursprungszustand ist häufig nicht möglich, da die betroffenen Daten bereits anderweitig geändert worden sein könnten - Lösung: - Anstatt eines Rollbacks auf den alten Stand versucht man die Aktionen zu kompensieren - Dafür loggt man die Schritte der Transaktion und erstellt Aktionen, die die ursprüglichen Schritte rückgängig machen - Vorteile: - Es gehen keine Informationen verloren - Schritte zum Rückgängig machen können auch parallel verlaufen - Probleme und Überlegungen: - Man muss überlegen, ob ein Fehler in einer Transaktion direkt rückgängig gemacht werden sollte, oder der fehlgeschlagene Schritt erneut veruscht werden sollte(Retry) - Der Versuch der Kompensation kann auch fehlschlagen, wo dann eventuell ein Mensch eingreifen sollte --- ### Bulkhead - Kontext: - Wenn ein Service sehr langsam ist und Requests nicht beantwortet werden, dann erhöht sich die Anzahl an Requests, bis der Server überlastet ist - Lösung: - Bulkhead ist ein Begriff aus dem Schiffsbau, wo das Schiff mehrere Trennwände enthält. Wenn das Schiff ein Loch hat, dann flutet nur eine kleine Sektion des Schiffes - Bulkhead Pattern isoliert die einzelnen Services, sodass, wenn ein Service langsam ist oder failt, die anderen Services unbeeinträchtigt weiterarbeiten können - Es werden für jeden Service nur eine maximale Anzahl an Requests angenommen, sodass selbst bei großer Auslastung eines Services die anderen weiterarbeiten können --- ### Bulkhead - Vorteile: - Selbst wenn ein Service fehlschlägt, können andere Services weiterarbeiten - Bei größeren Systemen kann man mehrere Instanzen des gleichen Services benutzen, bei dem jeder Client eine Instanz belegt. Wenn ein Client den Server überlastet, dann betrifft es nur den einen Client, während andere Clients den gleichen Service weiternutzen können - Probleme und Überlegungen: - Es ist nicht immer möglich Services aufzuteilen - Es kann schwerer zu managen sein --- class: center, middle # Management und Monitoring --- # Management und Monitoring - Cloud Anwendungen sind schwerer zu überwachen, da man nicht die volle Kontrolle über die Hardware und das Betriebssystem hat - Dennoch ist es wichtig zu überprüfen, ob das System verfügbar ist und im vollen Umfang funktioniert --- ### Health Endpoint Monitoring - Kontext: - Es ist wichtig zu überwachen, ob die Applikationen intakt sind und wo das System zu langsam oder gar nicht mehr läuft - Lösung: - Ein Monitoring System schickt regelmäßig Requests an alle Services - In diesem Request werden Tests ausgeführt, die Antwortzeiten und Response Codes überprüft - Vorteile: - Es lässt sich überprüfen, ob die Webservices funktionieren(Monitoring) - Probleme und Überlegungen: - Der Check sollte von einem Standort in der Nähe der Nutzer ausgeführt werden, damit Informationen über die Latenz der Realität entsprechen - Sicherheitsrichtlinien müssen bei dem Healthcheck eingehalten werden --- ### Ambassador - Kontext: - Legacy Applikationen haben nicht immer die Möglichkeit unterschiediche Netzwerkfunktionen zu implementieren - Lösung: - Ein Proxy Server (Ambassador) mit allen Netzwerkfunktionen des Clients - Der Proxy kann das Retry oder Circuit Breaker Pattern verwenden - Proxy kann die Clientapplikation mit Monitoring und Sicherheitsfunktionalitäten erweitern - Vorteile: - Generischer Proxy Server, welcher für alle möglichen Sprachen und Frameworks die Netzwerkfunktionen übernehmen kann - Probleme und Überlegungen: - Der Proxy Server beeinflusst die Latenz des Servers --- ### Ambassador .center[] --- ### Sidecar - Kontext: - Applikationen und Services benötigen häufig Funktionen zum Loggen oder Verbinden mit dem Netzwerk - Die Funktionen in jedem Service einzeln zu implementieren ist sehr aufwändig - Lösung: - Eine Sidecar Instanz mit den nötigen Funktionen erstellen, welche immer an der Seite seiner Primärapplikation bleibt und zusammen mit der Primärapplikation gelöscht wird - Vorteile: - Sidecar hat seine eigenen technischen Anforderungen und kann unabhängig von der Primärapplikation geupdatet werden - Durch die Nähe zur Primärapplikation gibt es (fast) keine zusätzliche Latenz - Probleme und Überlegungen: - Das Sidecar ist ein Teil der Applikation und skaliert mit, was eventuell nicht benötigt wird --- ### Gateway Offloading - Kontext: - Manche Funktionen werden von vielen oder sogar allen Services benötigt - Wartung der gleichen Funktionen an vielen verschiedenen Stellen ist aufwändig - Lösung: - Authentifizierung, Monitoring, Zertifikate, SSL und mehr in einer Gateway Instanz - Vorteile: - Weniger Aufwand in den einzelnen Services - Durch Auslagern von Sicherheitsfunktionen in eine einzelne Instanz kann das gesamte System einfacher und effizienter gemanaged werden - Probleme und Überlegungen: - Möglicher Single Point of Failure - Möglicher Bottleneck - Nicht jede Funktion sollte in das Gateway ausgelagert werden, vor allem, wenn nur wenige Services die Funktion benötigen --- ### Gateway Aggregation - Kontext: - Für eine Aufgabe des Clients müssen häufig mehrere Services angesprochen werden - Dadurch werden mehrfach Requests an unterschiedliche Services geschickt - Lösung: - Statt mehrere Requests an die einzelnen Services wird nur ein Request an ein Gateway geschickt - Das Gateway übernimmt die restlichen Requests an die einzelnen Services - Vorteile: - Senkung des Traffics - Senkung der Latenz - Probleme und Überlegungen: - Möglicher Single Point of Failure - Möglicher Bottleneck --- ### Gateway Aggregation .center[] --- ### Gateway Routing - Kontext: - Wenn ein Nutzer verschiedene Services ansprechen muss, dann muss er jeden Endpoint kennen - Lösung: - Anstatt dem Nutzer jeden Endpoint zur Verfügung zu stellen, benutzt man ein Gateway, welches die Requests der Nutzer weiterleitet - Vorteile: - Die einzelnen angebotenen Services können sich ohne großen Aufwand ändern und sind weiterhin über das Gateway erreichbar - Es ist dabei auch möglich über das Gateway an interne Endpunkte wie VMs verbinden - Probleme und Überlegungen: - Möglicher Single Point of Failure - Möglicher Bottleneck --- class: center, middle # Security --- # Security - Bei der Sicherheit geht es darum, dass die Daten vor unbefugten Zugriffen geschützt werden --- ### Gatekeeper - Kontext: - Wenn ein Server mit wichtigen Daten arbeitet und einen hohen Standard an Sicherheit haben muss, dann ist es sinnvoll, wenn der Nutzer nicht direkt mit dem Server kommuniziert - Lösung: - Ein Gatekeeper nimmt Requests entgegen und überprüft diese, bevor er sie weiterschickt. - Der Gatekeeper hat dabei so gut wie keine Rechte - Wenn ein Hacker einen Angriff startet, kommt er zwar an den Gatekeeper dran, hat aber dennoch keinen Zugriff auf den Server - Vorteile: - Eine Sicherheitsschicht, welche Angriffe abwehren kann - Probleme und Überlegungen: - Gatekeeper und Server müssen auf unterschiedlichen VMs laufen - Erhöht die Latenz - Kann zu einem Single Point of Failure werden --- ### Gatekeeper .center[] --- ### Federated Identity - Kontext: - Benutzer mögen es nicht, sich für jeden Webservice einen eigenen Account anzulegen - Benutzer verwenden dabei häufig entweder die gleichen Einlogdaten oder vergessen gelegentlich das Passwort, wodurch die Nutzer unzufrieden werden - Lösung: - Auslagern der Authentifikation an Identity Providern, wie zum Beispiel google, facebook, github... - Vorteile: - Der Nutzer ist zufrieden, da er keinen neuen Account erstellen muss - Weniger Arbeit, da keine eigene Nutzerverwaltung erstellt werden muss - Probleme und Überlegungen: - Bei mehreren externen Identifikationsdiensten muss herausgefunden werden, welcher der richtige Dienst, für die vom User angegebenen Daten ist --- ### Federated Identity .center[] --- ## Quellen http://en.clouddesignpattern.org/index.php/Main_Page https://docs.microsoft.com/en-us/azure/architecture/patterns/ --- class: center, middle # Danke fürs Zuhören # Habt ihr noch Fragen?