Calcul pour les charges de travail SaaS sur Azure
Votre application SaaS (Software as a Service) doit s’exécuter sur une plateforme de calcul. Comme d’autres composants de votre architecture, il doit répondre aux besoins de l’entreprise et être conçu en fonction de votre modèle métier. Le choix de la plateforme de calcul est une décision de conception importante. Votre décision affecte l’isolation, les performances et la résilience des clients, et votre plateforme de calcul influence la façon dont votre solution SaaS entière peut évoluer et croître.
Cet article décrit les considérations relatives au choix de votre modèle d’hébergement, aux aspects opérationnels de ce modèle et à l’optimisation des options technologiques pour vous aider à respecter vos contrats de niveau de service (SLA) et les objectifs de niveau de service (SLA).
Sélectionner une plateforme de calcul
Le choix de la plateforme de calcul appropriée pour votre charge de travail SaaS est important, mais l’abondance des options disponibles peut rendre le choix écrasant. La meilleure plateforme dépend de facteurs tels que l’architecture d’application, la mise à l’échelle, les besoins en performances et le modèle d’isolation du locataire. Ce qui est optimal pour une application peut ne pas être pour une autre.
Considérations sur la conception
Modèle d’hébergement. Azure propose différents modèles d’hébergement, principalement l’infrastructure en tant que service (IaaS) et la plateforme en tant que service (PaaS), chacun avec ses propres avantages et compromis. Évaluez les exigences de votre application et choisissez le modèle le plus approprié.
IaaS fournit des machines virtuelles et un contrôle total sur ces machines virtuelles, notamment la mise en réseau et le stockage. Toutefois, elle nécessite la gestion et la mise à jour corrective, qui peuvent être intensives sur le plan opérationnel. Les exemples incluent des groupes de machines virtuelles identiques et des clusters Azure Kubernetes Service (AKS).
PaaS vous permet de déployer des applications sans gérer l’infrastructure sous-jacente. Il inclut des fonctionnalités intégrées pour la mise à l’échelle automatique et l’équilibrage de charge. Par exemple, Azure App Service et Azure Container Apps.
Les services PaaS offrent moins de contrôle par rapport à IaaS, ce qui peut être problématique si votre application a besoin d’une configuration spécifique. Par exemple, votre application peut s’exécuter sur un système d’exploitation que le service PaaS ne prend pas en charge.
Type de charge de travail. Certaines plateformes sont spécialisées pour des charges de travail spécifiques, tandis que d’autres sont polyvalentes. Par exemple, App Service est conçu pour les applications web, tandis qu’AKS est plus universel. Il peut héberger des applications web, des charges de travail IA et des tâches de calcul par lots.
Développez l’expertise de l’équipe. Les changements importants peuvent être difficiles si l’équipe n’a pas d’expérience avec la nouvelle plateforme. Évaluez les compétences de votre équipe et faites-les correspondre aux exigences de votre plateforme. Commencez par une plateforme simple et faites évoluer progressivement votre architecture plutôt que de passer directement à une option plus avancée.
Par exemple, si vous créez une application conteneurisée, commencez par Container Apps pour faciliter la gestion. À mesure que vos besoins se développent plus complexes, vous pouvez passer à AKS lorsque vous obtenez une meilleure compréhension de la plateforme au fil du temps.
Surcharge de gestion. Les plateformes de calcul équilibrent la surcharge et le contrôle. Une plus grande responsabilité en matière de gestion s’éloigne de votre équipe signifie moins de contrôle sur la plateforme.
Par exemple, IaaS offre un contrôle élevé sur les machines virtuelles, mais offre une charge importante. Si votre application est déployée dans l’environnement d’un client, vous disposez peut-être d’un accès limité aux opérations de gestion. Évaluez si ces compromis sont acceptables et réalisables.
Exigences de performances. Comprendre les exigences de performances de votre application en modélisant l’UC, la mémoire, le réseau, notamment la bande passante et la latence, le GPU et les besoins de disponibilité. Vous devez également envisager une croissance future. Utilisez ces informations pour choisir les ressources de calcul appropriées, telles que la série et la taille des machines virtuelles. Vous devrez peut-être également sélectionner des régions spécifiques qui prennent en charge des séries de machines virtuelles particulières pour répondre aux exigences spécialisées.
Exigences de fiabilité. Tenez compte des fonctionnalités de fiabilité de votre plateforme de calcul et assurez-vous qu’elles répondent à vos objectifs de fiabilité. Vous devrez peut-être utiliser des niveaux de service spécifiques pour avoir plusieurs instances de votre solution ou déployer dans des zones de disponibilité pour une fiabilité améliorée.
Reportez-vous aux recommandations RE :04 pour définir des cibles de fiabilité.
Sécurité et conformité des applications. Évaluez les fonctionnalités de sécurité et les certifications de conformité de chaque plateforme de calcul pour vous assurer qu’elles répondent à vos besoins. Par exemple, si vous devez surveiller et filtrer le trafic sortant, vous devrez peut-être choisir des services de calcul ou des niveaux spécifiques.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Évaluez les exigences en matière de performances de calcul en évaluant les dimensions de mise à l’échelle du processeur, de la mémoire, du réseau et du GPU. Effectuez des tests de charge pour collecter des données plus précises pour informer votre exercice de modélisation. |
Ces tâches vous aident à sélectionner le dimensionnement approprié pour votre plateforme de calcul et à effectuer une mise à l’échelle appropriée lorsque la charge sur le système augmente. |
| Évaluez la compétence de votre équipe et commencez par la plateforme la moins complexe qui répond à vos besoins ou celle que l’équipe connaît déjà. | Vous garantissez des opérations plus lisses et évitez de surcharger votre équipe en choisissant une plateforme de calcul qu’ils connaissent. |
| Soyez flexible dans votre conception. Visez une solution que vous pouvez itérer au fil du temps pour vous adapter à l’évolution des exigences métier et techniques. | La flexibilité vous permet de vous adapter plus facilement aux modifications et aux améliorations au fil du temps. Vous pouvez répondre efficacement aux besoins métier et techniques en constante évolution. |
| Évaluez le coût total de possession (TCO), y compris les coûts d’exploitation de la solution. | Vous avez une compréhension claire des coûts, ce qui est essentiel dans la planification de votre modèle de tarification et la garantie des opérations rentables. |
| Déterminez si vous devez utiliser des plateformes de calcul spécifiques en raison de votre pile technologique. Certaines plateformes de calcul sont mieux adaptées à certains langages de programmation, outils et systèmes d’exploitation. S’efforcez d’utiliser des plateformes qui prennent en charge vos choix technologiques en mode natif. | Vous évitez le coût de la refonte de votre architecture, ce qui peut inclure la migration vers une nouvelle plateforme. |
| Évaluez les fonctionnalités de fiabilité de la plateforme et factorisez les garanties de votre fournisseur de services cloud dans vos contrats SLA. | Vous réduisez le risque de pannes de centres de données localisées en planifiant les fonctionnalités de fiabilité et en utilisant des zones de disponibilité si elles sont disponibles. |
Modèle de location et isolation
Votre modèle métier SaaS détermine si vous hébergez des ressources pour les clients ou les gérez dans l’environnement du client. La plupart des fournisseurs SaaS hébergent des ressources pour le compte de leurs clients, ce qui permet une flexibilité dans la conception de la plateforme de calcul. Isolez efficacement les charges de travail des clients pour optimiser l’efficacité des coûts sans compromettre l’expérience client ou les performances.
Considérations sur la conception
Planifiez votre modèle de location. Votre modèle de location détermine le partage des ressources entre les clients et est influencé par vos modèles métier et tarifaires. Les modèles à locataire unique ont des coûts plus élevés par client par rapport aux modèles entièrement multilocataires. Votre tarification doit refléter ces différences.
Exigences du client. Certains clients peuvent avoir des besoins spécifiques en matière de résidence des données, de garanties de performances ou de conformité de la sécurité. Si ces exigences nécessitent des niveaux d’isolation plus élevés que d’habitude, réfléchissez à l’augmentation des coûts dans votre modèle d’entreprise.
Problème de voisin bruyant. Tenez compte du problème de voisin bruyant lors du partage de ressources entre locataires. Les ressources de calcul sont affectées le plus. Pour plus d’informations, consultez antimodèle voisin bruyant.
Lorsque vous choisissez un modèle de location, équilibrez les économies de coûts du partage de ressources avec la nécessité de garantir les performances des clients. Le sur-partage des ressources ou l’autorisation d’une consommation excessive peut dégrader l’expérience client.
Compromis : performances et coûts. Le partage de ressources entre les clients peut être rentable, mais si certains clients utilisent plus de ressources que prévu, cette approche peut dégrader les performances pour d’autres. Pour éviter cela, implémentez une gouvernance appropriée des ressources pour garantir que l’utilisation du locataire reste dans les limites attendues.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Évaluez les fonctionnalités d’isolation de la plateforme de calcul pour vous assurer qu’elle répond aux exigences de votre modèle de location. | Vous évitez de retravailler votre plateforme en vérifiant d’abord la configuration critique. |
| Appliquez votre modèle d’isolation. Soyez prudent avec les ressources partagées telles que les caches de disque local, la mémoire système et les caches externes, car elles peuvent involontairement fuiter des données entre locataires s’ils ne sont pas gérés correctement. Pour des exigences d’isolation élevées, appliquez l’isolation au sein de la plateforme de calcul et dans l’application. |
Une isolation forte réduit le risque de fuite de données entre locataires, un incident de sécurité grave. |
| Implémentez la gouvernance et la surveillance des ressources, avec une visibilité des métriques au niveau du client. Surveillez de manière proactive la consommation des ressources de chaque client pour détecter et atténuer les problèmes de voisin bruyants. |
Vous empêchez les problèmes d’affecter d’autres clients en surveillant la consommation des ressources et en atténuant les problèmes précoces. |
Configurer pour l’extensibilité et l’efficacité des coûts
Vos clients peuvent utiliser votre application avec différents profils de performances. Ils s’attendent à ce que l’application gère les demandes croissantes des utilisateurs, les données à grande échelle et les charges de travail complexes sans compromettre la vitesse et les performances. Votre architecture système doit garantir une scalabilité et des performances optimales, qu’elle gère des centaines ou des millions d’utilisateurs, tout en équilibrant les besoins et les coûts des performances.
Pour plus d’informations sur la gestion des coûts, consultez Facturation et gestion des coûts pour les charges de travail SaaS sur Azure.
Considérations sur la conception
Stratégies de mise à l’échelle horizontale et verticale. Les approches de mise à l’échelle horizontale et verticale sont viables pour gérer une charge accrue. L’approche que vous utilisez dépend de la capacité de votre application à effectuer une mise à l’échelle sur plusieurs instances.
- La mise à l’échelle horizontale implique l’ajout d’instances de nœuds de calcul supplémentaires. Votre architecture a besoin d’un équilibreur de charge pour distribuer le trafic entrant sur plusieurs serveurs ou instances.
- La mise à l’échelle verticale implique l’augmentation des ressources, telles que l’UC et la mémoire, sur un seul serveur. Utilisez cette approche pour les applications avec état qui n’ont pas besoin de magasins d’états externes comme les caches. La mise à l’échelle verticale peut entraîner de brèves interruptions de service et avoir une limite de ressources sur un seul serveur.
Reportez-vous aux recommandations PE :05 pour la mise à l’échelle et le partitionnement.
Mise à l’échelle automatique. Les systèmes doivent gérer efficacement différents niveaux de demande. À mesure que le trafic utilisateur augmente, vos ressources d’application doivent monter en puissance pour maintenir les performances. Lorsque la demande diminue, les ressources diminuent pour contrôler les coûts sans affecter l’expérience utilisateur. Les facteurs tels que l’utilisation du processeur, l’heure de la journée ou les demandes entrantes guident ces ajustements. La mise à l’échelle automatique permet d’équilibrer les performances et les coûts et d’atténuer l’impact de la forte demande sur d’autres locataires.
Reportez-vous aux recommandations RE :06 pour une mise à l’échelle fiable.
Planification de la capacité et allocation de calcul. L’intégration de nouveaux clients à votre charge de travail SaaS consomme la capacité des ressources. Même si vous effectuez une mise à l’échelle verticalement ou horizontalement, vous atteignez finalement des limites, telles que des contraintes de mise en réseau ou de stockage, dans l’extensibilité de votre solution.
Remarque
Le modèle Empreintes de déploiement vous permet de déployer plusieurs instances indépendantes de votre solution. Il fournit une autre dimension de mise à l’échelle. Il est essentiel de comprendre la capacité de chaque empreinte à déterminer quand déployer davantage. Ce concept est également appelé emballage de bacs.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Choisissez la mise à l’échelle horizontale sur la mise à l’échelle verticale. La mise à l’échelle horizontale est souvent moins complexe, plus fiable et plus rentable que la mise à l’échelle verticale. | La mise à l’échelle horizontale est souvent plus simple, plus fiable et économique, ce qui vous permet de procéder à une mise à l’échelle plus élevée que la mise à l’échelle verticale. |
| Effectuez des tests de charge. | La simulation de l’utilisation peut vous aider à identifier les goulots d’étranglement et les seuils de mise à l’échelle avant de déployer en production. |
| Définissez le seuil de mise à l’échelle pour le déploiement d’un nouveau tampon au lieu de mettre à l’échelle horizontalement ou verticalement. Pour une mise à l’échelle économique sans perte de performances, condensez vos locataires sur autant de ressources que possible. |
Vous êtes mieux prêt à gérer la croissance au-delà de votre infrastructure actuelle. |
| Implémentez la mise à l’échelle automatique, le cas échéant. Définissez des règles de mise à l’échelle automatique pour refléter la charge de votre application avec précision. | Vous optimisez les performances et les coûts en augmentant et en réduisant les ressources en fonction des besoins. |
| Surveillez et évaluez les modèles d’utilisation des clients. | Vous savez quand ajuster votre infrastructure pour améliorer les performances ou optimiser les coûts. |
| Implémentez des mécanismes de mise en cache, le cas échéant. | Vous réduisez la charge de traitement potentielle sur la couche de calcul. |
| Utilisez des alertes de coût. | Les avertissements vous aident à détecter rapidement les problèmes d’utilisation et de contrôle des coûts. |
| Utilisez des réservations Azure pour les clients qui ont des engagements à long terme et une utilisation de calcul garantie pour toute cette période. | Vous optimisez l’efficacité des coûts sur votre capacité réservée. |
Conception pour la résilience
La résilience de votre couche de calcul joue un rôle important dans votre stratégie globale de résilience. Votre application doit tolérer et récupérer des défaillances courantes automatiquement et en toute transparence, sans impact sur l’utilisateur.
Considérations sur la conception
Exigences de fiabilité. Définissez des exigences de fiabilité claires. Ces exigences incluent des cibles internes, des contrats SLA et des engagements clients, ou des contrats SLA, qui spécifient souvent des cibles de temps d’activité telles que 99,9 % par mois.
Reportez-vous aux recommandations RE :04 pour définir des cibles de fiabilité.
Stratégie de déploiement. Les ressources cloud sont déployées dans des régions géographiques spécifiques. Dans Azure, les zones de disponibilité sont des jeux de centres de données isolés au sein d’une région. Pour la résilience, déployez des applications sur plusieurs zones de disponibilité. Le déploiement entre régions ou fournisseurs de cloud améliore la résilience, mais ajoute des coûts et une complexité opérationnelle.
Reportez-vous aux recommandations RE :05 pour l’utilisation des zones de disponibilité et des régions.
Charges de travail sans état. Pour déployer des applications résilientes, vous devez généralement exécuter des copies redondantes à différents emplacements. Cette tâche peut être difficile pour les charges de travail avec état, qui doivent conserver l’état de session. Visez à générer des charges de travail sans état lorsque cela est possible.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Gérez les erreurs temporaires dans votre application. | Vous augmentez votre disponibilité en récupérant rapidement des problèmes mineurs. |
| Choisissez des applications sans état. Si votre application doit être avec état, utilisez un mécanisme de stockage d’état externe comme un cache pour stocker l’état. | Vous empêchez la perte d’état causée par l’indisponibilité d’une instance, par exemple lors d’un équilibrage de charge erroné ou lors d’une panne. |
| Utiliser des zones de disponibilité. | Vous augmentez votre résilience en réduisant les pannes de centres de données localisées. |
| Concevez une architecture multirégion quand il y a une justification métier à faire. | Vous répondez aux exigences élevées en matière de temps d’activité et prenez en charge les utilisateurs dans différentes régions. |
| Effectuez l’ingénierie du chaos. | Vous comprenez mieux où se trouvent vos points de défaillance et pouvez les corriger avant qu’une panne se produise. |
| Limitez l’utilisation des composants qui partagent plusieurs tampons. | Vous éliminez les points de défaillance uniques et réduisez la zone d’impact potentielle d’une panne. |
Ressources supplémentaires
L’architecture multilocataire est une méthodologie métier de base pour la conception de charges de travail SaaS. Ces articles fournissent plus d’informations sur les considérations relatives à la plateforme de calcul :
Étape suivante
Découvrez les considérations relatives à la mise en réseau pour les charges de travail SaaS.