Ein unterbrechungsfreier Service ist im Bankensektor unerlässlich, wo strenge Compliance-Anforderungen, Sicherheitsbeschränkungen und der eingeschränkte Zugang zu bestimmten Google Cloud-Diensten zu einer Komplexität führen, die in weniger regulierten Umgebungen nicht zu finden ist. Eine Active-Active Architektur bietet zwar eine zuverlässige Lösung für hohe Verfügbarkeit und Ausfallsicherheit, doch die Implementierung in Google Cloud für Banken bringt ihre eigenen einzigartigen Herausforderungen mit sich. Eine effektive Active-Active Architektur kann helfen, diese Herausforderungen zu meistern.

In diesem Blog werden wir fünf „Active-Active“-Designs untersuchen, die wir für einen Bankkunden implementiert haben, die Hindernisse, mit denen wir konfrontiert waren, und die Lehren, die wir daraus gezogen haben. Wenn Sie vor ähnlichen Herausforderungen in Bezug auf Hochverfügbarkeit stehen, werden Ihnen diese Erkenntnisse dabei helfen, Ihren Weg effektiver zu gestalten.

In der heutigen digitalen Landschaft ist die Notwendigkeit einer Active-Active Architektur für Banken entscheidend, um Ausfallzeiten zu vermeiden und die Kundenbindung zu stärken.

Die Implementierung einer Active-Active Architektur ermöglicht es Unternehmen, ihre kritischen Systeme über mehrere Standorte hinweg zu synchronisieren und dadurch die Resilienz zu erhöhen.

Warum eine Active-Active Architektur im Bankwesen?

Im Bankensektor sind Zuverlässigkeit, Sicherheit und Compliance nicht verhandelbar – und wenn diese Herausforderungen nicht bewältigt werden, können Unternehmen erheblichen finanziellen und Reputationsrisiken ausgesetzt sein. Eine Active-Active Architektur ist nicht nur eine Option, sondern unerlässlich, um einen reibungslosen Betrieb zu gewährleisten und die Geschäftskontinuität in einer immer anspruchsvolleren Landschaft zu sichern. Die Vorteile einer Active-Active Architektur sind weitreichend und können entscheidend für den Erfolg eines Unternehmens sein.

Hier sind die Gründe, warum sie wichtig sind:

  • Ständige Verfügbarkeit: Ausfallzeiten sind nicht nur für Kunden unangenehm, sondern führen auch zu finanziellen Verlusten und untergraben das Vertrauen. Active-Active-Setups eliminieren einzelne Fehlerquellen, indem sie die Arbeitslasten auf mehrere Regionen verteilen und so einen unterbrechungsfreien Service gewährleisten.
  • Ausfallsicherheit: Ausfälle, Hardwarefehler und Katastrophen sind unvermeidlich, aber durch den gleichzeitigen Betrieb in mehreren Regionen halten Active-Active-Architekturen die Systeme betriebsbereit und mildern die Auswirkungen solcher Ereignisse.
  • Einhaltung gesetzlicher Vorschriften: Strenge Vorschriften zur Datenhaltung und Notfallwiederherstellung müssen eingehalten werden, und Active-Active-Setups bieten die regionsübergreifende Replikation, die zur Erfüllung dieser Anforderungen erforderlich ist.
  • Niedrige Latenz: Kunden erwarten eine sofortige Reaktionsfähigkeit. Durch die Verarbeitung von Arbeitslasten näher am Benutzer reduzieren Active-Active-Setups die Latenz und bieten eine überlegene Benutzererfahrung.
  • Kundenvertrauen: Zuverlässigkeit ist die Grundlage für das Vertrauen der Kunden. Eine Nichterfüllung der Erwartungen kann Beziehungen und den Ruf der Marke irreparabel schädigen.

Die Implementierung einer Active-Active Architektur ist ein strategischer Schritt, der es Banken ermöglicht, ihre Betriebsabläufe zu optimieren und auf unerwartete Herausforderungen schnell zu reagieren.

