Partager via

Approches architecturales pour le calcul dans les solutions mutualisées

  • Article

La plupart des solutions cloud sont composées de ressources de calcul d’un certain type, telles que les niveaux web et d’application, les processeurs par lots, les travaux planifiés et même les ressources spécialisées telles que les GPU et le calcul haute performance (HPC). Les solutions mutualisées bénéficient souvent de ressources de calcul partagées, car une densité plus élevée de locataires pour l’infrastructure réduit le coût opérationnel et la gestion. Vous devez prendre en compte les exigences d’isolation et les implications de l’infrastructure partagée.

Cet article fournit des conseils sur les considérations et les exigences essentielles pour les architectes de solutions à prendre en compte lors de la planification d’un niveau de calcul mutualisé. Cela inclut certains modèles courants pour l’application de l’architecture multilocataire aux services de calcul, ainsi que certains antimodèles à éviter.

Considérations et exigences clés

L’architecture mutualisée et le modèle d’isolation que vous sélectionnez ont un impact sur la mise à l’échelle, les performances, la gestion de l’état et la sécurité de vos ressources de calcul. Dans cette section, nous examinons certaines des décisions clés que vous devez prendre lorsque vous planifiez une solution de calcul mutualisée.

Scale

Les systèmes doivent s’exécuter de manière adéquate en cas de demande changeante. À mesure que le nombre de locataires et la quantité de trafic augmentent, vous devrez peut-être augmenter la capacité de vos ressources, pour suivre le nombre croissant de locataires et maintenir un taux de performances acceptable. De même, lorsque le nombre d’utilisateurs actifs ou la quantité de trafic diminue, vous devez réduire automatiquement la capacité de calcul pour réduire les coûts, mais vous devez réduire la capacité avec un impact minimal sur les utilisateurs.

Si vous déployez des ressources dédiées pour chaque locataire, vous avez la possibilité de mettre à l’échelle les ressources de chaque locataire indépendamment. Dans une solution où les ressources de calcul sont partagées entre plusieurs locataires, si vous mettez à l’échelle ces ressources, tous ces locataires peuvent utiliser la nouvelle échelle. Toutefois, ils souffriront tous si l’échelle est insuffisante pour gérer leur charge globale. Pour plus d'informations, consultez le problème de voisinage bruyant .

Lorsque vous créez des solutions cloud, vous pouvez choisir de les mettre à l’échelle horizontalement ou verticalement. Dans une solution mutualisée avec un nombre croissant de locataires, la mise à l’échelle horizontale vous offre généralement une plus grande flexibilité et un plafond d’échelle global plus élevé.

Les problèmes de performances restent souvent non détectés tant qu’une application n’est pas chargée. Vous pouvez utiliser un service complètement managé, tel que azure Load Testing, pour savoir comment votre application se comporte sous contrainte.

Déclencheurs de mise à l’échelle

Quelle que soit l’approche que vous utilisez pour la mise à l’échelle, vous devez généralement planifier les déclencheurs qui entraînent la mise à l’échelle de vos composants. Lorsque vous avez des composants partagés, tenez compte des modèles de charge de travail de chaque locataire qui utilise les ressources, afin de vous assurer que votre capacité provisionnée peut répondre à la capacité totale requise et réduire le risque qu’un locataire rencontre le problème voisin bruyant. Vous pouvez également planifier votre capacité de mise à l’échelle en tenant compte du nombre de locataires. Par exemple, si vous mesurez les ressources que vous utilisez pour traiter 100 locataires, alors que vous intégrez davantage de locataires, vous pouvez planifier la mise à l’échelle afin que vos ressources doublent pour chaque locataire supplémentaire de 100.

État

Les ressources de calcul peuvent être sans état ou avec état. Les composants sans état ne conservent pas de données entre les requêtes. Du point de vue de la scalabilité, il est souvent facile d’effectuer un scale-out des composants sans état, car vous pouvez rapidement ajouter de nouveaux rôles de travail, de nouvelles instances ou de nouveaux nœuds, et ils peuvent immédiatement commencer à traiter les requêtes. Si votre architecture l’autorise, vous pouvez également réaffecter des instances affectées à un locataire et les allouer à un autre locataire.

