Übersicht

AWS-Edge-Services sind wichtige Komponenten für die Erstellung von Webanwendungen mit hoher Verfügbarkeit. Zusätzlich zu ihrer nativen Hochverfügbarkeit dank ihres verteilten Charakters dienen die AWS-Edge-Services als Einstiegspunkt für Webanwendungen und können Anfragen an verfügbare Partitionen in Ihrer ursprünglichen Infrastruktur weiterleiten (z. B. Verfügbarkeitszone oder Region).

Architektur-Entscheidungen

Eine hochverfügbare Webanwendung kann auf verschiedene Arten konzipiert werden, je nach Ihren Anforderungen in Bezug auf Verfügbarkeit, SLO, Kosten und Komplexität. Auf der Grundlage Ihrer Geschäftsanforderungen sollten Sie mindestens die folgenden technischen Entscheidungen treffen:

  • Haben Sie eine Aktiv/Aktiv- oder eine Aktiv/Passiv-Architektur?
  • Haben Sie unterschiedliche Ursprünge? Verschiedene AZs? Verschiedene Regionen?
  • Welche Routing-Logik zwischen den Ursprüngen nutzen Sie für eine Aktiv/Aktiv-Architektur? Was sind die Failover-Kriterien für eine Aktiv/Passiv-Architektur?

Umgang mit vorübergehenden Ursprungsfehlern

CloudFront kann Ihnen helfen, die Auswirkungen vorübergehender 5xx-Fehler zu mindern, die gelegentlich eine kleine Anzahl von Benutzeranfragen beeinträchtigen können. Oft ist dies auf eine Überlastung durch plötzliche Datenverkehrsspitzen oder vorübergehende Netzwerkprobleme zurückzuführen. Sie können vorübergehende 5xx-Fehler mit CloudFront auf verschiedene Arten mindern.

Wiederholen. CloudFront kann so konfiguriert werden, dass die TCP-Verbindungsherstellung bis zu dreimal mit einem konfigurierbaren Verbindungs-Timeout wiederholt wird, wenn keine Verbindung mit dem Ursprung möglich ist. Außerdem versucht CloudFront entsprechend der konfigurierten Anzahl von Wiederholungen idempotente GET/HEAD-Anfragen.

Mit veralteten Inhalten antworten. Wenn die Wiederholungsversuche mit dem Ursprung fehlschlagen, stellt CloudFront standardmäßig eine veraltete Version des Objekts bereit, sofern sie im Cache verfügbar ist, anstatt eine Fehlerantwort zurückzugeben. Dieses Verhalten kann mit der Anweisung Cache-Control: stale-if-error=0 deaktiviert werden.

Origin Failover zum sekundären Ursprung. Mithilfe der Origin Failover-Funktion können Sie CloudFront so konfigurieren, dass für die entsprechende fehlgeschlagene Anfrage ein Failover an einen sekundären Ursprung durchgeführt wird. Origin Failover gilt nur für idempotente GET/HEAD-Anfragen. Beachten Sie, dass CloudFront die Funktion auch beim Failover ausführt, wenn Sie Lambda@Edge für Ursprungsereignisse verwenden. In diesem Szenario können Sie in der Lambda@Edge-Funktion ableiten, ob die Anfrage an den primären oder den sekundären Ursprung gerichtet war, um die Logik zu unterscheiden. Dazu konfigurieren Sie in beiden Ursprüngen denselben benutzerdefinierten Ursprungs-Header, allerdings mit unterschiedlichen Werten, die Lambda@Edge lesen kann.

Graceful Failover. Wenn ein Origin Failover zu einem anderen Ursprung nicht wünschenswert ist (z. B. Verwaltung einer anderen Ursprungsinfrastruktur), sollten Sie ein Failover auf eine statische Datei in Betracht ziehen, die an einem anderen Standort gehostet wird (z. B. in einem S3-Bucket). Dazu verwenden Sie eine benutzerdefinierte Fehlerseite. Standardmäßig wird dieselbe Seite für alle Anfragen verwendet, die zu Fehlern führen. Sie können jedoch eine dynamischere Antwort erstellen, wenn Sie dem dritten Muster in diesem Blog folgen.

Stateful Failover bei Ursprungsausfällen

Failover basierend auf der Route-53-Richtlinie