Google Cloud bietet zwar leistungsstarke Tools für Active-Active-Architekturen, doch die einzigartigen Einschränkungen im Bankwesen – wie der eingeschränkte Zugriff auf bestimmte Dienste – erfordern maßgeschneiderte Lösungen. Eine gut geplante Active-Active Architektur kann helfen, die Risiken zu minimieren und die betriebliche Effizienz zu steigern.

Die Risiken einer nicht implementierten Active-Active Architektur sind signifikant und können die betriebliche Resilienz eines Unternehmens gefährden.

Warum eine fehlende Active-Active Architektur Ihrem Unternehmen schaden könnte

Active-Active Architektur - Regional deployments

Bei einer nicht active-aactive Konfiguration, wie z. B. einem regionalen Einsatz, ist eine einzelne Region für die gesamte Arbeitslast verantwortlich. Dieser Ansatz ist zwar einfacher und kostengünstiger zu implementieren, hat aber erhebliche Nachteile. Die Verfügbarkeit ist von Natur aus begrenzt, da jeder Ausfall – sei es durch Hardwarefehler, Naturkatastrophen oder Netzwerkprobleme – zu längeren Ausfallzeiten führen kann. Ohne Redundanz über Regionen hinweg ist es praktisch ausgeschlossen, ein Verfügbarkeitsziel von 99,99 % zu erreichen, wodurch kritische Systeme ungeschützt bleiben und sich die Wiederherstellungszeiten verlängern. Dies wirkt sich direkt auf das Vertrauen der Kunden aus, erhöht das Risiko finanzieller Verluste und macht Unternehmen in einem hart umkämpften Markt verwundbar.

5 Active-Active Architektur Designs

Die Active-Active-Architektur für den Bankensektor ist darauf ausgelegt, eine hohe Verfügbarkeit, Ausfallsicherheit und Einhaltung gesetzlicher Vorschriften zu gewährleisten. Sie nutzt eine Kombination aus multiregionalen Bereitstellungen, synchronen und asynchronen Replikationsstrategien und Split-Horizon-DNS, um sowohl den internen als auch den externen Datenverkehr effizient zu verwalten. Externe Clients werden für einen nahtlosen Kundenzugriff an öffentliche Endpunkte weitergeleitet, während interne Clients zur Optimierung der Backend-Kommunikation an private Endpunkte weitergeleitet werden. Dieser Ansatz sorgt für ein Gleichgewicht zwischen Leistung, Konsistenz und Failover-Funktionen und bewältigt die einzigartigen Herausforderungen einer stark regulierten und sicherheitsrelevanten Umgebung.

Die Architektur für den externen Datenverkehr nutzt den Google Kubernetes Engine (GKE) Multi-Cluster Gateway Service der Google Cloud Platform, um einen nahtlosen, zuverlässigen und sicheren Zugriff auf kundenorientierte Anwendungen zu gewährleisten. Dieses Design bietet eine robuste und skalierbare Lösung für die Verwaltung des externen Datenverkehrs über mehrere aktive Regionen hinweg.

Die interne Datenverkehrsarchitektur in einer Active-Active Konfiguration erfordert robuste Designs, um eine zuverlässige Service-to-Service-Kommunikation über mehrere Regionen hinweg zu gewährleisten. Im Folgenden werden fünf Ansätze vorgestellt, die Google Kubernetes Engine (GKE)-Gateways und verschiedene Lastausgleichsmethoden zur Verwaltung des internen Datenverkehrs nutzen.

1. GKE Internal Global Multi-Cluster Gateway

Überblick: Ein zentralisiertes internes Gateway, das von GKE bereitgestellt wird, um den Dienstverkehr über mehrere Cluster weltweit zu verwalten.

