Aufbau eines stabilen öffentlichen Netzwerks auf AWS - Teil 5 - Verwaltung von HTTP-Clients und persistenten TCP-Verbindungen für Failover

Willkommen zum abschließenden Kapitel unserer Blog-Serie. Im Laufe dieser Serie haben wir uns mit fortschrittlichen Netzwerkstrategien für regionale Evakuierung, Failover und robuste Disaster Recovery beschäftigt. Lassen Sie uns unsere Reise rekapitulieren:

Wie in früheren Beiträgen haben wir ein GitHub-Repository, das diese Blog-Serie ergänzt. Es bietet Infrastructure as Code (IaC) unter Verwendung von AWS Cloud Development Kit (CDK), so dass Sie die erforderliche Infrastruktur mühelos bereitstellen und verwalten können.

Einführung

Wie bereits erwähnt, werden wir erörtern, wie sich persistente TCP-Verbindungen auf die in dieser Serie behandelten Failover- und Disaster Recovery-Strategien auswirken und warum es wichtig ist, dieses Verhalten zu berücksichtigen, um eine nahtlose Verfügbarkeit der Anwendungen zu gewährleisten.

In den vorangegangenen Blogbeiträgen haben wir zwei regionale Evakuierungsstrategien zur Verbesserung der Widerstandsfähigkeit untersucht. Es gibt jedoch einen wichtigen Fehler: Diese Strategien sind nur wirksam, wenn HTTP-Clients neue TCP-Verbindungen aufbauen, denn nur dann wird der Datenverkehr korrekt an eine gesunde Region weitergeleitet.

Im Allgemeinen funktioniert die Ausfallsicherung wie erwartet, wenn ein Backend ausfällt und aufgrund einer Verzögerung der Antwort Timeouts verursacht. In diesen Fällen unterbrechen diese Zeitüberschreitungen bestehende TCP-Verbindungen, so dass HTTP-Clients neue Verbindungen erstellen, die an eine gesunde Region weitergeleitet werden.

Aber was passiert, wenn das Backend schnell mit einem Fehler antwortet, anstatt die Zeit zu stoppen? In diesem Szenario kann der HTTP-Client den Versuch schnell wiederholen und die bestehende TCP-Verbindung aufrechterhalten. Dadurch entsteht eine Rückkopplungsschleife, die verhindert, dass die Verbindung in eine andere Region umgeleitet wird, was zu einem verschlechterten Failover-Verhalten führt.

Lassen Sie uns diese kritische Herausforderung genauer unter die Lupe nehmen und untersuchen, wie wir sie angehen können.

Warum HTTP-Clients dauerhafte TCP-Verbindungen verwenden

Persistente TCP-Verbindungen bieten erhebliche Leistungsvorteile, da sie die Latenzzeit für jede HTTP-Anfrage verringern. Anstatt für jede Anfrage eine neue Verbindung zu öffnen, verwenden die Clients eine bestehende Verbindung wieder und vermeiden so den Overhead, der durch den wiederholten Aufbau neuer Verbindungen entsteht.

Jede neue Verbindung verursacht eine Latenzzeit:

Durch die Aufrechterhaltung einer dauerhaften Verbindung vermeiden HTTP-Clients diese Schritte und verringern so die Latenzzeit beim Senden wiederholter HTTP-Anfragen.

Gängige HTTP-Clients zum Testen

Es ist auch wichtig zu wissen, dass sich verschiedene HTTP-Clients unterschiedlich verhalten, was sich auf die Testergebnisse auswirken kann. Wenn Sie wissen, wie die einzelnen Clients mit persistenten TCP-Verbindungen umgehen, können Sie Ihre Failover-Strategien genau bewerten.

Nachfolgend finden Sie eine Übersicht über die gängigen HTTP-Clients, die zum Testen verwendet werden:

Berücksichtigen Sie die oben beschriebenen Details, wenn Sie Failover und Disaster Recovery testen. Um das Verhalten von HTTP-Clients besser zu verstehen, lesen Sie unseren ersten Blogbeitrag in dieser Serie.