Les ressources à état peuvent être subdivisées en fonction du type d’état qu’elles conservent. L'état persistant ce sont des données qui doivent être stockées définitivement. Dans les solutions cloud, vous devez éviter de stocker un état persistant dans votre niveau de calcul. Utilisez plutôt des services de stockage tels que des bases de données ou des comptes de stockage. État temporaire, ce sont des données stockées temporairement, et inclut des caches en mémoire à lecture seule et le stockage de fichiers temporaires sur des disques locaux.

L’état temporaire est souvent utile pour améliorer les performances de votre couche Application, en réduisant le nombre de demandes adressées aux services de stockage back-end. Par exemple, lorsque vous utilisez un cache en mémoire, vous pouvez traiter des demandes de lecture, sans vous connecter à une base de données, et sans effectuer une requête intensive que vous avez récemment effectuée lorsque vous avez traité une autre requête.

Dans les applications sensibles à la latence, le coût de l’hydratation du cache peut devenir significatif. Une solution multilocataire peut aggraver ce problème, si chaque locataire nécessite la mise en cache de données différentes. Pour atténuer ce problème, certaines solutions utilisent l’affinité de session pour s’assurer que toutes les requêtes d’un utilisateur ou d’un locataire spécifique sont traitées par le même nœud Worker de calcul. Bien que l’affinité de session puisse améliorer la capacité de la couche applicative à utiliser efficacement son cache, elle rend également plus difficile la mise à l’échelle et l’équilibrage de la charge du trafic entre les travailleurs. Ce compromis doit être soigneusement pris en compte. Pour de nombreuses applications, l’affinité de session n’est pas nécessaire.

Il est également possible de stocker des données dans des caches externes, tels qu’Azure Cache pour Redis. Les caches externes sont optimisés pour la récupération des données à faible latence, tout en conservant l’état isolé des ressources de calcul, afin qu’ils puissent être mis à l’échelle et gérés séparément. Dans de nombreuses solutions, les caches externes vous permettent d’améliorer les performances de l’application, tandis que vous conservez le niveau de calcul sans état.

Important

Évitez de fuite de données entre locataires, chaque fois que vous utilisez des caches en mémoire ou d’autres composants qui conservent l’état. Par exemple, envisagez de prédéfinis un identificateur de locataire à toutes les clés de cache pour vous assurer que les données sont séparées pour chaque locataire.

Isolement

Lorsque vous concevez un niveau de calcul mutualisé, vous avez souvent de nombreuses options à prendre en compte pour le niveau d’isolation entre les locataires, notamment le déploiement de ressources de calcul partagées, à utiliser par tous les locataires, ressources de calcul dédiées pour chaque locataire, ou quelque chose entre ces extrêmes. Chaque option est fournie avec des compromis. Pour vous aider à déterminer quelle option convient le mieux à votre solution, tenez compte de vos besoins en matière d’isolation.

Vous vous inquiétez peut-être de l’isolation logique des locataires et de la façon de séparer les responsabilités de gestion ou les stratégies appliquées à chaque locataire. Vous devrez peut-être également déployer des configurations de ressources distinctes pour des locataires spécifiques, telles que le déploiement d’une référence SKU de machine virtuelle spécifique pour répondre à la charge de travail d’un locataire.

Quel que soit le modèle d’isolation que vous sélectionnez, vérifiez que vos données de locataire restent correctement isolées même si les composants ne sont pas disponibles ou ne fonctionnent pas correctement. Envisagez d’utiliser Azure Chaos Studio dans le cadre de votre processus de test automatisé régulier pour introduire délibérément des erreurs qui simulent des pannes réelles et vérifient que votre solution ne fuite pas de données entre locataires et fonctionne correctement même sous pression.

Approches et modèles à prendre en compte

Mise à l’échelle automatique

Les services de calcul Azure offrent différentes fonctionnalités pour mettre à l’échelle vos charges de travail. De nombreux services de calcul prennent en charge la mise à l’échelle automatique, ce qui vous oblige à prendre en compte quand vous devez effectuer une mise à l’échelle, ainsi que vos niveaux minimum et maximal d’échelle. Les options spécifiques disponibles pour la mise à l’échelle dépendent des services de calcul que vous utilisez. Consultez les exemples de services suivants :

Modèle d’empreintes de déploiement

Pour plus d’informations sur la façon dont le modèle Empreintes de déploiement peut être utilisé pour prendre en charge une solution multilocataire, consultez Vue d’ensemble.

Modèle de consolidation des ressources de calcul

