AWS Summit - Résilience à l’échelle
🛠️

AWS Summit - Résilience à l’échelle

Résilience à l’échelle : les secrets d’Amazon, ou, comment l’application d’un ensemble de bonnes pratiques permettent d’obtenir un niveau de service optimal.

Lors de notre participation à l’AWS Summit 2024 du 4 avril, nous avons pu assister à une breakout session sur la résilience à l’échelle.

Cette session avait pour objectif de présenter l’approche d’Amazon pour assurer la résilience et la scalabilité de leurs principaux services, notamment Amazon.com, Prime Video, Music, Ring et Alexa.

Démarrage par une définition de la résilience suivie de quelques chiffres permettant de mesurer la dimension dantesque du challenge Prime Day (126 millions de req/s pour DynamoDB, 318 milliards de transactions et 2140 TB de stockage sur Amazon Aurora pour n’en citer que deux en 2023).

Première notion évidente, l’architecture en microservices, où chaque élément d’une fiche produit en vente sur Amazon est un micro-service indépendant permettant ainsi d’assurer la résilience et de limiter l’impact en cas de dysfonctionnement. S’ensuit la notion d’architecture cellulaire qui consiste à concevoir chaque service divisible en x cellules indépendantes, chaque pool de clients étant assigné à une cellule. Là encore, cette conception permet d’être totalement scalable et résilient, un dysfonctionnement n’impactant qu’un nombre réduit de cellules et donc de clients.

Plus en détail, le premier cas d’utilisation concerne Amazon Prime Vidéo, dont l’architecture est régionale, mais comme expliqué précédemment, découpé en micro-services puis en plusieurs cellules, permettant ainsi d’isoler les pannes.

image

Dans la même optique, le trafic est également géré de manière cellulaire, le routage côté Route53 est d’abord opéré en RoundRobin, puis en Géo-Proximité vers la région la plus proche.

image

Dans ce cas d’usage, cette conception a permis d’améliorer la disponibilité d’Amazon Prime Vidéo à 99,9996 %, notamment par une meilleure capacité de bascule grâce à la cellularisation.

Second cas d’usage, Amazon Music. Là encore, la conception cellulaire a permis d’établir des affinités par type d’appareils (iOS, Android), ou par type d’événements, réduisant ainsi le rayon d’impact des pannes (-92 %) et diminuant le délai de traitements des événements, car isolés par type d’appareil.

Troisième cas d’usage, l’architecture événementielle de Ring. Cette dernière était composée de buckets S3 pour la réception d’artefacts vidéo pré et post traitement, de files SQS pour la gestion des événements, et de flottes d’EC2 pour réaliser l’encodage, l’ensemble étant supervisé et piloté par Cloudwatch/StepFunction pour assurer la scalabilité de la plateforme.

Cette architecture était optimisée pour réduire la latence sur le visionnage des vidéos. Ayant pour objectif d’optimiser la latence globale sur la totalité des événements, elle a été repensée en mode cellulaire via des clusters ECS pour les APIS et le routage, des lambdas associés à Amazon MSK pour le DataPlane, puis des queues SQS et d’autres clusters ECS pour la consommation d'événements. Le pattern Circuit Breaker a également été implémenté entre le routage et le DataPlane.

Cette refonte d’architecture permet aujourd’hui d’absorber des pics d’utilisation à 465 millions de demandes par heure et par région (Us-East-1 lors d’un Halloween par exemple) et d’assurer 99,9999 % de disponibilité malgré des pics de à 129k messages par seconde.

Enfin, le dernier cas d’usage présenté était celui d’Alexa. La croissance de 3 à 4 millions d’utilisateurs à chaque Prime Day nécessitait une amélioration de la résilience. Ce cas d’usage a été nettement moins détaillé que les précédents, mais a démontré l’intérêt de l’utilisation du service de chaos engineering AWS FIS (pour Fault Injection Service) pour simuler et reproduire des pannes, d’une latence réseau à la perte d’une région AWS.

En conclusion, cette session a permis de démontrer que l’usage de patterns éprouvés, comme les micro-services, les architectures cellulaires ou encore les circuits breaker, permet d’obtenir une résilience optimale, et ce, quelle que soit l’échelle de vos applications. L’usage du service FIS est également un vrai plus pour valider la résilience de vos architectures.

Un grand merci à Aurélia Pinhel et Florian Blond (Solutions Architects chez AWS) pour cette session !

Article issu de notre participation à AWS Summit

Merci pour votre lecture. Cet article vous a plu, partagez sur vos réseaux 😉

Michaël Vicaire - avril, 2024

image