Comprendre la charge de travail

Pour appliquer le framework, commencez par comprendre la charge de travail que vous souhaitez analyser. Un schéma d'architecture du système fournit un point de départ pour documenter les détails les plus pertinents du système. Cependant, essayer d'analyser une charge de travail complète peut s'avérer complexe, car de nombreux systèmes comportent de nombreux composants et interactions. Nous vous recommandons plutôt de vous concentrer sur les user stories, qui sont des explications générales informelles des fonctionnalités du logiciel rédigées du point de vue de l'utilisateur final. Leur objectif est d'expliquer comment une fonctionnalité logicielle apporte de la valeur au client. Vous pouvez ensuite modéliser ces user stories à l'aide de diagrammes d'architecture et de diagrammes de flux de données afin de faciliter l'évaluation des composants techniques qui fournissent les fonctionnalités métier décrites. Par exemple, une solution d'achat de jeux mobile intégrée à une application peut comporter deux histoires utilisateur, « acheter des crédits intégrés à l'application » et « obtenir des remboursements intégrés à l'application », comme le montre le schéma suivant. (Cet exemple d'architecture montre comment décomposer un système en témoignages d'utilisateurs ; il n'est pas destiné à représenter une application hautement résiliente.)

Chaque user story comprend quatre composants communs : le code et la configuration, l'infrastructure, les magasins de données et les dépendances externes. Vos diagrammes doivent inclure tous ces composants et refléter les interactions entre les composants. Par exemple, si votre point de terminaison Amazon API Gateway est soumis à une charge excessive, réfléchissez à la manière dont cette charge se répercute sur les autres composants du système, tels que vos AWS Lambda fonctions ou les tables Amazon DynamoDB. Le suivi de ces interactions vous permet de comprendre comment le mode de défaillance peut avoir un impact sur le récit de l'utilisateur. Vous pouvez capturer ce flux visuellement à l'aide d'un diagramme de flux de données ou à l'aide de simples flèches de flux dans un diagramme d'architecture, comme dans l'illustration précédente. Pour chaque composant, pensez à saisir des détails tels que le type d'informations transmises, les informations reçues, si la communication est synchrone ou asynchrone et les limites de défaillance franchies. Dans l'exemple, les tables DynamoDB sont partagées dans les deux récits utilisateur, comme le montrent les flèches indiquant que le composant Lambda de l'histoire des remboursements intégrés à l'application accède aux tables DynamoDB de l'historique des achats intégrés. Cela signifie qu'un échec causé par l'histoire utilisateur des achats intégrés à l'application peut se répercuter sur l'histoire utilisateur des remboursements intégrés à l'application en raison d'un destin partagé.

En outre, il est important de comprendre la configuration de base de chaque composant. La configuration de référence identifie les contraintes telles que le nombre moyen et maximal de transactions par seconde, la taille maximale d'une charge utile, le délai d'expiration du client et les quotas de service par défaut ou actuels pour la ressource. Si vous modélisez une nouvelle conception, nous vous recommandons de documenter les exigences fonctionnelles de la conception et de prendre en compte les limites. Cela vous permet de comprendre comment les modes de défaillance peuvent se manifester dans le composant.

Enfin, vous devez prioriser les user stories en fonction de la valeur commerciale qu'ils apportent. Cette hiérarchisation vous permet de vous concentrer d'abord sur les fonctionnalités les plus critiques de votre charge de travail. Vous pouvez ensuite concentrer votre analyse sur les composants de la charge de travail qui font partie du chemin critique pour cette fonctionnalité, et tirer parti de l'utilisation plus rapide de la structure. Au fur et à mesure du processus, vous pouvez examiner d'autres récits d'utilisateurs selon des priorités différentes.