Unité 2.4 : Architecture de coût et FinOps

Introduction

Le coût du cloud sur IONOS n'est pas un problème de facturation résolu a posteriori ; il s'agit d'une propriété architecturale décidée au moment de la conception, lorsque vous choisissez une classe de calcul, un niveau de stockage, une stratégie de mise à l'échelle et un terme d'engagement. Chacun de ces éléments est un levier, et ils diffèrent énormément en magnitude : le choix de contention de calcul peut modifier la facture plus que tous les réglages du tableau de bord combinés. FinOps ici est donc principalement une question d'architecture, avec une fine couche opérationnelle d'allocation et d'alerte en haut. Cette unité présente les leviers dans l'ordre de leur impact, explique comment les Savings Plans engagent correctement les dépenses, et se termine par la construction de la seule garde-fou bien documentée, une alerte de coût, dans le Data Center Designer.

1. Contention de calcul : le premier levier de coût

La décision de coût la plus importante est la façon dont une charge de travail partage des CPU physiques. Compute Engine offre deux classes d'utilisation de CPU : des serveurs Dedicated Core, où le core est Exclusif à la VM, et des serveurs vCPU, où le core est Partagé avec d'autres locataires. Les cores partagés sont moins chers et conviennent aux charges de travail à bursty, tolérantes en termes de latence ou non productives. Les cores exclusifs coûtent plus cher et sont nécessaires lorsque les performances doivent être prévisibles ou lorsque l'isolement est en soi une exigence, ce qui est souvent le cas pour un patrimoine réglementé.

C'est ici que la sur-approvisionnement délibérée devient un coût de contrôle justifié plutôt que du gaspillage. Pour les hôtes réglementés de FinCorp, la mono-locataire et les performances prévisibles sont des entrées de conformité et de risque, donc payer pour des cores dédiés (et approvisionner une marge au-dessus de la ligne de base mesurée) achète l'isolement et la stabilité que les économies de core partagé pourraient compromettre. La discipline consiste à être délibérée : sur-approvisionner les hôtes qui portent des obligations de conformité ou de performance, et utiliser des cores partagés partout où la charge de travail tolère la contention. Notez également que VM Auto Scaling crée de nouvelles répliques à partir d'un modèle de réplique de conception, donc un niveau qui doit être mis à l'échelle automatiquement a sa forme de calcul par réplique, et donc son coût par réplique, fixé au moment de la conception, ce qui intègre la décision d'élasticité dans la décision de coût.

2. Hiérarchisation du stockage pour accéder au modèle d'accès

Le coût de stockage est déterminé en faisant correspondre le niveau au modèle d'accès, et les trois niveaux de blocs présentent des points de prix matériellement différents. Les prix publiés par Go sont les suivants :

Deux contraintes façonnent le choix au-delà du prix. Premièrement, le plancher de performance de SSD : les volumes SSD Standard et SSD Premium nécessitent une taille minimale de 100 Go pour atteindre les performances complètes, donc un SSD Volume sous-dimensionné paie les prix SSD sans offrir les performances SSD, ce qui est un gaspillage courant et évitable sur les disques de base de données. Deuxièmement, Block Storage n'est pas le lieu pour les données bulk ou d'archive ; Object Storage est le niveau approprié pour les sauvegardes, les archives d'audit, les jeux de données et les données froides, et c'est là que vit l'archive Object-Lock de l'unité 2.3. Le modèle consiste à mettre des données chaudes et sensibles à la latence sur des SSD de taille appropriée, des données de capacité sur HDD, et tout ce qui est bulk ou d'archive sur Object Storage.

3. Montée en puissance versus mise à l'échelle basée sur le cache pour le niveau des données

Le niveau des données a une forme de coût distinctive car la plateforme n'a pas de réplicas de lecture (Unité 1.3 et Module 5). Les deux façons de gérer la charge de lecture croissante ont des économies très différentes. La montée en puissance signifie acheter une instance de base de données plus grande, ce qui entraîne un coût prévisible, toujours actif, et finit par atteindre des plafonds. La mise à l'échelle des lectures signifie placer un cache en mémoire dans le niveau relationnel et absorber le trafic de lecture à cet endroit, ce qui est généralement beaucoup moins cher par lecture servie et protège la base de données de l'être surdimensionnée uniquement pour gérer les pics de lecture. Pour la plupart des charges de travail FinCorp à forte intensité de lecture, une base de données de la bonne taille plus un niveau de cache coûte moins cher qu'une base de données toujours surdimensionnée, et c'est également le seul chemin de mise à l'échelle horizontale des lectures que la plateforme offre. La leçon en matière de coût est de dimensionner la base de données en fonction de ses besoins d'écriture et de jeu de travail, et de laisser le cache, et non une instance plus grande, absorber la croissance des lectures.

4. Plans d'économies : s'engager correctement sur le plancher