Active-Active Architektur: GKE Internal Global Multi-Cluster Gateway
  • Vorteile: Vereinfacht das Verkehrsmanagement mit einer einzigen Steuerungsebene für die Weiterleitung über Cluster hinweg.
  • Nachteile: Zum Zeitpunkt der Erstellung dieses Artikels war das GKE Internal Global Multi-Cluster Gateway noch nicht vollständig in Google Cloud implementiert. Laut dem Google-Team ist die Veröffentlichung für 2025 geplant.
  • Anwendungsfall: Geeignet für Organisationen, die Einfachheit und einheitliche Verwaltung in einer globalen Active-Active-Konfiguration priorisieren.

2. DNS-basierter globaler Lastenausgleich mit regionalen GKE-Gateways

Überblick: DNS löst internen Datenverkehr in regionale GKE-Gateways auf und verteilt Anfragen an den nächstgelegenen Cluster.

Active-Active Architektur: DNS-Based Global Load Balancing with Regional GKE Gateways

Die Investition in eine leistungsfähige Active-Active Architektur ist für Banken von großer Bedeutung, um wettbewerbsfähig zu bleiben.

  • Vorteile: Bietet Flexibilität bei der Routing-Logik und lässt sich gut mit Split-Horizon-DNS für die interne Traffic-Auflösung kombinieren.
  • Hindernisse: DNS-Änderungen hängen von der TTL ab, was bei Störungen zu Verzögerungen beim Failover führen kann. Die verlängerte Failover-Zeit untergräbt das Konzept einer Active-Active-Konfiguration, da der Datenverkehr nicht schnell genug zwischen Regionen umgeleitet werden kann, um einen nahtlosen Betrieb zu gewährleisten.
  • Anwendungsfall: Ideal für Workloads, die eine leichte Verteilung des Datenverkehrs mit regionaler Autonomie erfordern.

3. Regionalübergreifender interner L7-Lastenausgleich mit regionalen GKE-Gateways

Active-Active Architektur: Cross-Regional Internal L7 Load Balancer with Regional GKE Gateways

Überblick: Ein Layer-7-Load-Balancer (Anwendungsschicht) verwaltet den Datenverkehr über Regionen hinweg und leitet Anfragen an regionale GKE-Gateways weiter.

  • Vorteile: Bietet erweiterte Routing-Funktionen auf der Grundlage von HTTP/HTTPS-Headern, Pfaden oder anderen Metadaten.
  • Hindernisse: Erhöhte Komplexität und potenzielle Latenz beim Routing von Datenverkehr zwischen Regionen. Darüber hinaus war die interne TLS-Zertifikatsverwaltung in der Kundenumgebung nicht mit L7-regionsübergreifenden Load-Balancern kompatibel.
  • Anwendungsfall: Am besten für Microservice-Architekturen mit unterschiedlichen Routing-Anforderungen oder komplexer Logik auf Anwendungsebene geeignet.

4. Regionalübergreifender interner L4-Lastenausgleich mit regionalen GKE-Gateways

Überblick: Ein Layer-4-Lastenausgleich (Transportschicht) verarbeitet den regionalübergreifenden Datenverkehr und verteilt ihn auf regionale GKE-Gateways.

Active-Active Architektur: Cross-Regional Internal L4 Load Balancer with Regional GKE Gateways
  • Vorteile: Vereinfacht das Routing auf Netzwerkebene mit geringerer Latenz im Vergleich zum L7-Lastenausgleich.
  • Hindernisse: Begrenzte anwendungsorientierte Routing-Funktionen. Der Kunde verwendet das RFC-6598-Netzwerksegment (100.64.0.0/10) für seine GCP-Cloud, aber zum Zeitpunkt der Erstellung dieses Dokuments unterstützt GCP nur RFC-1918-Netzwerksegmente (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12).
  • Anwendungsfall: Effektiv für leistungskritische Anwendungen, bei denen Einfachheit und Geschwindigkeit im Vordergrund stehen.

5. Regionaler interner L4-Lastenausgleich mit regionalen GKE-Gateways

