REL01-BP03 Tenir compte des quotas et des contraintes de service fixes dans l'architecture - Pilier Fiabilité
Directives d'implémentationRessources

REL01-BP03 Tenir compte des quotas et des contraintes de service fixes dans l'architecture

Ayez conscience des quotas de service non modifiables, des contraintes de service et des limites de ressources physiques. Concevez des architectures pour les applications et les services afin d'éviter que ces limites n'aient un impact sur la fiabilité.

Par exemple, la bande passante du réseau, la taille de la charge utile des appels de fonctions sans serveur, le taux d'accélération d'une passerelle API et les connexions simultanées d'utilisateurs à une base de données.

Résultat souhaité : l'application ou le service fonctionne comme prévu dans des conditions de trafic normal et élevé. Ils ont été conçus pour fonctionner dans les limites des contraintes fixes ou des quotas de service de cette ressource.

Anti-modèles courants :

  • Choix d'une conception qui utilise une ressource d'un service, sans savoir qu'il existe des contraintes de conception qui entraîneront l'échec de cette conception au fil des mises à l'échelle.

  • Effectuer une évaluation comparative qui n'est pas réaliste et qui atteindra les quotas fixés par le service pendant les tests. Par exemple, l'exécution de tests à une limite de débordement mais pendant une durée prolongée.

  • Le choix d'une conception qui ne peut pas évoluer ou être modifiée si des quotas de service fixes doivent être dépassés. Par exemple, une taille de charge utile SQS de 256 KB.

  • L'observabilité n'a pas été conçue et mise en œuvre pour surveiller et alerter sur les seuils des quotas de service qui pourraient être compromis lors d'événements à fort trafic

Avantages liés au respect de cette bonne pratique : vérifier que l'application fonctionnera sous tous les niveaux de charge des services projetés sans perturbation ni dégradation.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : moyen

Directives d'implémentation

Contrairement aux quotas de services souples ou aux ressources qui peuvent être remplacées par des unités de plus grande capacité, les quotas fixes des services AWS ne peuvent pas être modifiés. Cela signifie que tous ces types de services AWS doivent être évalués en fonction des limites potentielles de capacité matérielle lorsqu'ils sont utilisés dans la conception d'une application.

Les limites strictes sont affichées dans la console Service Quotas. Si les colonnes affichent la valeur ADJUSTABLE = No, alors le service comporte une limite stricte. Des limites strictes sont également indiquées dans les pages de configuration de certaines ressources. Par exemple, Lambda possède des limites strictes spécifiques qui ne peuvent pas être ajustées.

À titre d'exemple, lors de la conception d'une application python destinée à être exécutée dans une fonction Lambda, l'application doit être évaluée pour déterminer si Lambda risque de s'exécuter pendant plus de 15 minutes. Si le code peut fonctionner au-delà de cette limite de quota de service, il faut envisager d'autres technologies ou conceptions. Si cette limite est atteinte après le déploiement de la production, l'application subira une dégradation et des perturbations jusqu'à ce qu'il soit possible d'y remédier. Contrairement aux quotas souples, il n'existe aucune méthode permettant de passer à ces limites, même en cas d'événements d'urgence de gravité 1.

Une fois que l'application a été déployée dans un environnement de test, il convient d'utiliser des stratégies pour déterminer si des limites strictes peuvent être atteintes. Les tests de résistance, les tests de charge et les tests de chaos doivent faire partie du plan de test d'introduction.

Étapes d'implémentation

  • Examinez la liste complète des services AWS qui pourraient être utilisés dans la phase de conception de l'application.

  • Examinez les limites de quota logiciel et de quota matériel pour tous ces services. Toutes les limites ne sont pas affichées dans la console Service Quotas. Certains services détaillent ces limites à d'autres endroits.

  • Lors de la conception de votre application, examinez les facteurs opérationnels et technologiques de votre charge de travail, tels que les résultats opérationnels, le cas d'utilisation, les systèmes dépendants, les objectifs de disponibilité et les objets de reprise après sinistre. Laissez vos facteurs commerciaux et technologiques guider le processus d'identification du système distribué qui convient à votre charge de travail.

  • Analysez la charge de service dans les régions et les comptes. De nombreuses limites strictes se basent sur la région pour les services. Cependant, certaines limites sont basées sur le compte.

  • Analysez les architectures de résilience pour l'utilisation des ressources lors d'une panne de zone et d'une panne régionale. Dans la progression des conceptions multirégionales utilisant des approches actives/actives, actives/passives – à chaud, actives/passives – à froid, et actives/passives – environnement de veille, ces cas de panne entraîneront une utilisation plus importante. Cela crée un cas d'utilisation potentiel pour atteindre des limites strictes.

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Outils associés :