Présentation

Les services de périphérie AWS sont des composants importants pour créer des applications Web à haute disponibilité. Outre leur haute disponibilité native due à leur nature distribuée, les services de périphérie AWS font office de point d'entrée vers les applications Web et peuvent acheminer les demandes vers les partitions disponibles dans votre infrastructure d'origine (par exemple, zone de disponibilité ou région).

Décisions architecturales

Une application Web à haute disponibilité peut être conçue de différentes manières, en fonction de vos besoins en termes de disponibilité SLO, de coût et de complexité. Au minimum, vous devez prendre les décisions techniques suivantes en fonction des besoins de votre entreprise :

  • Disposez-vous d'une architecture active/active ou active/passive ?
  • Avez-vous des origines différentes ? des AZ différents ? des régions différentes ?
  • Quelle est la logique de routage entre les origines pour une architecture active/active ? Quels sont les critères de basculement pour une architecture active/passive ?

Gestion des erreurs d'origine transitoires

CloudFront peut vous aider à atténuer l'impact des erreurs 5xx transitoires qui peuvent parfois affecter un petit nombre de demandes des utilisateurs. Cela est souvent dû à une origine submergée par des pics de trafic soudains ou des problèmes de réseau transitoires. Vous pouvez atténuer les erreurs 5xx transitoires avec CloudFront de différentes manières.

Réessayez. CloudFront peut être configuré pour réessayer la connexion TCP jusqu'à trois fois avec un délai de connexion configurable lorsqu'une connexion ne peut pas être établie avec l'origine. CloudFront relance également les GET/HEAD idempotents en fonction du nombre de tentatives configuré.

Répondre avec un contenu obsolète. Si les nouvelles tentatives échouent avec l'origine, CloudFront par défaut diffuse une version obsolète de l'objet si elle est disponible dans le cache au lieu de renvoyer une réponse d'erreur. Ce comportement peut être désactivé à l'aide de la directive Cache-Control: stale-if-error=0.

Basculement de l'origine vers l'origine secondaire. Vous pouvez configurer CloudFront pour qu'il bascule vers une origine secondaire pour la demande échouée spécifique à l'aide de la fonctionnalité Origin Failover. Origin Failover ne s'applique qu'aux demandes GET/HEAD idempotentes. Notez que si vous utilisez Lambda@Edge sur les événements d'origine, CloudFront exécute également la fonction en cas de basculement. Dans ce scénario, vous pouvez déduire dans la fonction Lambda@Edge si la demande concernait l'origine principale ou secondaire afin de différencier sa logique. Pour ce faire, configurez le même Origin Custom Header dans les deux origines, mais avec des valeurs différentes que Lambda@Edge peut lire.