Überblick: Jede Region verwendet ihren eigenen internen L4-Lastenausgleich, um die Verkehrsweiterleitung zwischen Regionen in einer Active-Active-Konfiguration zu verwalten.

Active-Active Architektur: Regional Internal L4 Load Balancer with Regional GKE Gateways
  • Vorteile: Geringe Latenz für regionale Kommunikation bei gleichzeitiger Unterstützung des regionsübergreifenden Datenverkehrs als Teil der Active-Active Architektur.
  • Nachteile: Erfordert zusätzliche Mechanismen für regionsübergreifendes Failover und Koordination
  • Hindernis: Keines – dieses Design wurde erfolgreich umgesetzt und an die Einschränkungen der Umgebung angepasst.
  • Anwendungsfall: Ideal für Szenarien, die eine nahtlose intra- und interregionale Kommunikation innerhalb einer konformen und regulierten Umgebung erfordern.

Wichtige Überlegungen zur Einrichtung einer Active-Active Architektur

Die Implementierung einer Active-Active Architektur in einer regulierten Umgebung wie dem Bankwesen erfordert eine sorgfältige Planung und die Berücksichtigung mehrerer kritischer Faktoren. Hier sind die wichtigsten Überlegungen, die das Design und die Implementierung der Architektur beeinflusst haben:

1. Compliance und Sicherheit

  • Regulatorische Anforderungen: Stellen Sie sicher, dass die Architektur den Branchenvorschriften entspricht, einschließlich Datenresidenz, Verschlüsselungsstandards und Disaster-Recovery-Mandaten.
  • Netzwerksicherheit: Verwenden Sie Firewalls, sichere Endpunkte und Verschlüsselung (TLS), um Daten während der Übertragung und im Ruhezustand zu schützen.
  • Zugriffskontrolle: Implementieren Sie eine rollenbasierte Zugriffskontrolle (RBAC) und setzen Sie strenge Richtlinien für die Identitäts- und Zugriffsverwaltung (IAM) durch.

2. Latenz und Leistung

  • Proximity-Based Traffic Routing: Minimieren Sie die Latenz, indem Sie den Datenverkehr mithilfe von DNS oder Lastverteilern in die nächstgelegene Region leiten.
  • Regionsübergreifende Kommunikation: Optimieren Sie die Datensynchronisierung zwischen den Regionen, um Latenz und Konsistenz auszugleichen.
  • Service-Reaktionszeiten: Überwachen und optimieren Sie die Dienste kontinuierlich, um die Leistungs-SLAs zu erfüllen.

3. Datenkonsistenz und -synchronisierung

  • Synchrone vs. asynchrone Replikation: Wählen Sie die geeignete Replikationsstrategie basierend auf der Kritikalität der Daten und der Latenztoleranz aus.
  • Konfliktlösung: Entwerfen Sie Mechanismen zur Konfliktbehandlung in asynchronen Replikationsszenarien.
  • Datenpartitionierung: Erwägen Sie die geografische Segmentierung von Daten, um den Synchronisierungsaufwand zu reduzieren.

4. Skalierbarkeit und Ausfallsicherheit

  • Lastenausgleich: Verwenden Sie eine Kombination aus globalen und regionalen Lastenausgleichsmodulen, um den Datenverkehr effizient zu verteilen.
  • Automatische Skalierung: Aktivieren Sie die automatische Skalierung für GKE-Cluster und -Dienste, um Verkehrsspitzen dynamisch zu bewältigen.
  • Failover-Mechanismen: Implementieren Sie robuste Failover-Prozesse, um die Verfügbarkeit von Diensten bei regionalen Ausfällen aufrechtzuerhalten.

5. Infrastrukturbeschränkungen

  • Dienstverfügbarkeit: Berücksichtigen Sie GCP-Dienste, die in der Bankenumgebung möglicherweise nicht verfügbar oder eingeschränkt sind.
  • Netzwerkkonfiguration: Richten Sie die Netzwerksegmentierung an GCP-unterstützten IP-Bereichen (z. B. RFC-1918) aus und stellen Sie die Kompatibilität mit der Architektur sicher.
  • Ressourcenquoten: Überwachen und verwalten Sie Cloud-Ressourcenquoten, um kapazitätsbedingte Störungen zu vermeiden.

