Estimation du profit du fournisseur

Dans cette sous section, nous estimons les revenus et les dépenses du fournisseur lors de l’exécution d’une requête afin de déduire le profit économique du fournisseur. Nous rappelons que ces estimations sont faites uniquement lorsqu’une réplication est envisagée.

4.5.2.1 Estimation des revenus

Nous nous sommes intéressés à deux types de revenus perçus par le fournisseur : (i) les revenus générés par la location des ressources à ses locataires lors du traitement de leurs requêtes, et (ii) les revenus générés par la location d’un service particulier à un autre fournisseur. En effet, il est possible qu'un fournisseur de Cloud procède à la location de services à d’autres fournisseurs de Cloud. Néanmoins, nous supposons que la majeure source de revenus du fournisseur provient des locataires. Ces revenus sont décrits ci-dessous :

(i) Un montant de service (Ti_Amount) reçu de la part de chaque locataire Ti servi par ce fournisseur, pour les ressources qui lui ont été allouées. Certains fournisseurs

77

commerciaux, par exemple Google Cloud21, facturent une location mensuelle des ressources (pour les abonnés) tandis que d’autres fournisseurs facturent pour une période plus courte, par exemple une heure pour l’utilisation de ressources de calcul avec OVH Cloud22. D’autres fournisseurs facturent l’exécution d’un certain nombre de requêtes, convenu dans le SLA. Par exemple, BigQuery23 de Google applique un tarif pour un certain nombre de requêtes, en fonctions du volume de données traitées. Dans notre cas, nous avons également considéré une tarification pour un nombre maximum de requêtes # Q pendant la période de facturation, par exemple 0,6 $ pour l’exécution de 1 000 requêtes. Ceci correspond à une tarification fixe. D’un autre coté, le prix peut être déterminé en fonction de l’offre et la demande, ce qui correspond à une tarification dynamique. Cela permet au fournisseur de mieux exploiter le potentiel de paiement des locataires et donc de réaliser un plus grand bénéfice.

(ii) Le prix probable d'un crédit de service (Rent_XaaS) reçu lorsque le fournisseur loue un service XaaS donné à un autre fournisseur (Serrano et al., 2016).

Nous estimons alors les revenus du fournisseur par requête (Q_Revenues) comme indiqué dans la Formule (4.11). Il est alors évident que le fournisseur doit définir le montant de service Ti_Amount en fonction de toutes ses dépenses afin d’obtenir un gain raisonnable. Rappelons qu’un fournisseur peut créer une ou plusieurs répliques afin de satisfaire l’objectif d’un locataire, ici SLORT. Néanmoins, un locataire n'est pas facturé pour le nombre de répliques créées lors de l'exécution de sa requête.