Un Plan d'économies est un engagement basé sur les ressources qui échange un terme fixe pour une réduction sur les serveurs Compute Engine Dedicated Core, les Managed Kubernetes Dedicated Core Node Pools, et Nextcloud Workspace, couvrant les dimensions des cœurs et des RAM (Go). Les économies sont précises :

Plusieurs règles rendent cela sécurisé uniquement si vous les respectez. Un plan réserve la facturation, et non la capacité physique, il ne bloque donc jamais la mise en service. Le débordement est géré de manière élégante : l'utilisation au-dessus de la quantité engagée est facturée au tarif standard à la demande, donc le seul véritable risque est la sur-engageance. Lorsque plusieurs plans couvrent le même produit, ils s'appliquent dans l'ordre chronologique de création, et au sein d'un produit, la réduction s'applique dans l'ordre des VM les plus anciens. La famille de processeurs AMD Opteron CPU est exclue. Un plan ne se renouvelle pas automatiquement, et seul le propriétaire d'un contrat peut en acheter un.

Le fait opérationnel le plus important est qu'un Plan d'économies ne peut pas être modifié après activation ; le seul champ modifiable est le nom du plan, et il ne peut pas être annulé après achat. Cela rend la décision d'engagement unilatérale, et cela dicte la discipline : s'engager sur le plancher. N'engagez que la ligne de base de l'état stable que vous êtes certain de maintenir pendant tout le terme, prenez le débordement à la demande pour tout ce qui dépasse, et prolongez le terme uniquement pour la capacité dont vous êtes certain qu'elle persiste pendant trois ans. S'engager de manière optimiste sur l'utilisation de pointe verrouille les dépenses que vous ne pouvez pas réduire ; s'engager sur le plancher permet de capter la réduction sur l'utilisation garantie tout en laissant la charge variable sur la facturation à la demande flexible.

5. Allocation, Showback et Chargeback

L'allocation des coûts repose sur la structure de l'unité 2.1. Puisque chaque centre de données virtuel produit déjà sa propre section sur la facture mensuelle, la hiérarchie contrat-centre de données virtuel est l'axe d'allocation principal : un contrat regroupe un domaine de gouvernance et de facturation, et les centres de données virtuel à l'intérieur séparent les environnements ou les projets en lignes de facturation distinctes. La vue Coûts et utilisation dans le DCD est la surface d'analyse pour cela, et un API Coûts et utilisation existe pour alimenter les flux de travail de facturation de manière programmatique.

