2.5 - Orchestration, analytique et services edge

1. Une charge relationnelle à forte lecture a des utilisateurs mondiaux et exige des lectures en millisecondes à un chiffre dans chaque Région, plus une copie promouvable pour un basculement régional. Quelle conception de base convient ?

• Amazon Aurora Global Database avec Régions secondaires (bonne réponse)
• Une unique instance RDS Multi-AZ avec des réplicas de lecture dans une Région
• DynamoDB global tables avec cohérence forte partout
• RDS avec snapshots automatiques cross-Region restaurés à la demande

Aurora Global Database réplique vers des Régions secondaires avec ~1 seconde de retard, sert des lectures locales à faible latence et permet de promouvoir une secondaire pour un basculement régional. RDS mono-Région n'offre pas de lectures locales mondiales ; DynamoDB n'est pas relationnel et les global tables sont à cohérence à terme entre Régions ; la restauration de snapshot est lente.

2. Un processus d'approbation de prêt enchaîne plusieurs fonctions Lambda avec branchements, attentes et reprises, et l'équipe veut que la logique du workflow soit visible et auditable plutôt qu'enfouie dans du code qui appelle lui-même la fonction suivante. Quel service doit l'orchestrer ?

• Une unique grosse fonction Lambda qui invoque les autres en séquence en interne
• Amazon SQS enchaînant chaque fonction à la suivante via des files distinctes
• AWS Step Functions modélisant le workflow comme une machine à états (bonne réponse)
• Amazon EventBridge Scheduler déclenchant les fonctions sur des minuteurs fixes

Step Functions exprime branchements, attentes, reprises et gestion d'erreurs sous forme de machine à états visuelle et auditable et gère l'état entre les étapes, donc l'orchestration sort du code des fonctions. Une méga-fonction masque le flux et couple les étapes, les chaînes SQS n'ont pas de branchement/visualisation natifs, et Scheduler ne fait que déclencher sur minuteurs.

3. Un chemin d'ingestion de clickstream à fort volume exécute un workflow très court et sans état des millions de fois par jour et exige le coût par exécution le plus bas, en acceptant une sémantique at-least-once sans historique d'exécution durable. Quel type de workflow Step Functions convient ?

• Un workflow Standard, qui enregistre l'historique complet d'exécution jusqu'à 90 jours
• Un workflow Express optimisé pour des exécutions à fort volume et courte durée (bonne réponse)
• Un workflow Standard avec un état Map ajouté pour traiter les éléments en parallèle
• Un worker Activity interrogeant un workflow Standard depuis des instances EC2

Les workflows Express sont tarifés pour de très forts débits d'événements et de courtes durées avec exécution at-least-once et sans historique durable par exécution, ce qui en fait le choix le moins cher pour des millions d'exécutions courtes. Les workflows Standard offrent exactly-once et l'historique complet mais coûtent plus par exécution, superflu ici.

4. Un monolithe est décomposé en microservices. Les architectes veulent que les services évoluent et se déploient indépendamment et éviter qu'une base de données unique devienne un point de couplage où le changement de schéma d'une équipe casse un autre service. Quels DEUX choix de conception soutiennent cela ? (Choisissez DEUX réponses.)

• Donner à chaque service son propre stockage privé, accédé uniquement via son API (bonne réponse)
• Partager une unique base relationnelle centrale que tous les microservices lisent et écrivent directement
• Faire communiquer les services via des API bien définies et des événements asynchrones (bonne réponse)
• Laisser chaque service accéder aux tables des autres services quand il a besoin de leurs données

Donner à chaque service un stockage privé derrière sa propre API (base par service) et communiquer via API et événements permet aux équipes de changer les schémas internes et de déployer indépendamment sans casser les autres. Une base partagée et l'accès aux tables d'autrui recréent le couplage fort, le problème même que la décomposition doit supprimer.

5. Un workflow Step Functions appelle une tâche qui échoue parfois sur une erreur transitoire et, lors de rares échecs permanents, doit exécuter une étape de nettoyage compensatoire plutôt que d'interrompre toute l'exécution. Quel mécanisme intégré gère cela dans la machine à états ?

• Un Retry avec backoff pour les erreurs transitoires et un Catch qui route vers un état de nettoyage (bonne réponse)
• Une alarme CloudWatch globale qui redémarre toute l'exécution depuis le début
• Un Lambda externe qui interroge le statut de l'exécution et relance les tâches échouées
• Envelopper toute la machine à états dans un seul bloc try/except à l'intérieur d'une unique fonction Lambda

Les états Step Functions supportent un bloc Retry (avec backoff) pour les erreurs transitoires et un bloc Catch qui transitionne vers un état de nettoyage compensatoire sur des erreurs définies, le tout nativement sans code externe. Un redémarrage global sur alarme est grossier, un poller externe réinvente le comportement intégré, et tout regrouper dans un seul Lambda supprime l'orchestration.

6. Une application SaaS mondiale doit servir des lectures et écritures en millisecondes à un chiffre à des utilisateurs sur trois continents, avec des écritures locales acceptées dans chaque Région et des conflits résolus automatiquement. Quel magasin de données convient le mieux ?

• Amazon RDS for PostgreSQL avec un réplica de lecture cross-Region par Région
• Amazon Aurora avec un seul writer et des réplicas de lecture dans chaque Région
• Amazon DynamoDB global tables répliquées entre les trois Régions (bonne réponse)
• Amazon ElastiCache for Redis en clusters déployés indépendamment dans chaque Région

DynamoDB global tables offrent des lectures/écritures multi-actives multi-Régions avec résolution de conflit last-writer-wins et une latence locale en millisecondes à un chiffre. RDS et Aurora n'acceptent d'écritures que dans une seule Région (les réplicas sont en lecture seule), et ElastiCache est un cache, pas une source de vérité.