メインコンテンツまでスキップ

コストのアノマリー

DoiT アノマリー検知は、Google Cloud、Amazon Web Services、Microsoft Azure、Snowflake、Databricks、Datadog、および OpenAI におけるコストスパイクをエンドツーエンドで監視します。

この検知サービスは、時系列モデリング を活用してデータを監視し、クラウド環境での支出トレンドを分析します。DoiT 顧客全体の請求パターンを特定し、クラウド支出を予測し、精度を高めるため継続的に改善されています。確立された支出行動に一致しない請求レコードは、潜在的なアノマリーとして特定されます。DoiT コンソールは、調査や必要に応じた是正措置に役立つよう、寄与リソースの一覧 や AI 分析 などの詳細情報を提供します。

以下のセクションでは、DoiT アノマリー検知の仕組みを説明します。

ソースデータ​

DoiT アノマリー検知は、2 種類のソースデータをサポートします。

  • 請求データ: クラウドプロバイダーやサードパーティプラットフォームのコストと使用量データ。例：AWS CUR、Google Cloud Billing データエクスポート、Azure 請求エクスポートなど。

  • リアルタイム使用量データ: ほぼリアルタイムのコストアノマリー検知のために、DoiT は次のサービスのコストを推定する目的でリアルタイム使用量データを活用します。

ベースライン期間​

アノマリー検知システムは、新規登録直後からデータの分析を開始します。ただし、正確な検知には十分な履歴データが必要です。機械学習モデルが請求データおよびリアルタイムデータに基づく使用パターンの信頼できるベースラインを確立できるよう、請求データは 14 日間、リアルタイム使用量データは 4 日間 をベースライン期間として設定します。

運用上アノマリー検知が重要な場合は、クラウド支出に大きな変更を加える前にベースライン期間が経過するまで待つことをおすすめします。ベースライン期間中は支出がアノマリーとして分類されることはありません。

集計レベル​

アノマリー検知システムは、SKU レベル と サービスレベル の両方でコストおよび使用量データを監視・評価する時系列モデルを活用します。履歴パターンを分析し、現在の使用傾向と比較することで、重要なコストスパイクを検知するよう設計されています。アノマリーなコストスパイクが検知されると、アノマーリーアラート がトリガーされます。

設定データ（請求データ）​

請求データについては、解決までの時間を短縮するため、アノマリー検知システムは主に SKU レベルで動作します。つまり、検知されるコストのアノマリーの多くは SKU レベルのアノマリーになります。

サービスレベルでの監視は、主に新規プロジェクトや新規 SKU によって引き起こされる初期スパイクに対処する補完的な役割を果たします。新しいプロジェクトが作成された場合、または新しい SKU でコストが発生し始めた場合、新しい時系列 が特定され、コストデータの収集を開始します。しかし、十分な履歴データポイント がないため、最初の数日間は新しい時系列で SKU レベルのアノマリー候補は生成されません。新しい時系列の「正常」な支出がまだ確立されていない間でも、新たに発生したコストがサービスレベルでアノマリーなスパイクを引き起こす可能性があります。

リアルタイム使用量データ​

2025 年 5 月 21 日以降、時間単位の粒度を持つリアルタイム使用量データ向けのアノマリー検知システムは、高解像度サンプリングによるノイズを低減するため、サービスレベルのみで動作します。

評価スコープ​

システムが評価するデータサンプルは、次のように分割されます。

  • 請求アカウント単位
  • プロジェクト／アカウント単位
  • サービス単位
  • SKU 単位
  • アロケーション単位（該当する場合）

評価のスコープは集計レベルによって異なります。

  • SKU レベル：SKU ごと、サービスごと、リージョンを跨いだプロジェクト／アカウントごと
  • サービスレベル：サービスごと（プロジェクトおよび SKU を横断）

検知システムは、複数サービスの合算コストは評価しません。

判定基準​

誤検知を軽減するため、アノマリー検知システムは、以下のすべての基準を満たした場合にのみ、SKU またはサービスの支出をアノマリーと分類します。

請求データ​

  1. 1 日あたりの支出が最小閾値に達していること：

    • SKU レベルのアノマリー：US$50

    • サービスレベルのアノマリー：US$100

  2. 1 日あたりの支出が月次の季節性を上回っていること。

  3. 1 日あたりの支出が、システムの_正常範囲_（または_許容範囲_）の上限を上回っていること。

リアルタイム使用量データ​

  1. 1 時間あたりの支出が US$10 の最小閾値に達していること。

  2. 1 時間あたりの支出が、システムの_正常範囲_（または_許容範囲_）の上限を上回っていること。

感度​

アノマリー検知システムは、直前期間のデータで学習した時系列モデルを使用して想定支出を予測します。正常範囲は DoiT 固有の予測区間によって決定されます。これは、あるパーセンテージの可能な値が収まると見積もられる区間です。例えば、90% の予測区間は、モデルに適合した過去の値に基づいて、新しいデータポイントが取り得る可能な値の 90% を含みます。正常範囲は、コストアノマリーのチャート上で陰影領域として示されます。

DoiT コンソールでは、アノマリー感度設定を調整して予測区間を変更し、それにより正常範囲を再定義できます。感度を高くすると範囲が狭まり、検知されるアノマリー数が増加します。感度を低くすると範囲が広がり、検知数が減少します。

検知レイテンシ​

検知レイテンシはソースデータの種類によって異なります。

請求データ​

多くの場合、集計コストがあらかじめ定義された閾値を超えると、12 時間以内に請求データのアノマリーが報告されます。

アノマリー検知エンジンは、定期的な間隔で使用量とコストデータを評価します。SKU レベルのアノマリーについては毎時、サービスレベルのアノマリーについては 6 時間ごとに評価が実行されます。