Q_Revenues = ( + Rent_XaaS (4.11) Il convient aussi de noter qu’il n’est pas réaliste de connaitre à l’avance le nombre de requêtes soumises par un locataire et avec quel taux d’arrivée. Q_Revenues correspond alors à l'estimation du revenu moyen attendu pour l’exécution d’une requête suivant les modalités fixées dans le SLA, par exemple en ayant le nombre maximum de requêtes traitées durant une période de facturation. L'estimation décrite ci-dessus permet alors de prédire rapidement le revenu moyen par requête avec une précision suffisante pour la décision de réplication.

4.5.2.2 Estimation des dépenses

Par rapport à l’estimation des revenus du fournisseur lors de l’exécution d’une requête Q d’un locataire, l'estimation des dépenses est plus complexe. Ces dépenses correspondent à la somme des prix des ressources allouées lors de l'exécution de Q. En effet, le fournisseur doit payer périodiquement le coût de fonctionnement de chaque serveur qui met à disposition ces ressources, par exemple en termes de stockage et de bande passante.

La création d’une nouvelle réplique engendre des coûts de transfert et de stockage supplémentaires afin de satisfaire le contrat SLA, ce qui évite au fournisseur le payement de pénalités au locataire. Rappelons qu’un locataire ne doit pas être facturé pour la création d’une réplique. Le coût engendré par toute nouvelle création de réplique doit alors être inclus dans les dépenses du fournisseur afin de pouvoir décider de la profitabilité de la 21 https://cloud.google.com/products/compute?hl=fr 22 https://www.ovhcloud.com/fr/public-cloud/prices/#compute 23 https://cloud.google.com/bigquery/pricing?hl=fr

78

réplication de données. Evidemment, les dépenses du fournisseur augmentent lorsque le nombre de répliques augmente. Une stratégie de réplication efficace doit alors envisager un ajustement dynamique du facteur de réplication comme décrit précédemment. Cela permet de réduire les dépenses du fournisseur.

Dans un environnement Cloud, l'exécution d’une requête Q peut impliquer la participation d'un certain nombre de nœuds. Les ressources disponibles sur ces nœuds peuvent être entièrement ou partiellement utilisées lors de cette exécution. Elles coûtent inévitablement de l'argent au fournisseur (Greenberg et al., 2009) qui les facturent à son tour aux locataires qu’il sert. Ces ressources incluent notamment le coût de traitement par les processeurs (CCPU), le coût du stockage (CS) et le coût de la bande passante du réseau (CNB). Ces dépenses doivent également inclure le coût probable des pénalités (CP) payées aux locataires et les coûts d’estimations du temps de réponse et du profit du fournisseur (CEst) engendrés par la réplication. Nous incluons également dans les dépenses du fournisseur : les coûts de la consommation énergétique (CEnerg), les coûts d’investissement du fournisseur (CInv) ainsi que les coûts de location de services XaaS auprès d’autres fournisseurs (CXaaS). L’estimation du coût monétaire total pour l'exécution d'une requête par le fournisseur revient alors à l’estimation de l’ensemble de dépenses monétaires citées dans la Formule (4.12).

Q_Expenses = CCPU + CS + CNB + CP + CEst + CEnerg + CInv + CXaaS (4.12) L’estimation de chaque dépense lors de l’exécution d’une requête Q est décrite en détail ci-dessous. Nous utilisons les paramètres suivants : Soit #MV le nombre de nœuds exécutant les opérateurs de Q. Soit Sdl la taille d’une relation stockée sur un nœud local. Sdr correspond à la taille d’une relation distante transférée entre deux nœuds. Cette relation peut être une réplique nouvellement créée. d’/r’ correspond au nombre de relations locales/distantes requises pour l’exécution de Q. Il convient de signaler que d’ et r’ incluent également le nombre de répliques requises pour l’exécution de Q.

=

(4.13)

Coût des traitements (CCPU). Les opérateurs d’une requête peuvent être traités conjointement par plusieurs nœuds dans un environnement distribué. Par conséquent, ce coût monétaire correspond au coût de l’ensemble des CPU sur les #MV participants à l'exécution de Q comme indiqué dans la Formule (4.13). Soit RTOp le temps de réponse estimé pour l’exécution d’un opérateur Oq ⊆ Q. Soit CPU_Cost le coût, en millions d’instructions par unité de temps, par exemple une heure dans le Cloud d’Amazon, pour utiliser un nœud alloué pour l’exécution de Oq.

Coût du stockage (CS). Le coût monétaire de stockage dans la Formule (4.13) inclut non seulement le coût de stockage des relations de base mais également le coût de stockage des répliques de chaque relation. D’un autre coté, nous prenons en compte l’hétérogénéité de tarification des ressources entre les CDs. Par exemple, chaque CDij a son propre tarif de stockage. Dans la Formule (4.13), le stockage d’une relation/réplique a un coût monétaire Stor_Costij en fonction du prix appliqué dans CDij qui l’héberge. Enfin, nous avons supposé

79

que les relations intermédiaires des opérations en pipeline ne sont pas stockées. Ceci explique pourquoi leur coût de stockage n’est pas inclut dans la Formule (4.13).

Coûts de transferts des données (CNB). Le traitement des requêtes dans des environnements distribués entraîne inévitablement la consommation de la bande passante du réseau en raison du transfert de données entre nœuds.

Le coût unitaire de transfert de données dans un CD est moins coûteux que le transfert de données entre CDs. En conséquence, le coût des transferts de données dépend de l'emplacement des nœuds (transfert intra-CD ou entre CDs  RGi dans notre cas). Dans la Formule (4.13), Netw_Cost représente le coût monétaire moyen des transferts de données lors de l'exécution de Q. Évidemment, il inclut le coût de transfert de données lors de la création d'une nouvelle réplique.

Coûts des pénalités (CP). Les pénalités probables payées par le fournisseur à ses locataires doivent également être prises en compte lors de l’estimation des dépenses du fournisseur. Dans la Formule (4.13), Avg_Pen_Cost correspond aux pénalités probables payées au locataire Ti lorsque l’objectif SLORT n’est pas satisfait.

Bien que le fournisseur prend les précautions nécessaires afin d’éviter le paiement d’une pénalité, par exemple à travers la réplication de données, il se peut que certaines requêtes ne répondent pas à l’objectif SLORT. Dans ce cas, il se doit de payer une pénalité à Ti. Dans notre proposition, nous nous appuyons sur le coût monétaire moyen de pénalité par requête, payé par le fournisseur à ses locataires lors de la précédente période de facturation.

Coûts des estimations (CEst). Comme décrit dans les sections précédentes, la prise de décision de réplication s’appuie sur l’estimation du temps de réponse d’une requête ainsi que l’estimation des revenus et dépenses du fournisseur pour l’exécution d’une requête lorsque la création d’une réplique est envisagée. Ces estimations ont évidemment un coût que nous intégrons dans l’estimation des dépenses du fournisseur. Ce coût est noté par Estim_Cost dans la Formule (4.13).

Coûts de la consommation énergétique (CEnerg). Comme énoncé dans le chapitre 3, la consommation en électricité représente un coût important pour les fournisseurs de Cloud. Ces derniers doivent alors intégrer le coût de la consommation énergétique Energ_Cost dans leurs dépenses comme le montre la Formule (4.13). La consommation énergétique engendrée par une réplication de données doit également être prise en compte. Dans les travaux que nous avons décrits dans ce manuscrit, ce coût est fixé d’avance de manière statique. Actuellement, nous co-encadrons une Thèse à l’IRIT (Séguéla et al., 2019a) qui vise à modéliser cette consommation énergétique tout en l’intégrant à la fonction objectif visée par une stratégie de réplication de données.

Coûts des investissements (CInv). En réalité, les fournisseurs de Cloud payent de nombreux types de dépenses, allant des salaires des employés à la sécurité physique du matériel. Ces coûts ne sont pas directement liés à la réplication de données ou à l'exécution des requêtes. Cependant, le fournisseur voudrait naturellement toujours avoir une marge bénéficiaire suffisante pour couvrir ces coûts. Ainsi, deux manières sont possible pour inclure le coût des investissements dans les dépenses du fournisseur lors de l’exécution d’une requête d’un locataire : (i) le profit monétaire du fournisseur doit être supérieur à un seuil de profit Profit_Th, c'est-à-dire Profit_Q > Profit_Th tels que Profit_Th correspond à un seuil de marge bénéficiaire prédéfini. Ce seuil peut être vu comme étant la montant minimal de profit qu'un

80

fournisseur souhaite générer lors de l'exécution d'une requête, ou (ii) le profit monétaire du fournisseur doit être positif lors de l’exécution d’une requête, c'est-à-dire Profit_Q > 0, tout en incluant le coût des investissements CInv dans les dépenses du fournisseur.

Dans notre cas, nous avons opté pour la deuxième solution en incluant le prix de l’investissement du matériel et des licences logicielles dans Inv_Cost comme le montre la Formule (4.13). Enfin, lorsque le fournisseur loue un service XaaS donné auprès d'un autre fournisseur, ses dépenses en investissement pourraient également inclure le prix de la location de ces services (XaaS_Cost).