Sie können die Failover-Routing-Richtlinie von Route 53 mit Zustandsprüfungen für den Namen der Ursprungsdomain verwenden, der in CloudFront als Ursprung konfiguriert ist. Wenn der primäre Ursprung fehlerhaft wird, erkennt Route 53 diesen Zustand und beginnt, den Namen der Ursprungsdomain mit der IP-Adresse des sekundären Ursprungs aufzulösen. CloudFront berücksichtigt die Quell-DNS-TTL, was bedeutet, dass der Datenverkehr innerhalb der DNS-TTL zum sekundären Ursprung geleitet wird. Die optimale Konfiguration (Fast Check aktiviert, ein Failover-Schwellenwert von 1 und eine DNS-TTL von 60 Sekunden) bedeutet, dass es mindestens 70 Sekunden dauert, bis das Failover erfolgt. Der gesamte Datenverkehr wird dann auf den sekundären Ursprung umgeleitet, da es sich um ein Stateful Failover handelt. Dieses Design kann mit Route 53 Application Recovery Control erweitert werden, um ein komplexeres Anwendungs-Failover in mehreren AWS-Regionen, Availability Zones und On-Premises zu ermöglichen. Dieser Ansatz kann mit der Origin-Failover-Funktionalität von CloudFront für GET/HEAD-Anfragen kombiniert werden, um Fehler zu reduzieren, wenn Route 53 einen Failover zum sekundären Ursprung durchführt. Das Muster wird in diesem Blog beschrieben.

Wenn die verschiedenen Ursprünge nicht denselben Domainnamen haben, z. B. für S3-basierte Ursprünge, kann Route 53 nicht auf die oben vorgeschlagene Weise verwendet werden. In diesem Szenario benötigen Sie eine für das Ursprungsanfrage-Ereignis konfigurierte Lambda@Edge-Funktion, um in Route 53 abzufragen, welcher Ursprung ausgewählt werden soll. Dann müssen Sie die Anfrage an den ausgewählten Ursprung umleiten, indem Sie den Namen der Ursprungsdomain und den Host-Header ändern. Weitere Informationen zu dieser Implementierung finden Sie in dieser Contentful-Fallstudie.

Failover mit Global Accelerator

Anwendungen, die Global Accelerator verwenden, können von den nativen Failover-Funktionen profitieren. Mit Global Accelerator kann Ihre Anwendung in einer einzigen AWS-Region über mehrere Availability Zones oder über mehrere AWS-Regionen hinweg bereitgestellt werden. Global Accelerator überwacht den Zustand Ihrer Anwendungsendpunkte mithilfe von Zustandsprüfungen und leitet den Datenverkehr innerhalb von Sekunden von fehlerhaften Endpunkten weg.

Aktiv-Aktiv-Architekturen

Latenzbasiertes Routing

CloudFront kann mit der latenzbasierten Route-53-Richtlinie verwendet werden, um Benutzeranfragen an die nächstgelegene AWS-Region weiterzuleiten, in der Sie den Ursprung in einer multiregionalen Aktiv-Aktiv-Architektur repliziert haben. Dazu konfigurieren Sie den Namen der Ursprungsdomain in CloudFront mit einer latenzbasierten Richtlinie in Route 53. Wenn CloudFront den Namen der Ursprungsdomain auflöst, um eine Verbindung herzustellen und die Anfrage an den Ursprung zu senden, gibt Route 53 basierend auf der Latenz die nächstgelegene Quell-IP zurück. Der Standort, von dem CloudFront den Namen der Ursprungsdomain auflöst, hängt von der Verteilungskonfiguration und dem Datenverkehrstyp ab. Im Allgemeinen wird der Domainname für dynamische Anfragen im Edge-Standort und für cachefähige Inhalte in regionalen Edge-Caches aufgelöst. Dieser Blog führt Sie durch eine multiregionale Aktiv-Aktiv-Bereitstellung für API Gateway.

Wenn die verschiedenen Ursprünge nicht denselben Domainnamen haben, z. B. für S3-basierte Ursprünge, kann Route 53 nicht auf die oben vorgeschlagene Weise verwendet werden. In dem Fall benötigen Sie eine für das Ursprungsanfrage-Ereignis konfigurierte Lambda@Edge-Funktion zur Weiterleitung an den nächstgelegenen Ursprung. Weitere Informationen zu dieser Implementierung finden Sie in den folgenden Blogs:

Erweitertes Routing

In bestimmten Szenarien erfordert das Routing von Anfragen eine Logik auf Anwendungsebene. Wenn die Logik einfach ist, z. B. Routing an verschiedene Ursprünge basierend auf dem Pfad (Beispiel: /api1 an Ursprung 1 und /api2 an Ursprung 2 weiterleiten), können Sie das native Cache-Verhalten von CloudFront verwenden. Wenn die Logik ausgefeilter ist, können Sie mit Lambda@Edge für ein Ursprungsanfrage-Ereignis den Datenverkehr anhand von Attributen auf Anwendungsebene weiterleiten, z. B. URL, Cookies, Header und Land. Die Logik kann zustandslos und vollständig in den Funktionscode eingebettet sein oder an einem externen Ort wie S3 oder DynamoDB gespeichert werden, von dem Lambda@Edge die Routing-Regel für die Ausführung abruft.

Ressourcen

War diese Seite hilfreich?

 Feedback