検知レイテンシは主に、クラウドプロバイダーが使用量およびコストデータを報告する間隔の違いに関連します。あわせて Data latency も参照してください。

リアルタイム使用量データ​

アノマリー検知エンジンは、リアルタイム使用量データを 30 分ごとに評価します。リアルタイム使用量データで検知されたアノマリーは、使用から 1 時間以内に報告されます。

動的アップデート​

進行中のアノマリーは Active と見なされます。検知システムは アクティブ なアノマリーを監視し、利用可能な最新データでシステムを継続的に更新します。

次のいずれかの条件を満たすと、アノマリーは Inactive になります。

  • コストが新しい平常の範囲に戻る。

  • アノマリーが最大アクティブ期間に達した場合（請求データに基づき 7 日間、リアルタイム使用データに基づき 3 日間）。

アノマリーが Active と Inactive になるタイミングの詳細は、コストのアノマリーのチャートを参照してください。

コストのアノマリーのアラート​

アノマリーが検出されると、システムは請求アカウント・サービス・プロジェクト ID を確認し、同じコンテキストに対して既に他のアラートが送信されていない場合にのみアラートがトリガーされるようにします。

つまり、同じサービスについて、SKU レベルのアラートが送信されている場合はサービスレベルのアラートは送信されません。その逆も同様です。

月初のスパイク​

一部のサービスは毎月 1 日に一括請求を適用するため、月の残りの期間と比べてコストが不均衡にスパイクする場合があります。ただし、その金額が前月までと同程度であれば、アノマリーとは見なしません。

精度を高めるため、月初のコスト評価では、日次のコストモデリングに加えて月次比較も行います（ニアリアルタイムのアノマリー検知は、より短期間で粒度の細かい評価を行うため、月次の季節性は考慮しません）。

以下は評価対象のサービス一覧です。

Services with cost spikes at the beginning of the month
  • Amazon API Gateway
  • Amazon Cognito
  • Amazon DynamoDB
  • Amazon ElastiCache
  • Amazon GuardDuty
  • Amazon Managed Service for Prometheus
  • Amazon OpenSearch Service
  • Amazon Redshift
  • Amazon Rekognition
  • Amazon Relational Database Service
  • Amazon Route 53
  • Amazon WorkSpaces
  • AWS Certificate Manager
  • AWS Data Transfer
  • AWS Elemental MediaConvert
  • AWS End User Messaging
  • AWS Identity and Access Management Access Analyzer
  • AWS Outposts
  • AWS Shield
  • Bright Data Enterprise non metered
  • Cloud Navigator
  • Compute Engine
  • Contact Center Telecommunications (service sold by AMCS, LLC)
  • Coralogix
  • Datadog
  • Datadog Pro
  • Directions API
  • Drata Security & Compliance Automation Platform
  • Fastly for GCP Marketplace
  • Geocoding API
  • Geolocation API
  • Grafana Cloud observability: Grafana, Prometheus metrics, logs, traces
  • HYCU R-Cloud™ Platform
  • Identity Platform
  • JFrog DevOps Platform - Enterprise X
  • JFrog Software Supply Chain Platform
  • Looker Studio
  • Maps API
  • Office LTSC Professional Plus 2021
  • Places API
  • Plerion Cloud Security Platform (Contract)
  • Snyk: Developer Security Platform
  • Twilio Segment
  • Vantage Cloud Cost Platform - Enterprise
  • WIZ Cloud Infrastructure Security Platform

よくある質問​

コストのスパイクがアナウンスされず、アノマリーとして報告されなかったのはなぜですか？​

アノマリー検知システムは、SKU レベルとサービスレベルの 2 つのレベルでコストを評価します。異なるサービスにまたがる複数の SKU の合算コストは評価対象ではありません。

クラウドコストのスパイクがアノマリーとして検出されなかった場合、まずそのスパイクがサービスをまたぐ SKU によって引き起こされたかどうかを評価することが重要です。加えて、アノマリーとして認定されるには、支出が特定の基準セットを満たす必要があります。

アノマリー検知はコストアラートとどう違いますか？​

アノマリー検知は、以下の点でコストアラートと異なります。

  • 範囲: アノマリー検知は個々の SKU およびサービスを監視しますが、コストアラートの範囲はより柔軟です。

  • 条件: アラートのトリガー条件は単一の閾値です（例：毎週のコストが 5.00% 増加）。一方、アノマリーと分類されるには、コストが複数の基準を満たす必要があります。

  • 客観性: アラートは客観的な閾値に反応しますが、アノマリー検知は当てはめた時系列モデルにより確立された想定支出パターンも考慮します。

一般に、アラートはアノマリー検知よりも「敏感」で、より容易にトリガーされます。

コストのアノマリーのアラートは、そのレポートとどう違いますか？​

データ値​

コストのアノマリーのアラートに含まれるチャートは、検知時点の請求データのスナップショットを提供します。

対応するレポート（レポートで開くボタンからアクセス）では、最新のデータが反映され、直近の時点でわずかに異なる場合があります。

データの可用性​

アノマリー検知システムは、アラートを迅速化するために最も新しい請求データを使用します。

レポートは追加処理を要する、より詳細なテーブルを使用するため、データの可用性に遅延が生じます。その結果、アラートをトリガーした請求データが、アラート送信時点では一時的にレポートで利用できない場合があります。

▶️ インタラクティブデモ​

インタラクティブデモを試して、ハンズオンの手順を体験してください。

デモが正しく表示されない場合は、ブラウザウィンドウを広げるか、新しいタブでデモを開くことをお試しください。

参照

FinOps Foundation: クラウドコストのアノマリーの管理

に最終更新