Zellenbasierte Architektur auf AWS

Einführung

Monolithische Anwendungen sind weit verbreitet und es ist keine Schande, eine davon in Ihren Workloads auszuführen. Diese Systeme entwickeln sich oft durch viele Iterationen von Funktionserweiterungen und Fehlerbehebungen und wachsen allmählich zu dem heran, was wir heute als Monolith erkennen. Dieses Wachstum ist auch ein indirektes Zeichen für die Fähigkeit Ihres Unternehmens, zu expandieren und steigenden Anforderungen gerecht zu werden. Mit der Vergrößerung Ihrer Benutzerbasis steigen jedoch auch die Herausforderungen im Zusammenhang mit der Umgestaltung und Neugestaltung Ihrer Anwendungen und Arbeitsabläufe, was letzten Endes zu Engpässen und potenziellen einzelnen Ausfallpunkten führt.

In diesem Blog wird die zellenbasierte Architekturvorgestellt, ein Name, auf den ich gestoßen bin, als ich nach einer praktikablen Lösung für den Beginn einer Entkopplung mehrerer monolithischer Anwendungen in AWS gesucht habe. Bei den Architekturmustern handelt es sich nicht um ein neues Konzept. Ziel ist es jedoch, das Konzept der Bulk-Head-Architektur in Ihre Lösung einzuführen.

Wenn Sie mit dem Well-Architected Framework von AWS nicht vertraut sind, empfehle ich Ihnen, das Whitepaper zu lesen, in dem das Konzept der Bulkhead-Architektur erläutert wird.

Einführung in Zellen

Stellen Sie sich vor, Ihre Anwendung sei in unabhängige, in sich geschlossene Einheiten, sogenannte Zellen, aufgeteilt. Jede Zelle ist eine vollständige Instanz Ihrer Anwendungslogik mit eigener Datenbankreplik oder eigenen Speicherressourcen. Wir müssen aufpassen, dass wir es nicht mit einer Hochverfügbarkeitslösung über mehrere Verfügbarkeitszonen oder Regionen hinweg verwechseln, da uns diese eine physische Isolation auf der Infrastrukturebene bietet. Wir sind besorgt über die Anwendungsisolierung auf der Grundlage von Geschäftsanforderungen und CI/CD Arbeitsabläufe. Wenn man dieses Konzept vereinfacht, ähnelt es sehr der Containerisierungsarchitektur, allerdings in einem anderen Maßstab.

In diesem Diagramm können wir davon ausgehen, dass jede Zelle eine Anwendung darstellt, die in ihrem eigenen AWS-Konto isoliert ist. Den als „dünnstmögliche Schicht“ dargestellten Mobilfunkrouter erkläre ich später noch.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

So sieht eine zellenbasierte Architektur für eine einfache zweistufige Anwendung aus.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Um die Zellenarchitektur aufzuschlüsseln: Jede Zelle ist ein AWS-Konto. Wenn wir eine der Zellen vergrößern, können Sie die Rechen- und Speicherressourcen sehen, die für hohe Verfügbarkeit über mehrere AZs hinweg eingerichtet sind.

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Vorteile der zellenbasierten Architektur

Verbesserte Verwaltbarkeit

• Reduzierter Explosionsradius: Probleme werden auf einzelne Zellen beschränkt, wodurch die Auswirkungen auf die Gesamtanwendung minimiert werden. Auf diese Weise können Sie Probleme isolieren und schnell beheben, ohne eine große Benutzerbasis zu beeinträchtigen. Es handelt sich hierbei um das oben erwähnte Schottkonzept.
• Sichere Bereitstellungen: Neue Funktionen oder Versionsupgrades können zum Testen in einer einzelnen Zelle bereitgestellt werden, bevor sie in allen Zellen eingeführt werden. Dies minimiert das Risiko und ermöglicht bei Bedarf einfachere Rollbacks.

Verbesserte Fehlertoleranz

• Hohe mittlere Betriebsdauer zwischen Ausfällen (MTBF): Indem Sie die Größe jeder Zelle begrenzen, d. h. die Anzahl der Benutzer oder die Arbeitslast pro Zelle einschränken, können Sie Ausfälle möglicherweise leichter vorhersagen und beheben. Dies führt zu einer höheren MTBF, was bedeutet, dass bei Ihrer Anwendung seltener Ausfälle auftreten.
• Kürzere mittlere Wiederherstellungszeit (MTTR): Die begrenzte Zellengröße vereinfacht zudem die Fehlerbehebung. Da Sie weniger Ressourcen für die Diagnose zur Verfügung haben, können Sie Probleme schneller lösen, was zu einer kürzeren MTTR führt.

Leicht skalierbar