Le modèle de consolidation des ressources de calcul vous permet d’obtenir une densité plus élevée de locataires pour l’infrastructure de calcul, en partageant les ressources de calcul sous-jacentes. En partageant des ressources de calcul, vous pouvez souvent réduire le coût direct de ces ressources. En outre, vos coûts de gestion sont souvent inférieurs, car il y a moins de composants à gérer.

Toutefois, la consolidation des ressources de calcul augmente la probabilité du problème du voisin bruyant. La charge de travail d’un locataire peut consommer une quantité disproportionnée de la capacité de calcul disponible. Vous pouvez souvent atténuer ce risque en vous assurant de mettre à l’échelle votre solution de manière appropriée et en appliquant des contrôles tels que des quotas et des limites d’API, afin d’éviter que les locataires consomment plus que leur juste part de la capacité.

Ce modèle est obtenu de différentes façons, selon le service de calcul que vous utilisez. Consultez les exemples de services suivants :

  • Azure App Service et Azure Functions: déployer des plans App Service partagés, qui représentent l’infrastructure du serveur d’hébergement.
  • Azure Container Apps : Déployez des environnements partagés.
  • Azure Kubernetes Service (AKS) : Déployez des pods partagés, avec une application compatible avec la multilocation.
  • machines virtuelles: déployez un seul ensemble de machines virtuelles à l'usage de tous les locataires.

Ressources de calcul dédiées par locataire

Vous pouvez également déployer des ressources de calcul dédiées pour chaque locataire. Les ressources dédiées atténuent le risque de problème de voisin bruyant, en garantissant que les ressources de calcul de chaque locataire sont isolées des autres. Il vous permet également de déployer une configuration distincte pour les ressources de chaque locataire, en fonction de leurs besoins. Toutefois, les ressources dédiées ont généralement un coût plus élevé, car vous avez une faible densité de locataires par rapport aux ressources.

Selon les services de calcul Azure que vous utilisez, vous devez déployer différentes ressources dédiées, comme suit :

  • Azure App Service et Azure Functions: déployez des plans App Service distincts pour chaque locataire.
  • Azure Container Apps: déployez des environnements distincts pour chaque locataire.
  • azure Kubernetes Service (AKS): déployez des clusters dédiés pour chaque locataire.
  • machines virtuelles: déployez des machines virtuelles dédiées pour chaque locataire.

Ressources de calcul semi-isolées

Les approches semi-isolées vous obligent à déployer des aspects de la solution dans une configuration isolée, tandis que vous partagez les autres composants.

Lorsque vous travaillez avec App Service et Azure Functions, vous pouvez déployer des applications distinctes pour chaque locataire, et vous pouvez héberger les applications sur des plans App Service partagés. Cette approche réduit le coût de votre niveau de calcul, car les plans App Service représentent l’unité de facturation. Il vous permet également d’appliquer une configuration et des stratégies distinctes à chaque application. Toutefois, cette approche introduit le risque de problème de voisin bruyant .

Azure Container Apps vous permet de déployer plusieurs applications dans un environnement partagé, puis d’utiliser Dapr et d’autres outils pour configurer chaque application séparément.

Azure Kubernetes Service (AKS) et Kubernetes plus largement fournissent diverses options pour l’architecture mutualisée, notamment les suivantes :

  • Espaces de noms spécifiques au locataire, pour l’isolation logique des ressources spécifiques au locataire, qui sont déployées sur des clusters partagés et des pools de nœuds.
  • Nœuds ou pools de nœuds spécifiques au locataire sur un cluster partagé.
  • Pods spécifiques aux locataires qui peuvent utiliser le même pool de nœuds.

AKS vous permet également d’appliquer une gouvernance au niveau des pods pour atténuer le problème du voisin bruyant. Pour plus d’informations, consultez Meilleures pratiques pour les développeurs d’applications de gérer les ressources dans azure Kubernetes Service (AKS).

Il est également important de connaître les composants partagés dans un cluster Kubernetes et de savoir comment ces composants peuvent être affectés par l’architecture mutualisée. Par exemple, le serveur d’API Kubernetes est un service partagé utilisé dans l’ensemble du cluster. Même si vous fournissez des pools de nœuds spécifiques aux locataires pour isoler les charges de travail d'applications des locataires, le serveur d'API peut rencontrer une contention due à un grand nombre de requêtes parmi les locataires.

