Architecture cloud IA

La conception doit répondre aux contraintes de fiabilité, de données, de latence et de coût de la tâche. Un accélérateur puissant n’est qu’un élément de cette conception.

Points clés à retenir

• Séparez les charges de travail selon leurs besoins opérationnels.
• Appliquez les limites des données et des autorisations.
• Concevoir la capacité, les tentatives et la restauration ensemble.

Séparez les charges de travail interactives et en arrière-plan lorsque leurs exigences diffèrent. Un utilisateur en attente d'une réponse a besoin d'un temps de réponse limité, tandis que le traitement par lots peut utiliser des files d'attente et des tâches plus longues. Rendre l'état de la file d'attente et le comportement des nouvelles tentatives observables. Définissez les limites des données et les rôles d’accès. Les documents, les intégrations, les artefacts de modèle et les journaux peuvent avoir des exigences de conservation et d'autorisation différentes. Conservez les informations d'identification dans une gestion secrète appropriée et évitez de supposer que l'emplacement réseau seul établit l'autorisation. Planifiez les changements de capacité et les échecs de dépendance. La mise à l'échelle automatique peut prendre du temps, le chargement du modèle peut être coûteux et un fournisseur peut imposer des limites de débit. Utilisez des contrôles d’admission, des contre-pressions, des tentatives limitées et des états indisponibles clairs pour éviter qu’une dépendance surchargée ne submerge l’ensemble du service. Versionnez le déploiement et testez la récupération. Vérifiez les modèles compatibles et les versions de prétraitement, les migrations de données et les procédures de restauration. Mesurez le coût par tâche utile terminée, y compris le stockage, le transfert, les tentatives infructueuses et les ressources inutilisées. Un prix bas pour un appel d'API peut cacher un flux de travail global plus coûteux.

1. Imaginez 100 utilisateurs d'applications appelant un point de terminaison de modèle à débit limité. Chaque demande ayant échoué est réessayée immédiatement cinq fois.
2. Les tentatives supplémentaires augmentent la charge sans ajouter de capacité au point final.
3. Appliquez une stratégie de nouvelle tentative limitée qui respecte l'intervalle de temps du fournisseur, limite les requêtes simultanées et affiche la file d'attente ou l'état d'indisponibilité aux utilisateurs.

Cet exemple construit explique comment l'architecture peut empêcher la propagation d'une surcharge.