Avec l'adoption de l'IA, l'attribution de l'utilisation et les cas d'utilisation de la rétrofacturation sont en augmentation. Les entreprises modernes sont également désireuses de collecter et d'attribuer des données d'utilisation à leurs clients et à leurs services internes, pour piloter la facturation, les ventes, le développement de produits et l'analyse des coûts du cloud.
La Fondation FinOps a également dévoilé récemment la première version de son FOCUS (Open Cost & Usage Specification). Pourquoi les données d'utilisation peuvent être complexes et qu'est-ce qui différencie la mesure des événements des métriques de séries temporelles ?
Avant de plonger dans les subtilités de la facturation, de l'analyse et de la surveillance des cas d'utilisation, définissons ce que nous entendons par données d'utilisation. L'usage décrit une personne consommant un bien au cours d'une période donnée. Par exemple, entre 13h et 14h, Alice a envoyé 100 SMS via l'API Twillio.
L'utilisation est généralement décrite pour une période de temps au lieu d'une seule date car les ordinateurs sont rapides, mais les humains sont lents. Examinons quelques-uns des cas d'utilisation courants nécessitant des données d'utilisation :
Facturation : cela nécessite des données d'utilisation précises, car les clients sont facturés sur la base de conditions contractuelles juridiquement contraignantes. Bien que les dimensions des données soient souvent limitées, la cardinalité est élevée car les données d'utilisation doivent être suivies pour chaque client.
Les données en temps réel sont facultatives, mais des notifications rapides sont requises lorsqu'un utilisateur atteint un seuil de facturation. La conservation des données est cruciale pour la validation des factures, bien que cela devienne moins important une fois la facture réglée.
Surveillance : Cela nécessite des données d'utilisation en temps réel à des fins d'alerte. La précision est importante mais elle est plus flexible que la facturation. Les systèmes de surveillance sont souvent limités autour de la cardinalité.
La conservation des données est généralement courte en raison des coûts de stockage de gros volumes de données de surveillance, qui sont rarement utilisées après quelques semaines.
Analytique : les cas d'utilisation typiques tels que le coût du cloud, l'analyse des marges et la tarification nécessitent des données historiques précises des trois à cinq dernières années pour former des modèles et identifier efficacement les tendances. L'analyse est rarement en temps réel.
Résumé sous forme de tableau :
Cas d'utilisation | Précision | Cardinalité | Temps réel | Rétention |
---|---|---|---|---|
Facturation | Haut | Haut | Modéré | 1-2 ans |
Surveillance | Modéré | Faible | Haut | Semaines |
Analytique | Haut | Modéré | Faible | 3+ ans |
Comme vous pouvez le constater, chaque cas d'utilisation a des besoins différents, ce qui peut prêter à confusion lors de l'examen des données d'utilisation.
Le concept de classification des données comme auditables ou opérationnelles a été porté pour la première fois à mon attention en 2018 par le biais d'un tweet de Charity Majors, cofondateur de Honeycomb.io .
Les données vérifiables sont classées comme telles lorsque la perte de tout enregistrement de données est intolérable et que la conservation complète des enregistrements est nécessaire. Lors de l'utilisation d'un ensemble de données auditables, celui-ci doit être exhaustif et complet.
Des exemples de données auditables incluent les journaux de transactions, les journaux de réplication et les événements de facturation/finances.
Les données opérationnelles , à l'inverse, ne nécessitent pas une stricte exhaustivité. Pour maintenir des coûts gérables, l'échantillonnage est souvent utilisé et un certain degré de perte de données est acceptable.
Les outils conçus pour gérer les données opérationnelles donnent souvent la priorité à l'efficacité des efforts, en contournant les tentatives et les garanties coûteuses d'une seule livraison. Des exemples de données opérationnelles incluent la télémétrie, les métriques et les données contextuelles qui décrivent chaque requête et composant système.
Avant de décider de la méthodologie de collecte, de traitement et de stockage de vos données d'utilisation, il est important de déterminer si vos données doivent être auditables ou opérationnelles.
Dans la section suivante, nous comparerons deux stratégies de collecte de données : le comptage événementiel, généralement mieux adapté aux cas d'utilisation auditables, et la surveillance des séries chronologiques, la méthode privilégiée pour collecter les données d'utilisation opérationnelle.
Il existe deux manières principales de collecter des données d'utilisation :
mesure événementielle et
systèmes de surveillance de séries chronologiques .
Voici comment ils se comparent :
Mesure basée sur les événements : les sociétés de facturation basées sur l'utilisation privilégient cette approche car elle est vérifiable en raison de sa cohérence inhérente dans la gestion des événements uniques. Les événements peuvent être livrés en double dans les systèmes distribués et dédupliqués à l'aide d'identifiants uniques pour éviter la surfacturation ou la sous-facturation.
Le comptage gère bien la cardinalité élevée, qui est nécessaire pour suivre l'utilisation de chaque client. Cependant, le défi réside dans la collecte de données. L'industrie dispose de collecteurs d'infrastructure robustes pour la surveillance, mais ceux-ci ont été conçus avec autre chose que les événements à l'esprit.
La plupart des fournisseurs fournissent une API POST pour la soumission d'événements, laissant le processus de collecte à l'utilisateur.
Surveillance de séries chronologiques : les systèmes de surveillance tels que Prometheus récupèrent des compteurs et des histogrammes pour stocker et fournir des métriques sous forme de données opérationnelles de séries chronologiques.
Il est conseillé de garder une cardinalité faible, ce qui rend difficile le suivi de la consommation des ressources des utilisateurs individuels à grande échelle. La collecte de métriques est une voie bien tracée dans l'industrie, avec des extracteurs de métriques prêts à l'emploi disponibles pour la plupart des composants d'infrastructure.
Les fournisseurs d'APM ont beaucoup investi dans des standards comme OpenTelemetry pour rationaliser la collecte de données. Le défi réside dans les garanties limitées du collecteur de métriques concernant la livraison et la déduplication, car ils ont été conçus avec des cas d'utilisation de données opérationnelles à l'esprit.
Les contributeurs de Prometheus partagent ici quelques réflexions sur la précision . Si vous voulez creuser plus profondément, vous pouvez également trouver un débat sur l'ajustement du raclage pour augmenter la précision du compteur ici .
Résumé sous forme de tableau :
Utilisation de la collecte | Auditable | Cohérence | Collecteurs et normes |
---|---|---|---|
Mesure des événements | Oui | Haut | Faible |
Métriques de séries chronologiques | Non | Modéré | Haut |
L'enjeu actuel réside dans la collecte et l'intégration des données d'usage. Ces tâches sont complexes car la collecte de l'utilisation doit équilibrer la précision, la cardinalité et les aspects en temps réel différemment selon les cas d'utilisation (comme illustré dans la comparaison des événements par rapport aux métriques), tandis que l'intégration prend du temps en raison de la nécessité d'une norme de spécification d'utilisation.
Pensez simplement à toutes les API personnalisées des fournisseurs ou à l'interface générique PromQL. Ce manque de consolidation crée des difficultés pour intégrer les données d'utilisation dans les cas d'utilisation de facturation, de refacturation et d'analyse des coûts, ce qui entraîne souvent des systèmes séparés pour la collecte des données d'utilisation plutôt que de les partager entre eux.
FOCUS (Open Cost & Usage Specification) by FinOps vise à répondre aux enjeux d'intégration des données d'usage. FOCUS décrit une spécification pour la production et la consommation de données d'utilisation et de facturation normalisées par les fournisseurs de cloud et les fournisseurs de SaaS.
FOCUS vous permettra d'intégrer de manière transparente les données d'utilisation entre les fournisseurs, pour la facturation et les cas d'utilisation d'analyse des coûts du cloud.
La spécification FOCUS est actuellement en cours de développement ; la version d'aperçu 0.5 vient d'être publiée fin juin 2023, et la spécification est actuellement davantage axée sur la facturation que sur les données d'utilisation.
Vous pouvez suivre ou rejoindre le groupe de travail FOCUS ici .
Je ne prévois pas une convergence des systèmes de mesure et de métrique des événements, car ils équilibrent chacun des compromis commerciaux et techniques distincts pour répondre à leurs cas d'utilisation. Pensez simplement aux différences entre les données vérifiables et opérationnelles.
Mais je m'attends à une convergence sur les normes concernant l'intégration des données d'utilisation entre les fournisseurs comme FOCUS de FinOps.
Nous avons besoin de votre contribution. OpenMeter devrait-il ingérer des métriques et s'intégrer à Prometheus pour rationaliser les cas d'utilisation de facturation et de rétrofacturation ?
Faites-le nous savoir dans notre référentiel open source : https://github.com/openmeterio/openmeter