6. Betriebskomplexität

  • Bereitstellungspipelines: Automatisieren Sie Bereitstellungspipelines, um eine konsistente Verwaltung der Infrastruktur in mehreren Regionen zu gewährleisten.
  • Überwachung und Beobachtbarkeit: Verwenden Sie zentralisierte Überwachungstools, um Einblicke in Verkehrsmuster, den Zustand von Diensten und Anomalien zu erhalten.
  • Konfigurationsmanagement: Stellen Sie mithilfe von Tools wie Terraform oder Config Connector eine konsistente Konfiguration in allen Regionen sicher.

7. Kostenoptimierung

  • Traffic Distribution: Verteilen Sie den Datenverkehr intelligent, um die Kosten für den regionenübergreifenden Datentransfer zu minimieren.
  • Right-Sizing Resources: Überprüfen Sie regelmäßig die Ressourcenzuweisung, um die Cloud-Ausgaben zu optimieren.
  • Billing Transparency: Nutzen Sie die GCP-Abrechnungstools, um die mit dem Active-Active-Setup verbundenen Kosten zu überwachen und zu prognostizieren.

Durch die Berücksichtigung dieser Überlegungen kann die Active-Active Architektur die hohen Standards in Bezug auf Verfügbarkeit, Leistung und Compliance erfüllen, die im Bankensektor erforderlich sind.

Abschließende Empfehlungen

Die Implementierung einer Active-Active Architektur in einer regulierten und eingeschränkten Umgebung wie dem Bankensektor erfordert strategische Entscheidungen und ein klares Verständnis der Einschränkungen. Auf der Grundlage unserer Erfahrung lauten die abschließenden Empfehlungen wie folgt:

  1. Bewertung der Notwendigkeit einer Active-Active-Konfiguration: Nicht alle Anwendungen erfordern ein 99,99-prozentiges Verfügbarkeitsziel, und eine Active-Active-Konfiguration ist nicht immer notwendig. Viele Anwendungen können auch mit etwas niedrigeren Verfügbarkeitszielen effektiv funktionieren, wobei eine Konfiguration mit einer einzigen Region und robusten Failover- und Disaster-Recovery-Mechanismen eine ausreichende Ausfallsicherheit bieten kann.
    • Beispielsweise muss eine lokale Unternehmenskantine-Webanwendung, die Mitarbeiter während der Geschäftszeiten nutzen, um Menüs anzuzeigen oder Mittagessen zu bestellen, nicht zu 99,99 % verfügbar sein. In solchen Fällen ist eine Bereitstellung in einer einzelnen Region mit einer an die Betriebszeiten angepassten Betriebszeit sowohl praktisch als auch kosteneffizient. Dieser Ansatz ermöglicht es, kritische Ressourcen auf Systeme zu konzentrieren, die wirklich eine hohe Verfügbarkeit erfordern.
    • Berücksichtigen Sie bei der Entscheidung für eine Architektur die Kritikalität der Anwendung, die Erwartungen der Benutzer und die Kostenauswirkungen. Bei nicht kritischen Arbeitslasten ist die zusätzliche Komplexität und der Aufwand einer Active-Active-Konfiguration möglicherweise nicht gerechtfertigt, sodass Ressourcen auf andere Prioritäten konzentriert werden können. Richten Sie die Architektur immer an den spezifischen Verfügbarkeitsanforderungen und Geschäftszielen der Anwendung aus.
  2. Verstehen Sie die Umgebung frühzeitig: Führen Sie eine detaillierte Bewertung der Compliance-Anforderungen, Netzwerkbeschränkungen und Serviceverfügbarkeit durch, um potenzielle Hindernisse zu identifizieren, bevor Sie die Architektur entwerfen.
  3. Priorisieren Sie Einfachheit, wo möglich: Während multi- und regionenübergreifende Setups von entscheidender Bedeutung sind, kann ein Übermaß an Technik zu unnötiger Komplexität führen. Entscheiden Sie sich für einfachere Lösungen, wenn diese die Leistungs- und Compliance-Anforderungen erfüllen. Dieser Ansatz steht im Einklang mit dem Konzept der Zufriedenstellung, das in Models of Man: Social and Rational von Herbert A. Simon eingeführt wurde und das vorschlägt, eine Lösung zu finden, die die Kriterien für Angemessenheit erfüllt, anstatt eine optimale, aber übermäßig komplexe Lösung anzustreben.
  4. Nutzen Sie die regionale Unabhängigkeit: Minimieren Sie strategisch regionenübergreifende Abhängigkeiten, bei denen Latenz, Leistung oder Compliance im Vordergrund stehen, und sorgen Sie gleichzeitig für eine ausreichende regionenübergreifende Koordination, um Failover, Konsistenz und die Vorteile einer Active-Active-Konfiguration zu gewährleisten.
  5. Planen Sie Skalierbarkeit und Ausfallsicherheit ein: Planen Sie für Datenverkehrsspitzen und unerwartete Ausfälle, indem Sie automatische Skalierung und robuste Failover-Mechanismen verwenden. Stellen Sie sicher, dass Überwachung und Beobachtbarkeit im Mittelpunkt der Architektur stehen.
  6. Kosten sorgfältig optimieren: Leistungsanforderungen und Kosteneffizienz durch die richtige Dimensionierung von Ressourcen und die Minimierung von regionenübergreifenden Datenübertragungen in Einklang bringen. Cloud-Ausgaben regelmäßig überprüfen und optimieren.
  7. Bei Bedarf einen hybriden Ansatz verwenden: Mehrere Designs kombinieren, um unterschiedliche Anforderungen zu erfüllen, z. B. regionale Lastverteilung für lokale Arbeitslasten und regionenübergreifende Lösungen für kritische globale Dienste.