Antimodèles à éviter

Antimodèle : voisin bruyant

Chaque fois que vous déployez des composants partagés entre locataires, le problème voisin bruyant est un risque potentiel. Veillez à inclure la gouvernance et la surveillance des ressources pour atténuer le risque que la charge de travail de calcul d’un locataire soit affectée par l’activité d’autres locataires.

Fuite de données entre locataires

Les niveaux de calcul peuvent être soumis à des fuites de données entre locataires, s’ils ne sont pas gérés correctement. Ce n’est généralement pas quelque chose que vous devez prendre en compte lorsque vous utilisez un service multilocataire sur Azure, car Microsoft fournit des protections au niveau de la couche de plateforme. Toutefois, lorsque vous développez votre propre application mutualisée, déterminez si des ressources partagées (telles que les caches de disque local, la RAM et les caches externes) peuvent contenir des données qu’un autre locataire peut afficher ou modifier par inadvertance.

Antimodèle Serveur frontal occupé

Pour éviter l’antimodèle Serveur frontal occupé, ne laissez pas votre couche frontale effectuer une grande partie du travail qui pourrait être effectué par d’autres composants ou couches de votre architecture. Cet antimodèle est particulièrement important lorsque vous créez des serveurs frontaux partagés pour une solution multilocataire, car un front-end occupé dégrade l’expérience pour tous les locataires.

Au lieu de cela, envisagez d’utiliser le traitement asynchrone en utilisant des files d’attente ou d’autres services de messagerie. Cette approche vous permet également d'appliquer les contrôles de qualité de service (QoS) pour différents clients, en fonction de leurs besoins. Par exemple, tous les locataires peuvent partager une couche frontale commune, mais les locataires qui paient pour un niveau de service plus élevé peuvent disposer d’un ensemble plus important de ressources dédiées pour traiter le travail de leurs messages en file d’attente.

Mise à l’échelle non élastique ou insuffisante

Les solutions multilocataires sont souvent mises à l’échelle par à-coups. Les composants partagés sont particulièrement sensibles à ce problème, car la portée du burst est plus élevée et l’impact est plus important lorsque vous avez plus de locataires avec des modèles d’utilisation distincts.

Veillez à utiliser l’élasticité et l’échelle du cloud. Déterminez si vous devez utiliser une mise à l’échelle horizontale ou verticale, et utilisez la mise à l’échelle automatique pour gérer automatiquement les pics de charge. Testez votre solution pour comprendre comment elle se comporte sous différents niveaux de charge. Assurez-vous d’inclure les volumes de charge attendus en production et votre croissance attendue. Vous pouvez utiliser un service complètement managé, tel que azure Load Testing, pour savoir comment votre application se comporte sous contrainte.

Antimodèle d’absence de mise en cache

On parle d’antimodèle Absence de mise en cache lorsque le niveau de performance de votre solution souffre du fait que la couche Application demande ou recalcule de manière répétée des informations qui pourraient être réutilisées d’une requête à l’autre. Si vous avez des données qui peuvent être partagées, entre locataires ou entre utilisateurs au sein d’un seul locataire, il est probable qu’il vaut la mise en cache pour réduire la charge sur votre niveau back-end/base de données.

Conservation de l’état inutile

Le corollaire de l’antimodèle Sans mise en cache est que vous devez également éviter de stocker un état inutile dans votre niveau de calcul. Soyez explicite quant à l’emplacement où vous conservez l’état et au motif. Les couches Application ou frontale avec état peuvent réduire votre capacité à mettre à l’échelle. Les couches de calcul avec état requièrent généralement aussi une affinité de session, ce qui peut réduire votre capacité à équilibrer efficacement la charge du trafic entre les rôles de travail ou les nœuds.

Examinez les compromis pour chaque élément d’état que vous gérez dans votre couche de calcul, et voyez si cela a un impact sur votre capacité à mettre à l’échelle ou à croître en fonction de l’évolution des modèles de charge de travail de vos locataires. Vous pouvez également stocker l’état dans un cache externe, tel qu’Azure Cache pour Redis.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

  • Dixit Arora | Ingénieur client senior, FastTrack pour Azure
  • John Downs | Ingénieur logiciel principal

Autres contributeurs :

Étapes suivantes

Passez en revue les conseils spécifiques au service pour vos services de calcul :