• Horizontale Skalierung: Anders als bei der Hochskalierung einer monolithischen Anwendung können Sie bei der zellenbasierten Architektur eine horizontale Skalierung durchführen, indem Sie neue Zellen hinzufügen, um den erhöhten Datenverkehr zu bewältigen. Dies ermöglicht einen effizienteren und besser handhabbaren Ansatz zur Bewältigung des Wachstums.
• Vorhersehbares Servicekontingent: AWS-Servicekontingente definieren Ressourcennutzungsgrenzen für Ihr Konto. Wenn dies übersehen wird, kann es manchmal ein Hindernis darstellen. Durch die Verwendung einer zellenbasierten Architektur können wir sicherstellen, dass diese Kontingente die Anwendungsfunktionalität beim Skalieren nicht beeinträchtigen.
• Verbesserte Testbarkeit: Canary-Tests, bei denen Sie einer kleinen Teilmenge von Benutzern eine neue Version bereitstellen, werden durch die zellenbasierte Architektur vereinfacht. Sie können neue Funktionen oder Updates in einer einzelnen Zelle testen, ohne die gesamte Benutzerbasis zu beeinträchtigen.

Erstellen Sie Ihre zellenbasierte Architektur auf AWS

Hier bespreche ich die wichtigsten Komponenten, die AWS zum Einrichten einer zellenbasierten Architektur bereitstellt:

• Route 53: Dieser Dienst verteilt den Verkehr auf mehrere Superzellen (Gruppen von Zellen innerhalb einer Region) und verwendet dabei gewichtetes Routing oder erweiterte Integritätsprüfungen zur Zonensteuerung.
• Zellenroutingschicht: Ein Mikroservice oder eine containerisierte Anwendung, die Anfragen empfängt, eine Routingtabelle wie DynamoDB konsultiert, um Benutzer bestimmten Zellen zuzuordnen, und sie an den Load Balancer der entsprechenden Zelle weiterleitet. Im ersten Diagramm oben wird es als „dünnstmögliche Schicht“ dargestellt und genau das sollte es sein. Dies sollte die einzige Aufgabe dieser Schicht sein.
• Superzelle (Region): Jede AWS-Region stellt eine Superzelle dar und kann mehrere Zellen enthalten. Es umfasst einen Elastic Load Balancer (ELB) zur Verkehrsverteilung, eine Auto Scaling-Gruppe zur automatischen Skalierung, einen CloudWatch-Agenten zur Überwachung und optionale S3-Buckets für zellenspezifische Daten oder Protokolle.
• Zelle: Dies ist die Kerneinheit. Sie kann EC2-Instanzen, Lambda-Funktionen, ECS, EKS usw. enthalten, auf denen Ihr Anwendungscode ausgeführt wird, eine eigene Datenbankreplik oder ein eigener Speicher sowie zellenspezifische Konfigurationsdateien.

Zentrale Verwaltung

Durch die Nutzung von AWS Organizations und AWS Control Tower wird die Einrichtung von AWS Landing Zones automatisiert, während Ihre Governance-Anforderungen eingehalten und die Best Practices von AWS in der Cloud übernommen werden.

Wichtige Überlegungen zur zellenbasierten Architektur:

• Zellenplatzierung: Entscheiden Sie, wie Kunden und Arbeitslasten Zellen zugeordnet werden. Dabei werden Daten und Verkehr basierend auf Ihrer spezifischen Anwendung (B2B vs. Geschäftskontext
• Möchten Sie beispielsweise, dass die Zellen näher am geografischen Standort Ihres Endbenutzers oder näher am Kunden liegen, basierend auf dessen Benutzerprofil?

< Drupal-Entität data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

• Routing: Implementieren Sie einen robusten Routing-Mechanismus wie Route 53 oder API Gateway, um den Datenverkehr an die richtigen Zellen zu verteilen. Sorgen Sie für hohe Verfügbarkeit, indem Sie einzelne Ausfallpunkte vermeiden. Erwägen Sie die Verwendung mehrerer VPCs mit VPC-Peering für die Zellenkommunikation. Wir können Route 53 Application Recovery Controller für erweiterte Routing-Szenarien integrieren.
• Zellengröße: Bestimmen Sie die optimale Größe für Ihre Zellen, um eine effiziente Skalierung basierend auf Ihrem vorgegebenen Scale-Out-Plan sicherzustellen.

Wie bereits erwähnt, ist die zellenbasierte Architektur kein neues Konzept. Es handelt sich um ein bewusstes Muster, das bei der Ausarbeitung einer Lösung zur Entkopplung einer monolithischen Anwendung und beim Entwurf einer neuen Lösung berücksichtigt werden muss. Die Nutzung einiger globaler AWS-Dienste wie Route 53 und CloudFront in einer zellenbasierten Architektur kann neue Dynamiken bei der Verwaltung Ihrer CI/CD Pipeline mit maßgeschneiderten Endbenutzererlebnissen basierend auf Ihren Geschäftsanforderungen.

Angesichts der Komplexität moderner Softwareentwicklung stellt der Übergang von der monolithischen zur zellenbasierten Architektur nicht nur eine Verbesserung dar – es handelt sich um einen strategischen Schritt in Richtung Agilität, Belastbarkeit und nachhaltige Innovation. Wenn Sie bereit sind, die Verwaltbarkeit, Fehlertoleranz und Skalierbarkeit Ihres Systems mit AWS zu verbessern, machen wir gemeinsam den ersten Schritt.