Die Implementierung einer Active-Active Architektur ermöglicht Banken, effektiv auf Veränderungen im Markt zu reagieren und gleichzeitig Risiken zu minimieren.

Schlussfolgerung

Die Entwicklung einer Active-Active Architektur in Google Cloud für den Bankensektor ist sowohl herausfordernd als auch lohnend. Die eingeschränkte Umgebung stellte zwar erhebliche Einschränkungen dar, führte aber auch zu innovativen Lösungen, die auf die individuellen Bedürfnisse des Kunden zugeschnitten sind. Die erfolgreiche Umsetzung des fünften Entwurfs unter Nutzung regionaler interner L4-Lastverteiler zeigt den Wert eines durchdachten und anpassungsfähigen Ansatzes.

Durch die Berücksichtigung wichtiger Aspekte wie Compliance, Leistung und Skalierbarkeit bietet diese Architektur die Ausfallsicherheit und Hochverfügbarkeit, die im Bankensektor gefordert wird. Die hier geteilten Erkenntnisse und Erfahrungen können anderen Organisationen, die vor ähnlichen Herausforderungen stehen, als Leitfaden dienen und sie in die Lage versetzen, robuste und zukunftssichere Systeme aufzubauen.

Um wettbewerbsfähig und relevant zu bleiben, müssen Banken ihre Transformation beschleunigen und ihre Architekturen kontinuierlich weiterentwickeln, um neue Technologien zu integrieren und den sich ständig weiterentwickelnden regulatorischen Anforderungen gerecht zu werden. Die Zeit zum Handeln ist jetzt.

Weiterführende Literatur

Für diejenigen, die sich eingehender mit Active-Active-Architekturen, Cloud-Lösungen und den spezifischen Herausforderungen des Bankensektors befassen möchten, finden Sie hier einige empfohlene Ressourcen: