Partager via

Mesure de la consommation de chaque locataire

  • Article

En tant que fournisseur de solutions, il est important de mesurer la consommation de chaque locataire dans votre solution multilocataire. En mesurant la consommation de chaque locataire, vous pouvez vous assurer de la rentabilité du coût des marchandises vendues (CMV) pour la livraison du service à chaque locataire. Dans cette page, nous fournissons des conseils pour les décideurs techniques concernant l’importance de la mesure de la consommation, les approches que vous pouvez prendre en compte pour mesurer la consommation d’un locataire ainsi que les compromis impliqués.

Il existe deux problèmes principaux qui nécessitent la mesure de la consommation de chaque locataire :

  • Vous devez mesurer le coût réel pour servir chaque locataire. Il est important de surveiller la rentabilité de la solution pour chaque locataire.
  • Vous devez déterminer le montant à facturer au locataire, lorsque vous utilisez la tarification basée sur la consommation.

Toutefois, il peut être difficile de mesurer les ressources réelles utilisées par un locataire dans une solution multilocataire. La plupart des services qui peuvent être utilisés dans le cadre d’une solution multilocataire ne différencient pas ou ne ventilent pas automatiquement l’utilisation, en fonction de la définition d’un locataire. Prenons l’exemple d’un service qui stocke les données de tous vos locataires dans une seule base de données relationnelle. Il est difficile de déterminer exactement l’espace que chaque locataire utilise dans cette base de données relationnelle, que ce soit en termes de stockage ou de capacité de calcul nécessaire pour répondre aux requêtes et aux demandes.

En revanche, pour une solution à locataire unique, vous pouvez utiliser Microsoft Cost Management dans le Portail Azure afin d’obtenir une répartition des coûts complète pour toutes les ressources Azure utilisées par ce locataire.

Par conséquent, face à ces défis, il est important de réfléchir à la manière de mesurer la consommation.

Remarque

Dans certains cas, une perte sur la prestation de services à un locataire est commercialement acceptable, par exemple, lorsque vous entrez sur un nouveau marché ou une nouvelle région. Il s’agit d’un choix commercial. Même dans ce cas, il est toujours judicieux de mesurer la consommation de chaque locataire afin que vous puissiez planifier pour l’avenir.

Métriques de consommation indicatives

Les applications modernes (conçues pour le cloud) sont généralement composées de nombreux services différents, chacun ayant des métriques de consommation différentes. Par exemple, un compte de stockage mesure la consommation en fonction de la quantité de données stockées, des données transmises et du nombre de transactions. Cependant, la consommation d’Azure App Service est mesurée par la quantité de ressources de calcul allouées au fil du temps. Si vous disposez d’une solution qui comprend un compte de stockage et des ressources App Service, il peut être très difficile de combiner toutes ces métriques pour calculer le coût réel des marchandises vendues (COGS). Souvent, il est plus facile d’utiliser une seule mesure indicative pour représenter la consommation dans la solution.

Par exemple, dans le cas d’une solution multilocataire qui partage une seule base de données relationnelle, vous pouvez estimer que les données stockées par le locataire constituent une bonne métrique indicative de la consommation.

Remarque

Même si vous utilisez le volume de données stockées par un locataire comme métrique indicative de la consommation, il se peut que celui-ci ne soit pas une représentation fidèle de la consommation pour chaque locataire. Par exemple, si un locataire particulier effectue beaucoup plus de lectures ou exécute davantage de rapports à partir de la solution, mais qu’il n’écrit pas beaucoup de données, il peut utiliser un volume de calcul bien plus important que celui indiqué par les exigences de stockage.

Il est important de mesurer et d’examiner de temps en temps la consommation réelle de vos locataires question de déterminer si les hypothèses que vous emettez sur vos métriques indicatives sont correctes.

Métriques de transaction

Une autre façon de mesurer la consommation consiste à identifier une transaction clé représentative du COGS pour la solution. Par exemple, dans une solution de gestion de documents, il peut s’agir du nombre de documents créés. Cela peut être utile s’il existe une fonction ou une fonctionnalité de base dans un système transactionnel, et si elle peut être facilement mesurée.

Cette méthode est généralement simple et économique à mettre en place, car votre application comporte généralement un seul point devant enregistrer le nombre de transactions qui se produisent.

Métriques par requête

