監査可能な使用状況データと運用上の使用状況データの違い

AI の導入により、使用量の帰属とチャージバックのユースケースが増加しています。現代の企業は、請求、販売、製品開発、クラウドのコスト分析を推進するために、使用状況データを収集して顧客や社内部門に割り当てることにも熱心に取り組んでいます。

FinOps Foundation も最近、 FOCUS (オープン コスト & 使用法仕様) の初期草案を発表しました。使用状況データが複雑になるのはなぜですか?また、イベント メータリングと時系列メトリクスの違いは何ですか?

使用状況データの使用例

請求、分析、ユースケースの監視の複雑さを掘り下げる前に、使用状況データの意味を定義しましょう。使用法は、誰かが一定期間内に商品を消費することを表します。たとえば、午後 1 時から午後 2 時までの間に、Alice は Twillio API 経由で 100 件の SMS を送信しました。

コンピューターは高速ですが、人間の速度は遅いため、使用状況は通常、単一の日付ではなく期間で説明されます。使用状況データを必要とする一般的な使用例をいくつか見てみましょう。

請求:顧客は法的拘束力のある契約条件に基づいて請求されるため、正確な使用状況データが必要になります。データの次元は制限されることが多いですが、顧客ごとに使用状況データを追跡する必要があるため、カーディナリティは高くなります。

リアルタイム データはオプションですが、ユーザーが請求額のしきい値に達した場合は、即時に通知する必要があります。データ保持は請求書を検証するために非常に重要ですが、請求書が決済されるとそれほど重要ではなくなります。

モニタリング:アラートを目的としたリアルタイムの使用状況データが必要です。正確さは重要ですが、請求よりも柔軟です。監視システムは多くの場合、カーディナリティに関して制限されています。

大量の監視データを保存するコストがかかるため、データの保持期間は通常短く、数週間後にはほとんど利用されなくなります。

分析:クラウドのコスト、利益率分析、価格設定などの一般的なユースケースでは、モデルをトレーニングして傾向を効果的に特定するために、過去 3 ～ 5 年間の正確な履歴データが必要です。分析がリアルタイムであることはほとんどありません。

表としてまとめると次のようになります。

ご覧のとおり、各ユースケースには異なるニーズがあるため、使用状況データについて議論する際に混乱を招く可能性があります。

監査可能な運用データの理解

データを監査可能または運用可能として分類するという概念は、2018 年にHoneycomb.ioの共同創設者である Charity Majors のツイートを通じて初めて私の注意を引きました。

データ記録の損失が許容できず、記録の完全な保持が必要な場合、監査可能データはそのように分類されます。監査可能なデータセットを利用する場合、それが包括的で完全であることが期待されます。

監査可能なデータの例には、トランザクション ログ、レプリケーション ログ、請求/財務イベントなどがあります。

逆に、運用データは厳密な完全性を必要としません。管理可能なコストを維持するために、サンプリングが使用されることが多く、ある程度のデータ損失は許容されます。

運用データを管理するために設計されたツールは、多くの場合、作業の効率性を優先し、再試行やコストのかかる 1 回の配信の保証を回避します。運用データの例には、テレメトリ、メトリクス、および各リクエストとシステム コンポーネントを説明するコンテキスト データが含まれます。

使用状況データを収集、処理、保存する方法を決定する前に、データが監査可能である必要があるか、運用可能である必要があるかを判断することが重要です。

次のセクションでは、2 つのデータ収集戦略を比較します。1 つは一般に監査可能なユース ケースに適したイベント ドリブン メータリング、もう 1 つは運用使用状況データを収集するための推奨方法である時系列モニタリングです。

イベント駆動型のメータリングと時系列メトリクスの比較

使用状況データを収集するには、主に 2 つの方法があります。

1. イベント駆動型のメータリングと

   
   

2. 時系列監視システム。

   
   

比較すると次のようになります。

イベント駆動型の計測:使用量ベースの課金会社は、固有のイベントの処理に固有の一貫性があるため監査可能であるため、このアプローチを好みます。イベントは分散システムで二重配信され、一意の識別子を使用して重複を排除して、過剰または過小な請求を防ぐことができます。

メータリングは、すべての顧客の使用状況を追跡するために必要な高いカーディナリティに適切に対応します。ただし、課題はデータ収集にあります。業界には監視用の強力なインフラストラクチャ コレクターがありますが、これらはイベント以外のことを念頭に置いて設計されています。

ほとんどのベンダーはイベント送信用の POST API を提供しており、収集プロセスはユーザーに任せています。

時系列モニタリング: Prometheus のようなモニタリング システムは、カウンターとヒストグラムを収集して、メトリクスを時系列運用データとして保存および提供します。

カーディナリティを低く保つことをお勧めします。これにより、個々のユーザーのリソース消費を大規模に追跡することが困難になります。メトリクスの収集は業界でよく舗装された道であり、ほとんどのインフラストラクチャ コンポーネントですぐに使用できるメトリクス エクストラクタが利用可能です。

APM ベンダーは、データ収集を合理化するために OpenTelemetry などの標準に多大な投資を行っています。課題は、メトリクス コレクターが運用データのユースケースを念頭に置いて設計されているため、配信と重複排除に関する保証が限られていることです。

Prometheus の寄稿者は、精度に関するいくつかの考えをここで共有しています。さらに詳しく知りたい場合は、カウンターの精度を高めるためにスクレイピングを調整することに関する議論をここで見つけることもできます。

表としてまとめると次のようになります。

使用の未来: 統合

現在の課題は、使用状況データの収集と統合にあります。これらのタスクは複雑です。なぜなら、使用状況の収集では (イベントとメトリクスの比較で示されているように) 使用状況ごとに精度、カーディナリティ、およびリアルタイムの側面のバランスをとる必要がある一方で、使用仕様の標準が必要なため統合には時間がかかります。

すべてのカスタム ベンダー API または汎用 PromQL インターフェイスについて考えてみましょう。この統合の欠如により、使用状況データを請求、チャージバック、およびコスト分析のユースケースに統合することが困難になり、多くの場合、使用状況データを相互に共有するのではなく、別個のシステムで使用状況データを収集することになります。

FinOps の焦点: 利用統合のための新しい仕様

FinOps による FOCUS (オープン コスト & 使用状況仕様) は、使用状況データの統合の課題に対処することを目的としています。 FOCUS は、クラウド プロバイダーや SaaS ベンダーによる正規化された使用量の生成と消費、および請求データの仕様の概要を示しています。

FOCUS を使用すると、ベンダー間の使用状況データをシームレスに統合して、請求やクラウドコスト分析のユースケースを実現できます。

FOCUS 仕様は現在開発中です。 0.5 プレビュー バージョンは 2023 年 6 月末にリリースされたばかりで、仕様は現在使用量データよりも請求に重点を置いています。

ここからFOCUSワーキンググループをフォローしたり、参加したりできます。

精度、カーディナリティ、適時性の調整

イベント メータリング システムとメトリクス システムはそれぞれ、ユース ケースに対応するためにビジネスとエンジニアリングの異なるトレードオフのバランスをとっているため、これらのシステムが統合されるとは予想していません。監査可能なデータと運用データの違いについて考えてみましょう。

しかし私は、FinOps の FOCUS のようなベンダー間の使用状況データの統合に関する標準が収束することを期待しています。

皆様のご意見が必要です。請求とチャージバックのユースケースを合理化するために、OpenMeter はメトリクスを取り込み、Prometheus と統合する必要がありますか?

オープンソース リポジトリでお知らせください: https://github.com/openmeterio/openmeter