REL04-BP01 Identifier le type de systèmes distribués dont vous dépendez - AWS Well-Architected Framework
Directives d’implémentation

REL04-BP01 Identifier le type de systèmes distribués dont vous dépendez

Les systèmes distribués peuvent être synchrones, asynchrones ou par lots. Les systèmes synchrones doivent traiter les demandes le plus rapidement possible et communiquer entre eux en effectuant des appels de demande et de réponse synchrones à l’aide des protocoles HTTP/S, REST ou RPC (Remote Procedure Call). Les systèmes asynchrones communiquent entre eux en échangeant des données de manière asynchrone via un service intermédiaire sans coupler des systèmes individuels. Les systèmes par lots reçoivent un volume important de données d’entrée, exécutent des processus de données automatisés sans intervention humaine et génèrent des données de sortie.

Résultat souhaité : concevez une charge de travail qui interagit efficacement avec les dépendances synchrones, asynchrones et par lots.

Anti-modèles courants :

  • La charge de travail attend indéfiniment une réponse de la part de ses dépendances, ce qui peut entraîner une expiration des clients de la charge de travail, qui ne savent pas si leur demande a été reçue.

  • La charge de travail utilise une chaîne de systèmes dépendants qui s’appellent les uns les autres de manière synchrone. Cela nécessite que chaque système soit disponible et traite correctement une demande avant que l’ensemble de la chaîne puisse aboutir, ce qui entraîne un comportement et une disponibilité globale potentiellement fragiles.

  • La charge de travail communique avec ses dépendances de manière asynchrone et repose sur le concept de livraison garantie unique des messages, alors qu’il est souvent encore possible de recevoir des messages dupliqués.

  • La charge de travail n’utilise pas les outils de planification par lots appropriés et permet l’exécution simultanée de la même tâche de traitement par lots.

Avantages de la mise en place de cette bonne pratique : il est courant pour une charge de travail donnée de mettre en œuvre un ou plusieurs styles de communication (synchrone, asynchrone et par lots). Cette bonne pratique vous aide à identifier les différents compromis associés à chaque style de communication afin que votre charge de travail soit capable de tolérer les interruptions liées à toutes ses dépendances.

Niveau de risque exposé si cette bonne pratique n’est pas respectée : élevé

Directives d'implémentation

Les sections suivantes contiennent des instructions de mise en œuvre générales et spécifiques pour chaque type de dépendance.

Instructions générales

  • Assurez-vous que les objectifs de niveau de service (SLO) offerts vos dépendances en matière de performance et de fiabilité répondent aux exigences de performance et de fiabilité de votre charge de travail.

  • Utilisez les services d’observabilité AWS pour surveiller les temps de réponse et les taux d’erreur afin de vous assurer que votre dépendance fournit le service aux niveaux requis par votre charge de travail.

  • Identifiez les défis potentiels auxquels votre charge de travail peut être confrontée lors de la communication avec ses dépendances. Les systèmes distribués présentent un large éventail de défis susceptibles d’accroître la complexité architecturale, la charge opérationnelle et les coûts. Les défis courants incluent la latence, les perturbations du réseau, la perte de données, la mise à l’échelle et le retard de réplication des données.

  • Mettez en œuvre une gestion des erreurs et une journalisation robustes pour faciliter la résolution des problèmes lorsque votre dépendance rencontre des problèmes.

Dépendance synchrone

Dans les communications synchrones, votre charge de travail envoie une demande à sa dépendance et bloque l’opération en attente de réponse. Lorsque sa dépendance reçoit la demande, elle essaie de la traiter le plus rapidement possible et renvoie une réponse à la charge de travail. L’un des principaux défis liés à la communication synchrone est qu’elle entraîne un couplage temporel, ce qui nécessite que la charge de travail et ses dépendances soient disponibles en même temps. Lorsque la charge de travail doit communiquer de manière synchrone avec ses dépendances, suivez les conseils ci-dessous :

  • Votre charge de travail ne doit pas reposer sur plusieurs dépendances synchrones pour exécuter une seule fonction. Cette chaîne de dépendances augmente la fragilité globale, car toutes les dépendances sur le chemin doivent être disponibles pour que la demande soit traitée correctement.

  • Lorsqu’une dépendance n’est pas saine ou n’est pas disponible, déterminez vos stratégies de gestion des erreurs et de nouvelles tentatives. Évitez d’utiliser un comportement bimodal. On parle de comportement bimodal lorsque la charge de travail présente un comportement différent en mode normal et en mode d’échec. Pour plus d’informations sur le comportement bimodal, consultez REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux.

  • N’oubliez pas qu’il vaut mieux échouer rapidement que faire attendre la charge de travail. Par exemple, le Guide du développeur AWS Lambda décrit comment gérer les nouvelles tentatives et les échecs lorsque vous invoquez des fonctions Lambda.

  • Définissez des délais d’expiration lorsque la charge de travail appelle sa dépendance. Cette technique permet d’éviter d’attendre trop longtemps ou d’attendre indéfiniment une réponse. Pour une discussion utile sur ce problème, consultez la section Réglage des paramètres de demande HTTP du kit AWS Java SDK pour les applications Amazon DynamoDB prenant en charge la latence.

  • Réduisez le nombre d’appels passés entre la charge de travail et sa dépendance pour répondre à une seule demande. Le fait d’avoir trop d’appels entre elles augmente le couplage et la latence.