Pour les solutions qui reposent principalement sur des API, il peut être judicieux d’utiliser une métrique de consommation basée sur le nombre de requêtes d’API adressées à la solution. Cela peut souvent être assez simple à implémenter, mais cela vous oblige à utiliser les API comme interface principale avec le système. L’implémentation d’une métrique par requête entraînera une augmentation des coûts opérationnels, en particulier pour les services à volume élevé, en raison de la nécessité d’enregistrer l’utilisation des requêtes (à des fins d’audit et de facturation).

Notes

Les solutions accessibles à l’utilisateur qui se composent d’une application à page unique (SPA) ou d’une application mobile qui utilise les API peuvent ne pas être adaptées à la métrique par requête. Cela est dû au fait que l’utilisateur final comprend peu la relation entre l’utilisation de l’application et la consommation des API. Que votre application peut être bavarde (elle effectue de nombreuses requêtes d’API) ou laborieuse (elle effectue trop peu de requêtes d’API), l’utilisateur ne remarquera probablement pas la différence.

Avertissement

Veillez à stocker les métriques de requête dans un magasin de données fiable conçu à cet effet. Par exemple, bien qu’Azure Application Insights puisse suivre les requêtes et même les identifiants des locataires (à l’aide de propriétés), cette solution n’est pas conçue pour stocker tous les éléments de télémétrie. Elle supprime les données dans le cadre de son comportement d’échantillonnage. À des fins de facturation et de mesure, choisissez un magasin de données qui vous donnera un niveau de précision élevé.

Estimer la consommation

Lors de la mesure de la consommation d’un locataire, il peut être plus aisé de fournir une estimation de la consommation du locataire que d’essayer de calculer le montant exact de la consommation. Par exemple, dans le cas d’une solution multilocataire qui dessert plusieurs milliers de locataires dans un seul déploiement, il est raisonnable d’estimer que le coût du service au locataire ne représente qu’un pourcentage du coût des ressources Azure.

Vous pouvez estimer le COGS pour un locataire, dans les cas suivants :

  • Vous n’utilisez pas la tarification basée sur l’utilisation.
  • Les modèles d’utilisation et le coût de chaque locataire sont similaires, quelle que soit la taille.
  • Chaque locataire consomme un faible pourcentage (par exemple, < 2 %) des ressources globales du déploiement.
  • Le coût par locataire est faible.

Vous pouvez également choisir d’estimer la consommation en associant les métriques de consommation indicatives, les métriques de transaction ou les métriques par requête. Par exemple, dans le cas d’une application qui gère principalement des documents, le pourcentage de stockage global utilisé par un locataire pour stocker ses documents donne une idée du COGS réel. Cette approche peut être utile lorsque la mesure du COGS est difficile ou lorsqu’elle rendrait l’application trop complexe.

Facturation de vos coûts

Dans certaines solutions, vous pouvez simplement facturer à vos clients le COGS pour les ressources de leur locataire. Par exemple, vous pouvez utiliser des balises de ressources Azure pour allouer des ressources Azure facturables aux locataires. Vous pouvez ensuite déterminer le coût pour chaque locataire de l’ensemble des ressources qui lui sont dédiées, plus une marge de profit et d’exploitation.

Notes

Certains services Azure ne prennent pas en charge les balises. Pour ces services, vous devrez attribuer des coûts à un locataire, en fonction du nom et du groupe de ressources ou de l’abonnement.

L’analyse des coûts Azure permet d’analyser les coûts des ressources Azure pour les solutions à locataire unique qui utilisent des balises, des groupes de ressources ou des abonnements aux coûts d’attribut.

Toutefois, cela devient excessivement complexe dans la plupart des solutions multilocataires modernes, car il est difficile de déterminer avec précision les coûts d’exploitation exacts pour servir un seul locataire. Cette méthode ne doit être envisagée que pour des solutions très simples, des solutions qui ne comportent que des déploiements de ressources pour un seul locataire ou des fonctionnalités supplémentaires spécifiques à un locataire au sein d’une solution plus vaste.

Certains services Azure fournissent des fonctionnalités qui permettent d’autres méthodes d’attribution des coûts dans un environnement mutualisé. Par exemple, le service Azure Kubernetes prend en charge plusieurs pools de nœuds, où chaque locataire est alloué à un pool de nœuds avec des balises de pool de nœuds, qui permettent d’attribuer des coûts.

Contributeurs

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

Auteur principal :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Tenez compte du modèle de déploiement des mises à jour que vous utiliserez.