L'allocation prend en charge deux modèles de fonctionnement. Les rapports Showback présentent à chaque équipe ou projet sa part de coûts pour la visibilité et la responsabilité sans déplacer d'argent. Le Chargeback facture réellement le coût à l'unité qui le consomme. Le Showback est le point de départ le plus léger et est généralement suffisant pour modifier le comportement ; le Chargeback ajoute une force financière au coût de plus de machinerie de facturation. Pour FinCorp, la mise en correspondance des centres de données virtuel avec les projets de sorte que chacun atterrisse sur sa propre ligne de facturation donne un Showback propre immédiatement, avec un Chargeback ajouté plus tard si la finance l'exige. (Traitez le tableau de bord et la navigation d'allocation comme la couche d'analyse ; la construction ci-dessous est la barrière de garde de l'alerte de coût, qui est le chemin de création bien documenté.)

DCD Déploiement étape par étape

Vous allez créer une alerte de coût qui envoie un e-mail à un destinataire lorsque les dépenses du contrat dépassent un seuil de budget. Il s'agit de la construction de coût bien documentée ; c'est le garde-fou opérationnel qui fait office de soutien aux leviers architecturaux ci-dessus. Le prérequis est l'accès de propriétaire de contrat ou d'administrateur, puisque seuls ces rôles peuvent créer des alertes de coût. Notez que l'alerte est définie au niveau du contrat (un montant et un e-mail), donc l'allocation entre les VDC est une préoccupation de rapport gérée dans la vue Coût et utilisation, et non dans l'alerte elle-même.

Objectif de construction : Créer une alerte de coût contre un seuil de budget.

Étapes (dans le Data Center Designer) :

1. Allez dans Menu > Gestion > Alerte de coût. La fenêtre Alerte de coût s'ouvre ; cette vue liste également les alertes existantes.
2. Choisissez Créer une alerte de coût.
3. Dans la boîte de dialogue, entrez le montant (le seuil de dépense pour le contrat) et l'adresse e-mail qui doit être notifiée.
4. Choisissez Créer une alerte de coût pour confirmer. L'alerte est maintenant active et enverra un e-mail au destinataire une fois que les dépenses du contrat dépassent le seuil.

Erreurs courantes :

• S'attendre à ce que l'alerte limite ou arrête les dépenses. Elle ne fait que notifier ; c'est un signal d'alarme, et non une mise en œuvre stricte du budget. Les dépenses continuent au-delà du seuil.
• La configurer par VDC. L'alerte de coût est au niveau du contrat (montant plus e-mail) ; utilisez la vue Coût et utilisation pour l'analyse et l'allocation par VDC.
• Se fier aux alertes au lieu de l'architecture. L'alerte détecte les écarts ; les décisions concernant la classe de calcul, le niveau de stockage et le plan d'économies sont celles qui fixent réellement la facture.
• Diriger l'alerte vers une boîte aux lettres personnelle. Envoyez-la à une adresse de finance ou d'exploitation surveillée afin que la notification soit vue et traitée.

Modèle d'architecture

Un modèle d'architecture de coûts FinCorp défendable superpose les leviers par impact. À la base, la classe de calcul est choisie par niveau : des cœurs dédiés pour les niveaux réglementés et auto-évolués (avec une marge de manœuvre délibérée en tant que coût de contrôle justifié), des cœurs partagés pour les charges de travail tolérantes et non productives. Le stockage est hiérarchisé en fonction du modèle d'accès, avec des volumes SSD maintenus à ou au-dessus du plancher de 100 Go et des données bulk/archive sur Object Storage. Le niveau de données est dimensionné pour les écritures et l'ensemble de travail, avec un cache en mémoire absorbe la croissance des lectures au lieu d'une base de données surdimensionnée. Au-dessus, un Plan d'économies ne s'engage qu'à la base de cœurs dédiés et RAM sur un délai correspondant à une persistance réelle, en prenant le débordement PAYG au-dessus. En haut, les cartes d'allocation relient les VDC aux projets pour le suivi des coûts, et une alerte de coût au niveau du contrat fournit le déclencheur de dérive. À titre de chiffre travaillé, un niveau qui fonctionne de manière constante avec 32 cœurs dédiés coûterait environ 1,28 EUR de l'heure en PAYG (32 x 0,04) ; s'engager sur ce plancher sur un plan de 3 ans ramène le coût du cœur à environ 0,77 EUR de l'heure (32 x 0,024), soit une réduction de 40 % par rapport à la base garantie, alors que toute poussée au-dessus de 32 cœurs est toujours facturée en PAYG.

Résumé

Le coût du cloud chez IONOS est conçu, et non simplement surveillé. La classe de contention de calcul est le plus grand levier, avec une sur-approvisionnement délibérée des hôtes dans le cadre de la justification d'un coût de contrôle ; le stockage est hiérarchisé pour accéder au modèle dans le plan de performance de SSD ; et le niveau de données met à l'échelle les lectures à travers un cache plutôt qu'une instance surdimensionnée. Les Plans d'économie capturent les remises de 15 % (1 an) et 40 % (3 ans) sur les cœurs dédiés et RAM, mais ne peuvent pas être modifiés après activation, ce qui oblige à s'engager uniquement sur le plancher certain et à prendre le débordement à la demande. L'allocation suit la structure de contrat et de VDC pour le showback ou le chargeback, et une alerte de coût au niveau du contrat fournit le déclencheur opérationnel intégré dans le DCD.

Points clés :

• La contention de calcul est le premier levier de coût : les cœurs partagés sont moins chers, les cœurs exclusifs (dédiés) offrent une prévisibilité et une isolation ; l'auto-mise à l'échelle fixe la forme de calcul de chaque réplique au moment de la conception, en intégrant l'élasticité dans la décision de coût.
• Hiérarchiser le stockage en fonction du modèle d'accès : HDD 0,04, SSD Standard 0,07, SSD Premium 0,15 EUR/GB/mois ; maintenir les volumes SSD à ou au-dessus du plancher de performance complet de 100 GB ; mettre les données en vrac et les archives sur Object Storage.
• Mettre à l'échelle les lectures du niveau de données avec un cache en mémoire, et non avec une base de données surdimensionnée, puisqu'il n'y a pas de répliques de lecture.
• Les Plans d'économie offrent des remises de 15 % (1 an) et 40 % (3 ans) sur les cœurs dédiés et RAM, le débordement est facturé à la demande, les plans s'appliquent du plus ancien au plus récent, et ils ne peuvent pas être modifiés après activation, il faut donc s'engager uniquement sur le plancher certain.
• Allouer par contrat et VDC (chaque VDC facture déjà sa propre ligne) ; choisir le showback ou le chargeback ; une alerte de coût au niveau du contrat (montant plus e-mail) est la barrière de sécurité de construction et ne notify uniquement, elle ne limite pas les dépenses.

Terminologie importante :

• Classe d'utilisation de CPU : Que les cœurs d'un serveur soient Exclusifs (Cœur dédié) ou Partagés (vCPU) ; le principal levier de coût et de performance de calcul.
• Plan d'économie : Un engagement de facturation de 1 an ou 3 ans basé sur les ressources pour les cœurs dédiés et RAM, avec un débordement à la demande, non modifiable après activation, achetable uniquement par le propriétaire du contrat.
• Showback / Chargeback : Signaler à une équipe sa part de coût pour la responsabilité (showback) par opposition à la facturation réelle du coût à cette équipe (chargeback).
• Alerte de coût : Un seuil au niveau du contrat (montant plus e-mail) qui notify en cas de dépassement de dépenses ; il avertit mais ne limite pas.