Alexander Kaserbacher
02.05.2023
Reliability umfasst viele Teilbereiche Ihrer System-Architektur. Von technischen Infrastruktur-Themen über Systemdesign bis hin zu organisatorischen Aspekten. Die Reliability-Pillar der drei großen Architektur-Frameworks von Amazon Web Services (AWS), Microsoft Azure und Google Cloud geben Ihnen dazu Designprinzipien und Best Practices and die Hand.
In diesem Blogpost sehen wir uns die Reliability-Pillar der drei Architektur-Frameworks an und beleuchten zentrale Begriffe und Konzepte. Falls Sie weiter in die Tiefe gehen möchten, finden Sie an den entsprechenden Stellen Referenzen. Die Namenskürzel der Verweise haben eine Bedeutung: Kürzel, die mit A beginnen, beziehen sich auf AWS, M auf Microsoft Azure und G auf Google Cloud.
Reliability (englisch für Zuverlässigkeit) ist die Fähigkeit eines Systems, seine Funktionalität seinen Nutzer:innen zur Verfügung zu stellen. Zwei Kernbegriffe sind für das Konzept wichtig:
Basierend auf diesen Ideen beschreiben die Architektur-Frameworks Designprinzipien und Best Practices zur Erhöhung von Verfügbarkeit und Resilienz.
Abbildung 1: Zusammengefasste Designprinzipien der Reliability-Pillar aus den drei Architektur-Frameworks
Setzen Sie Ziele und definieren Sie Metriken bevor Sie sich über technische Maßnahmen zur Erhöhung Ihrer Zuverlässigkeit Gedanken machen.
Alle drei Architektur-Frameworks stützen sich auf die Definition von Service Level Agreements (SLAs), Service Level Objectives (SLOs) und Service Level Indicators (SLIs) [ASL] [GDG] [MAT].
Service Level Objectives (SLOs) definieren eine Erwartungshaltung an die Verfügbarkeit eines Systems oder eines einzelnen Services. Einerseits definieren Teams SLOs für die Services, die sie anderen Teams zur Verfügung stellen. Andererseits definieren Organisationen SLOs für ganze Systeme. Diese Zielsetzungen beeinflussen zukünftige Diskussionen von Architekturentscheidungen, die Auswirkung auf die Verfügbarkeit haben. SLOs werden Ihre Diskussionen treiben, da sie in Zukunft definieren, welches Maß an Systemausfällen tragbar ist und wie viel Risiko bei technischen Entscheidungen Sie eingehen sollten.
Wenn Sie Ihre Zielsetzungen vertraglich vereinbaren und unter Umständen auch mit (finanziellen) Strafen belasten, dann haben Sie ein Service Level Agreement (SLA). Diese werden üblicherweise mit Kunden oder Partnern vereinbart und sollten etwas loser gehalten sein als interne SLOs – um noch etwas Spielraum zwischen Ihren Objectives und eventuellen Vertragsstrafen zu lassen.
Service Level Indicators (SLIs) sind Metriken, die Ihnen beantworten, ob Sie ihre SLOs und SLAs einhalten. Das kann eine Prozentzahl von Fehlermeldungen pro Anfrage sein oder die Latenz von Anfragen (also die Zeit, die Ihr System und Netzwerk benötigt um dem Benutzer eine Antwort anzuzeigen).
Definieren Sie Ihre SLAs, SLOs und SLIs immer aus Kunden- bzw. Nutzer-Sicht. Ihre SLIs sollten sich nicht ändern, wenn Nutzer von internen (Teil-)Ausfällen nichts bemerken. Umgekehrt sollen Systemausfälle, die Benutzer direkt betreffen, sich negativ auf Ihre SLOs und SLAs auswirken.
Verfügbarkeit ist recht einfach zu messen. Wie machen wir aber das Konzept von Resilienz greifbarer? Dazu gibt es einige Metriken, die Sie hier im Auge behalten sollten:
Je kleiner diese Metriken sind, desto resilienter ist Ihr System. Abbildung 2 verdeutlicht diese Konzepte.
Abbildung 2: Metriken für Resilienz eingeordnet
Für eine gute “Mean Time to Acknowledge” brauchen Sie Automatismen, die schnell und zuverlässig Systemausfälle erkennen. Gutes Monitoring, aufgesetzt auf die “Operational Excellence”-Pillar ist hier entscheidend. Zusätzliche Best Practices zu Observability (bezogen auf Reliability) finden Sie auch in der jeweiligen Pillar [AMW] [MMR] [GMO].
Das Systemdesign ist ein wichtiger Einflussfaktor auf die Resilienz und somit auf die Zuverlässigkeit Ihres Systems. Deswegen fassen alle drei Architektur-Frameworks Best Practices zu diesem Thema zusammen [AWA] [GDS] [MDR]. Denken Sie an dieser Stelle auch daran, dass das Google Cloud Architecture Framework dem Thema eine eigene Pillar widmet [GPD].
Ich greife hier ein paar wichtige Punkte zu diesem Thema heraus.
Teilen Sie ihr System in unabhängige Prozesse Monolithische Systeme sind schwer zu skalieren. Da Ihr gesamtes System in einem Prozess läuft, müssen Sie auch Ihr gesamtes System replizieren und skalieren. Lösen Sie daher Teilsysteme in eigene Prozesse heraus und betreiben Sie diese als separate Services. So können Sie kleinere Einheiten unabhängig skalieren [ASW] [GDA] [MBM]. Achten Sie darauf, dass sich diese Services um fachliche Domänen und Funktionalität bilden und ihre Daten und Dienste mittels APIs zur Verfügung stellen [ABD] [ASC].
Achten Sie auf “Graceful Degradation” Stellen Sie sich vor, Service A ruft Service B auf, der aktuell nicht verfügbar ist. Nach dem Konzept “Graceful Degradation” geht Service A nun sinnvoll mit dem Fehler um, anstatt seinem Aufrufer wiederum einen Fehler zurückzugeben. Beispielsweise könnte Service A mittels vorhandener Informationen (z.B. in einem Cache) eine sinnvolle Antwort erzeugen [AGD] [GGD]. Es gibt eine Reihe von Patterns, die Sie für “Graceful Degradation” benutzen können – das Azure Well-Architected Framework hat eine sehr nützliche Auflistung dazu [MRP].
Koppeln sie Ihre Services lose Benutzen Sie Messaging und asynchrone Aufrufe um Abhängigkeiten zwischen Services zu reduzieren. Dadurch unterstützen sie “Graceful Degradation”, machen Ihre Services leichter und schneller änderbar und verringern die Wahrscheinlichkeit, unbeabsichtigt Fehler einzuführen.
Die Reliability-Pillar beschreibt ein breites Themenfeld. Wichtige Begriffe, die wir in diesem Blogpost diskutiert haben, finden Sie in Abbildung 3 nochmal entsprechend eingeordnet. Ich lade Sie dazu ein, in den Pillars der Architektur-Frameworks zu stöbern und das breite Themenfeld detaillierter aufzuschließen. Die entsprechenden Links finden Sie am Ende dieses Blogposts.
Abbildung 3: Begriffe um Reliability eingeordnet
Das war der vierte Beitrag der Blogreihe “Well Architected Cloud”. Im nächsten Artikel werden wir die Pillar “Performance Efficiency” beleuchten.
Sie möchten sich zum Thema Reliability oder den Architektur-Frameworks der Cloud-Anbieter austauschen? Melden Sie sich gerne, meine Kontaktdaten finden Sie hier.
“Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber”
‘Well Architected Cloud: die “Operational Excellence”-Pillar’
“Well Architected Cloud: die Security-Pillar”
‘Well Architected Cloud: die “Performance Efficiency”-Pillar’
“Well Architected Cloud: die Pillars “Cost Optimization” und Sustainability”
“Well Architected Cloud: die Architektur-Frameworks effektiv und effizient einsetzen”
“Die Pillar im AWS Well-Architected Framework”
“Die Pillar im Azure Well-Architected Framework”
“Die Pillar im Google Cloud Architecture Framework”
[ABD] “Build services focused on specific business domains and functionality”
[AGD] “Implement graceful degradation to transform applicable hard dependencies into soft dependencies”
[AMW] “Monitor workload resources”
[ASC] “Provide service contracts per API”
[ASL] “Architect your product to meet availability targets and uptime service level agreements (SLAs)"
[ASW] “Choose how to segment your workload”
[AWA] “Workload architecture”
[GDA] “Decouple your architecture”
[GDG] “Define your reliability goals”
[GDS] “Design for scale and high availability”
[GGD] “Degrade service levels gracefully when overloaded”
[GMO] “Build observability into your infrastructure and applications”
[GPD] “System design pillar”
[MAT] “Availablity targets”
[MBM] “Build with microservices”
[MDR] “Design for reliability”
[MMR] “Monitoring for reliability”
[MRP] “Resiliency Patterns”