REL01-BP03 Prise en compte des quotas de services et des contraintes de service fixes dans l’architecture - Reliability Pillar
Directives d’implémentationRessources

REL01-BP03 Prise en compte des quotas de services et des contraintes de service fixes dans l’architecture

Ayez conscience des quotas de services 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 invocations de fonctions sans serveur, la limitation du taux de salves d’une passerelle API et les connexions simultanées d’utilisateurs à une base de données.

Résultat escompté : l’application ou le service fonctionne comme prévu dans des conditions de trafic normales et intenses. Ils ont été conçus pour fonctionner dans les limites des contraintes fixes ou des quotas de services 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.

  • Réalisation d’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 se mettre à l’échelle ou être modifiée si des quotas de services fixes doivent être dépassés. Par exemple, une taille de charge utile SQS de 256 Ko.

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

Avantages de l’établissement de cette bonne pratique : vérifier que l’application s’exécutera sous tous les niveaux de charge de service prévus, sans interruption ni dégradation.

Niveau d’exposition au risque 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 indiquent ADJUSTABLE = No, le service est soumis à 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 Service Quota, 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 flexible et de quota fixe pour tous ces services. Les limites ne sont pas toutes affichées dans la console Service Quotas. Certains services décrivent ces limites dans d’autres lieux.

  • 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 : veilleuse, 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 :