Demonstration der Auswirkungen von TCP Persistence auf regionales Failover

In diesem Abschnitt zeigen wir, wie persistente TCP-Verbindungen den regionalen Evakuierungsprozess stören können.

Für dieses Beispiel bauen wir auf der Infrastruktur aus unserem vorherigen Blog-Beitrag "Regionale Evakuierung mit statischem Anycast-IP-Ansatz - AWS Global Accelerator" auf. Sie könnten dieses Szenario auch mit der DNS-basierten Evakuierungsstrategie replizieren, die wir in unserem dritten Beitrag, "Regionale Evakuierung mit DNS-Ansatz - AWS Route 53", beschrieben haben .

Schritt 1 - Prüfen Sie, welches Ihre nächstgelegene AWS-Region ist

Um Ihre nächstgelegene Region zu ermitteln, können Sie den folgenden curl-Befehl verwenden, der eine Anfrage über den AWS Global Accelerator sendet und die Region zurückgibt, an die Ihre Anfrage weitergeleitet wird:

curl https://global-accelerator.subdomain-2.subdomain-1.cloudns.ph 
 { 
  "MessageResponse": "Region: us-east-1. HTTP Response code: 200. Delay response: 0 seconds.", 
  "SocketRequest": "::ffff:10.0.206.182:16068", 
  "HeadersRequest": { 
    "x-forwarded-for": "79.117.226.67", 
    "x-forwarded-proto": "https", 
    "x-forwarded-port": "443", 
    "host": "global-accelerator.subdomain-2.subdomain-1.cloudns.ph", 
    "x-amzn-trace-id": "Root=1-6787c723-0294604c58cfa08c3fc1bf48", 
    "user-agent": "curl/8.7.1", 
    "accept": "*/*" 
  }, 
  "HeadersResponse": { 
    "x-powered-by": "Express" 
  } 
} 

Nachdem wir geklärt haben, an welche Region unsere Anfragen weitergeleitet werden, können wir unsere Demo starten, indem wir einen HTTP-Client erstellen, der eine TCP-Verbindung aufrechterhält und diese Wiederholungsrichtlinie verwendet:

Um diesen HTTP-Client zu erstellen, werden wir Postman Retry Policy for Testingverwenden . Dieses Setup simuliert einen Client, der eine Stunde lang alle 30 Sekunden HTTP-Anfragen sendet.

‌

Schritt 2 - Simulieren des Ausfalls (us-east-1)

Sobald der vorherige HTTP-Client läuft, können wir einen Ausfall in einer Region simulieren. Dazu halten wir die Container in dieser Region an (in unserem Fall ist es us-east-1). Infolgedessen wird unser ALB ungesund und gibt einen HTTP 503 Fehlercode zurück, wenn er versucht, unseren Webserver zu erreichen.

Verwenden Sie die AWS-Konsole, um unsere Fargate-Aufgabenkonfiguration zu aktualisieren:

‌

Sobald die Container gestoppt werden, beginnen die ALB-Zustandsprüfungen zu versagen, was dazu führt, dass unsere ALB in einen ungesunden Zustand gerät. Dadurch wird AWS Global Accelerator veranlasst, den Datenverkehr nicht mehr an die ungesunde Region zu senden und ihn an die verbleibenden gesunden Regionen umzuleiten.

Schritt 3 - Neue TCP-Verbindungen werden an us-west-2 weitergeleitet

Um zu bestätigen, dass AWS Global Accelerator aufgehört hat, Datenverkehr an die ungesunde Region (us-east-1) zu senden und begonnen hat, Datenverkehr an die gesunden Regionen umzuleiten, können wir einen einfachen curl-Befehl verwenden. Wie bereits erwähnt, erstellt der curl-Befehl standardmäßig jedes Mal eine neue TCP-Verbindung, wenn wir eine HTTP-Anfrage senden.