Basculement gracieux. Si le basculement d'Origin Failover vers une autre origine n'est pas souhaitable (par exemple, maintenir une autre infrastructure d'origine), envisagez de basculer vers un fichier statique hébergé dans un emplacement différent (par exemple, un compartiment S3) à l'aide de la Page d'erreur personnalisée. Par défaut, la même page est utilisée pour toutes les demandes qui génèrent des erreurs, mais vous pouvez créer une réponse plus dynamique en suivant le troisième modèle de ce blog.

Basculement dynamique lors des pannes d'origine

Basculement basé sur la politique de Route 53

Vous pouvez utiliser la politique de routage de Basculement de Route 53 avec des surveillances de l'état sur le nom de domaine d'origine configuré comme origine dans CloudFront. Lorsque l'origine principale devient défectueuse, Route 53 la détecte, puis commence à résoudre le nom de domaine d'origine avec l'adresse IP de l'origine secondaire. CloudFront respecte le TTL DNS d'origine, ce qui signifie que le trafic commencera à circuler vers l'origine secondaire au sein du TTL DNS. La configuration la plus optimale (Fast Check activé, seuil de basculement de 1 et TTL DNS de 60 secondes) signifie que le basculement prendra au moins 70 secondes pour se produire. Dans ce cas, tout le trafic est transféré vers l'origine secondaire, car il s'agit d'un basculement dynamique. Notez que cette conception peut être encore étendue avec le Contrôle de récupération de l'application de Route 53 pour un basculement d'applications plus sophistiqué dans plusieurs régions AWS, zones de disponibilité et sur site. Cette approche peut être combinée avec la fonctionnalité CloudFront Origin Failover pour les demandes GET/HEAD afin de réduire les erreurs pendant que Route 53 bascule vers l'origine secondaire. Ce modèle est décrit dans ce blog.

Lorsque les différentes origines ne partagent pas le même nom de domaine, comme pour les origines basées sur S3, Route 53 ne peut pas être utilisée de la manière proposée ci-dessus. Dans ce scénario, vous avez besoin d'une fonction Lambda@Edge configurée sur l'événement de demande d'origine pour interroger Route 53 sur l'origine à sélectionner, puis réacheminer la demande vers l'origine sélectionnée, en modifiant le nom de domaine d'origine et avec l'en-tête hôte. Pour en savoir plus sur cette implémentation, lisez l'étude de cas suivante.

Basculement avec Global Accelerator

Les applications qui utilisent Global Accelerator peuvent bénéficier de ses fonctionnalités de basculement natives. À l'aide de Global Accelerator, votre application peut être déployée dans une seule région AWS dans plusieurs zones de disponibilité ou dans plusieurs régions AWS. Global Accelerator surveille l'état des points de terminaison de vos applications à l'aide des surveillances de l'état, et éloigne le trafic des points de terminaison défectueux en quelques dizaines de secondes.

Architectures active-active

Routage basé sur la latence

CloudFront peut être utilisé avec la politique basée sur la latence de Route 53 pour acheminer les demandes des utilisateurs vers la région AWS la plus proche dont vous avez répliqué l'origine dans une architecture multirégionale Active-Active. Pour ce faire, configurez le nom de domaine d'origine dans CloudFront avec une politique basée sur la latence dans Route 53. Lorsque CloudFront résout le nom de domaine d'origine pour se connecter et envoyer la demande à l'origine, Route 53 renvoie l'adresse IP d'origine la plus proche en fonction de la latence. Notez que l'emplacement à partir duquel CloudFront résout le nom de domaine d'origine dépend de la configuration de distribution et du type de trafic. En général, le nom de domaine est résolu dans l'emplacement périphérique pour les demandes dynamiques et dans les caches périphériques régionaux pour le contenu pouvant être mis en cache. Ce blog vous accompagne dans un déploiement multi-régions actif-actif pour la passerelle API.

Lorsque les différentes origines ne partagent pas le même nom de domaine, comme pour les origines basées sur S3, Route 53 ne peut pas être utilisée de la manière proposée ci-dessus. Dans ce scénario, vous avez besoin d'un événement de demande Lambda@Edge configuré sur l'origine pour acheminer vers l'origine la plus proche. Pour en savoir plus sur cette implémentation, consultez les blogs suivants :

Routage avancé

Dans certains scénarios, le routage des demandes nécessite une logique au niveau de l'application. Lorsque la logique est simple, comme le routage vers différentes origines en fonction du chemin (par exemple, route /api1 vers l'origine 1 et /api2 vers l'origine 2), vous pouvez simplement utiliser la fonctionnalité de comportement de cache native de CloudFront. Si la logique est plus sophistiquée, Lambda@Edge sur l'événement de demande d'origine vous permet d'acheminer le trafic sur la base d'attributs au niveau de l'application, tels que l'URL, les cookies, les en-têtes, le pays, etc. La logique peut être sans état et entièrement intégrée au code de la fonction, ou elle peut être stockée dans un emplacement externe tel que S3 ou DynamoDB à partir duquel Lambda@Edge extrait la règle de routage pour l'exécuter.

Ressources

Cette page vous a-t-elle été utile ?

 Commentaires