Dépendance asynchrone

Pour pouvoir découpler temporellement la charge de travail de sa dépendance, elles doivent communiquer de manière asynchrone. En utilisant une approche asynchrone, la charge de travail peut poursuivre tout autre traitement sans avoir à attendre que sa dépendance, ou sa chaîne de dépendances, envoie une réponse.

Lorsque la charge de travail doit communiquer de manière asynchrone avec sa dépendance, suivez les conseils ci-dessous :

  • Déterminez s’il convient d’utiliser la messagerie ou le streaming d’événements en fonction de votre cas d’utilisation et de vos exigences. La messagerie permet à votre charge de travail de communiquer avec ses dépendances en envoyant et en recevant des messages via un agent de messages. Le streaming d’événements permet à votre charge de travail et à ses dépendances d’utiliser un service de streaming pour publier et s’abonner à des événements, diffusés sous forme de flux de données continus, qui doivent être traités dès que possible.

  • La messagerie et le streaming d’événements traitent les messages différemment. Vous devez donc faire un choix en fonction des éléments suivants :

    • Priorité des messages : les agents de messagerie peuvent traiter les messages prioritaires avant les messages normaux. Dans le cadre du streaming d’événements, tous les messages ont la même priorité.

    • Consommation des messages : les agents de messagerie s’assurent que les consommateurs reçoivent le message. Les consommateurs qui diffusent des événements doivent suivre le dernier message qu’ils ont lu.

    • Ordre des messages : avec la messagerie, la réception des messages dans l’ordre exact dans lequel ils ont été envoyés n’est pas garantie, sauf si vous utilisez une approche FIFO (premier entré, premier sorti). Le streaming d’événements préserve toujours l’ordre dans lequel les données ont été produites.

    • Suppression du message : avec la messagerie, le consommateur doit supprimer le message après l’avoir traité. Le service de streaming d’événements ajoute le message à un flux et y reste jusqu’à l’expiration de la période de conservation du message. Cette politique de suppression rend le streaming d’événements adapté à la rediffusion de messages.

  • Définissez comment la charge de travail comprend que sa dépendance a mené à bien sa tâche. Par exemple, lorsque votre charge de travail appelle une fonction Lambda de manière asynchrone, Lambda place l’événement dans une file d’attente et renvoie une réponse positive sans informations supplémentaires. Une fois le traitement terminé, la fonction Lambda peut envoyer le résultat vers une destination, configurable en fonction du succès ou de l’échec.

  • Augmentez votre charge de travail pour gérer les messages dupliqués en tirant parti de l’idempotence. L’idempotence signifie que les résultats de la charge de travail ne changent pas même si elle est générée plusieurs fois pour le même message. Il est important de souligner que les services de messagerie ou de streaming rediffusent un message en cas de panne du réseau ou si aucun accusé de réception n’a été reçu.

  • Si la charge de travail n’obtient pas de réponse de sa dépendance, elle doit soumettre à nouveau la demande. Envisagez de limiter le nombre de tentatives pour préserver le processeur, la mémoire et les ressources réseau de votre charge de travail afin de gérer d’autres demandes. La documentation AWS Lambda montre comment gérer les erreurs liées à l’invocation asynchrone.

  • Tirez parti des outils d’observabilité, de débogage et de suivi appropriés pour gérer et exploiter la communication asynchrone de la charge de travail avec ses dépendances. Vous pouvez l’utiliser Amazon CloudWatch pour surveiller les services de messagerie et de streaming d’événements. Vous pouvez également instrumenter votre charge de travail AWS X-Ray pour obtenir rapidement des informations utiles afin de résoudre les problèmes.

Dépendance par lots

Les systèmes par lots prennent les données d’entrée, lancent une série de tâches pour les traiter et produisent certaines données de sortie, sans intervention manuelle. En fonction de la taille des données, les tâches peuvent s’exécuter pendant une durée allant de quelques minutes à, dans certains cas, plusieurs jours. Lorsque la charge de travail communique avec sa dépendance par lots, suivez les conseils ci-dessous :

  • Définissez la fenêtre de temps pendant laquelle la charge de travail doit exécuter le traitement par lots. La charge de travail peut configurer un modèle de récurrence pour invoquer un système de traitement par lots (par exemple, toutes les heures ou à la fin de chaque mois).

  • Déterminez l’emplacement de l’entrée des données et de la sortie des données traitées. Choisissez un service de stockage, comme Amazon Simple Storage Services (Amazon S3), Amazon Elastic File System (Amazon EFS), et Amazon FSx for Lustre, qui permet à votre charge de travail de lire et d’écrire des fichiers à grande échelle.

  • Si la charge de travail doit invoquer plusieurs tâches par lots, vous pouvez utiliser AWS Step Functions pour simplifier l’orchestration des tâches par lots exécutées sur AWS ou sur site. Cet exemple de projet montre l’orchestration de tâches par lots à l’aide de Step Functions, AWS Batch et Lambda.

  • Surveillez les tâches par lots pour détecter d’éventuelles anomalies, telles qu’une tâche qui prend plus de temps que prévu. Vous pouvez utiliser des outils comme CloudWatch Container Insights pour surveiller les environnements et les tâches AWS Batch. Dans ce cas, la charge de travail empêcherait le début de la tâche suivante et informerait le personnel concerné de l’exception.