curl https://global-accelerator.subdomain-2.subdomain-1.cloudns.ph   
{  
  "MessageResponse": "Region: us-west-2. HTTP Response code: 200. Delay response: 0 seconds.",  
  "SocketRequest": "::ffff:10.0.198.70:30538",  
  "HeadersRequest": {  
    "x-forwarded-for": "79.117.226.67",  
    "x-forwarded-proto": "https",  
    "x-forwarded-port": "443",  
    "host": "global-accelerator.subdomain-2.subdomain-1.cloudns.ph",  
    "x-amzn-trace-id": "Root=1-677fa9aa-16f2863a081d9dac08d359f2",  
    "user-agent": "curl/8.7.1",
    "accept": "*/*"  
  },  
  "HeadersResponse": {  
    "x-powered-by": "Express"  
  }  
} 

Schritt 4 - Alte TCP-Verbindungen erreichen immer noch us-east-1

Selbst nachdem der Datenverkehr zu us-west-2 umgeleitet wurde, können die vor dem Ausfall aufgebauten persistenten TCP-Verbindungen weiterhin versuchen, us-east-1 zu erreichen. In diesem Beispiel sendet Postman, das mit einer Wiederholungsrichtlinie alle 30 Sekunden konfiguriert ist, noch eine Stunde nach dem Ausfall Anfragen an die ungesunde Region. Dies verdeutlicht die Einschränkung von dauerhaften Verbindungen während regionaler Evakuierungen.

‌

Mögliche Lösungen

Um die Probleme, die durch anhaltende TCP-Verbindungen während regionaler Evakuierungen verursacht werden, zu mildern, können verschiedene Strategien helfen, das Verhalten der Clients zu steuern und die Reaktionsfähigkeit bei Failover zu verbessern. Im Folgenden finden Sie einige empfohlene Ansätze.

ALB-Konfiguration aktualisieren

Wenn Sie die Werte für den Leerlauf-Timeout in Ihrem Application Load Balancer (ALB) reduzieren, können Sie Verbindungen schneller schließen, aber dies ist mit Kompromissen verbunden, die die Leistung beeinträchtigen können.

Wichtige Timeout-Konfigurationen, die Sie berücksichtigen sollten:

Wenn Sie also diese Werte senken, können Sie schnellere Verbindungsabbrüche erzwingen, was bei einer Ausfallsicherung von Vorteil ist. Allerdings kann dies den Overhead erhöhen, da häufigere Verbindungs-Handshakes erforderlich sind, was die Leistung unter normalen Bedingungen beeinträchtigen kann.

Es ist wichtig, dass Denken Sie daran, dass bei Verwendung der Standard-ALB-Einstellungen eine TCP-Verbindung bis zu einer Stunde bestehen bleiben kann(HTTP Client Keep-Alive Duration), bevor der Client eine neue Verbindung herstellt. Unter zu diesem Zeitpunkt wird der Datenverkehr an eine gesunde Region weitergeleitet, aber eine Stunde zu warten ist vielleicht nicht machbar, wenn Sie eine sofortige Umleitung benötigen.

Erzwingen Sie Verbindungsabbrüche auf der Backend-Ebene

In Situationen, in denen die Leistung optimal bleiben muss und eine permanente Verringerung der Leerlaufzeit unerwünscht ist, kann das dynamische Erzwingen von Verbindungsabbrüchen eine flexiblere Lösung sein.

Schritte zur Implementierung dynamischer Verbindungsabbrüche:

Durch die Kombination dieser Strategien können Sie die Ausfallsicherheit und Reaktionsfähigkeit Ihrer regionalen Failover-Szenarien erheblich verbessern. Der optimale Ansatz hängt von Ihrer Kontrolle über Client-Anwendungen, Ihren spezifischen Infrastrukturanforderungen und Ihrer Toleranz gegenüber Kompromissen bei Verbindungslatenz und Leistung ab.

Zusätzliche Ressourcen