REL01-BP03 Berücksichtigen von festen Servicekontingenten und Einschränkungen durch die Architektur
Achten Sie auf nicht veränderbare Service-Kontingente, Service-Einschränkungen und physische Ressourcenbeschränkungen. Entwerfen Sie Architekturen für Anwendungen und Services, um zu verhindern, dass sich diese Beschränkungen auf die Zuverlässigkeit auswirken.
Beispiele hierfür sind die Netzwerkbandbreite, die Datengröße beim Aufrufen von Serverless-Funktionen, die Drosselung der Burst-Rate eines API-Gateways und die gleichzeitig mit einer Datenbank verbundenen Benutzer.
Gewünschtes Ergebnis: Die Anwendung oder der Service erbringt unter normalen Bedingungen und bei hohem Datenverkehr die erwartete Leistung. Sie wurden so konzipiert, dass sie innerhalb der für diese Ressource festgelegten Beschränkungen oder Service-Kontingente arbeiten.
Typische Anti-Muster:
-
Auswahl eines Designs, das eine Ressource eines Service verwendet, ohne zu wissen, dass es Design-Einschränkungen gibt, die dazu führen, dass dieses Design beim Skalieren versagt.
-
Sie führen ein Benchmarking durch, das unrealistisch ist und mit dem während der Tests die festen Kontingente für den Service erreicht werden. Sie führen beispielsweise Tests mit einem Burst-Limit durch, diese aber für einen längeren Zeitraum.
-
Sie wählen ein Design aus, das nicht skaliert oder geändert werden kann, wenn feste Service-Kontingente überschritten werden müssen. Ein Beispiel wäre ein SQS-Payload von 256 KB.
-
Die Überwachungsfunktion wurde nicht zur Überwachung und Benachrichtigung von/für Schwellenwerte/n für Service-Kontingente entwickelt und implementiert, die bei hohem Datenverkehr gefährdet sein könnten.
Vorteile der Nutzung dieser bewährten Methode: Es wird sichergestellt, dass die Anwendung unter allen prognostizierten Last-Levels der Services ohne Unterbrechung oder Beeinträchtigung läuft.
Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: mittel
Implementierungsleitfaden
Im Gegensatz zu Soft-Kontingenten für Services oder Ressourcen, die durch Einheiten mit höherer Kapazität ersetzt werden können, können feste Kontingente für AWS-Services nicht geändert werden. Das bedeutet, dass alle AWS-Services dieser Art auf potenzielle harte Kapazitätsgrenzen geprüft werden müssen, wenn sie in einer Anwendung zum Einsatz kommen.
Feste Beschränkungen werden in der Service Quotas-Konsole angezeigt. Wenn die Spalten ANPASSBAR = Nein
anzeigen, gibt es eine feste Beschränkung für den Service. Auch auf einigen Konfigurationsseiten für Ressourcen werden feste Beschränkungen angezeigt. Für Lambda gibt es zum Beispiel bestimmte feste Beschränkungen, die nicht angepasst werden können.
Wenn Sie beispielsweise eine Python-Anwendung entwerfen, die in einer Lambda-Funktion ausgeführt werden soll, sollte die Anwendung daraufhin geprüft werden, ob die Möglichkeit besteht, dass Lambda länger als 15 Minuten läuft. Wenn die Codeausführung länger als dieses Service-Kontingent dauert, müssen alternative Technologien oder Designs in Betracht gezogen werden. Wird diese Beschränkung nach der Bereitstellung in der Produktion erreicht, wird die Anwendung beeinträchtigt und gestört, bis sie wiederhergestellt werden kann. Im Gegensatz zu Soft-Kontingenten gibt es keine Möglichkeit, diese Beschränkungen zu ändern – selbst wenn ein Ereignis des Schweregrads 1 eintritt.
Sobald die Anwendung in einer Testumgebung bereitgestellt wurde, sollten Strategien eingesetzt werden, um herauszufinden, ob feste Beschränkungen erreicht werden könnten. Stresstests, Lasttests und Chaostests sollten Teil des Einführungstestplans sein.
Implementierungsschritte
-
Sehen Sie sich die vollständige Liste der AWS-Services an. Diese können Sie in der Entwurfsphase der Anwendung verwenden.
-
Sehen Sie sich die Soft-Kontingentbeschränkungen und Hard-Kontingentbeschränkungen der Services an. Nicht alle Beschränkungen werden in der Service Quotas-Konsole angezeigt. Einige Services zeigen die Beschränkungen an anderen Stellen an.
-
Prüfen Sie bei der Entwicklung Ihrer Anwendung die geschäftlichen und technologischen Faktoren Ihres Workloads, wie z. B. Geschäftsergebnisse, Anwendungsfälle, abhängige Systeme, Verfügbarkeitsziele und Objekte für die Notfallwiederherstellung. Lassen Sie sich von Ihren geschäftlichen und technologischen Faktoren leiten, um das richtige verteilte System für Ihren Workload zu finden.
-
Analysieren Sie die Last des Services über Regionen und Konten hinweg. Viele feste Beschränkungen für Services basieren auf Regionen. Einige Beschränkungen sind jedoch kontobasiert.
-
Analysieren Sie die Architekturen zur Ausfallsicherheit der Ressourcen bei einem zonenbezogenen Fehler und einem Fehler in einer Region. Bei der Entwicklung von Multi-Regionen-Designs mit Aktiv/Aktiv-, Aktiv/Passiv-Hot-, Aktiv/Passiv-Cold- und Aktiv/Passiv-Pilot-Light-Ansätzen werden diese Fehlerfälle eine höhere Auslastung verursachen. Dies schafft einen potenziellen Anwendungsfall für feste Beschränkungen.
Ressourcen
Zugehörige bewährte Methoden:
-
REL01-BP01 Kenntnis von Servicekontingenten und Einschränkungen
-
REL01-BP02 Verwalten von Servicekontingenten für mehrere Konten und Regionen
-
REL10-BP01 Bereitstellen des Workloads an mehreren Standorten
-
REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler
-
REL12-BP05 Testen der Ausfallsicherheit mit Chaos-Engineering
Zugehörige Dokumente:
-
AWS Well-Architected Framework’s Reliability Pillar: Availability (Säule für Zuverlässigkeit des AWS Well-Architected Framework)
-
Bewährte AWS Trusted Advisor-Prüfungsmethoden (siehe Abschnitt „Servicelimits“)
-
How to Request Quota Increase (So beantragen Sie eine Kontingenterhöhung)
-
Service endpoints and quotas (Service-Endpunkte und -Quoten)
-
Quota Monitor for AWS
(Kontingentüberwachung für AWS) -
AWS Fault Isolation Boundaries (AWS-Grenzen für die Fehlerisolierung)
-
Availability with redundancy (Verfügbarkeit mit Redundanz)
-
What is Continuous Integration?
(Was ist Continuous integration?) -
What is Continuous Delivery?
(Was ist Continuous Delivery?) -
APN-Partner: Partner, die Sie bei der Konfigurationsverwaltung unterstützen können
-
Managing the account lifecycle in account-per-tenant SaaS environments on AWS
(Verwaltung des Kontolebenszyklus in SaaS-Umgebungen mit Konto pro Mandant auf AWS) -
Verwalten und Überwachen der API-Drosselung in Ihren Workloads
-
View AWS Trusted Advisor recommendations at scale with AWS Organizations
(Umfangreiche AWS Trusted Advisor-Empfehlungen mit AWS Organizations anzeigen) -
Automating Service Limit Increases and Enterprise Support with AWS Control Tower
(Automatisieren von Service-Limit-Erhöhungen und Enterprise Support mit AWS Control Tower) -
Aktionen, Ressourcen und Bedingungsschlüssel für Service Quotas
Zugehörige Videos:
-
View and Manage Quotas for AWS Services Using Service Quotas
(Kontingente für AWS Services, die Service Quotas verwenden, anzeigen und verwalten) -
AWS IAM Quotas Demo
(AWS IAM-Kontingente – Demo) -
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small
(AWS re:Invent 2018: Details und Strategien: Wie man die Kontrolle über große und kleine Systeme übernimmt)
Zugehörige Tools: