メインコンテンツへスキップ

コストのアノマリー

DoiT Anomaly Detection は、Google Cloud、Amazon Web Services、Microsoft Azure、Snowflake、Databricks、Datadog、OpenAI におけるコストスパイクをエンドツーエンドで監視します。

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

以下のセクションでは、DoiT Anomaly Detection の仕組みについて説明します。

ソースデータ​

DoiT Anomaly Detection は、次の 2 種類のソースデータをサポートします。

  • 請求データ：クラウドプロバイダーおよびサードパーティプラットフォームによるコストおよび使用量データ。例：AWS CUR、Google Cloud Billing データエクスポート、Azure billing export など。

  • リアルタイム使用量データ：ほぼリアルタイムのコストアノマリー検知のために、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 レベルのアノマリーについては 1 時間ごと、サービスレベルのアノマリーについては 6 時間ごとに評価が実行されます。

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

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

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

動的な更新​

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

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

  • コストが新しい通常範囲内に戻った場合。

  • アノマリーが最大有効期間に達した場合：請求データに基づく場合は 7 日間、リアルタイム使用量データに基づく場合は 3 日間。

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

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

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

これは、同一サービスに対して SKU レベルのアラートが送信されている場合、サービスレベルのアラートは送信されないことを意味します（その逆も同様です）。

ヒント

CloudFlow triggers を使用してコストアノマリーへの対応を自動化できます。たとえば、アノマリーが検知されたとき、そのステータスやコストが変化したとき、またはアノマリーが確認されたときなどです。フローの開始条件となるイベントの一覧については、Cost anomaly events を参照してください。

月初のスパイク​

一部のサービスでは、月初の 1 日に一括請求が行われるため、月の残りの期間と比べて不均衡なコストスパイクが発生する場合があります。しかし、その金額が過去数か月と同程度であれば、アノマリーとは見なされません。

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

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

月初にコストスパイクが発生するサービス
  • 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
  • Maps Static 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

FAQ​

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

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

クラウドコストのスパイクがアノマリーとして検出されなかった場合、まずそのスパイクがサービス間にまたがる SKU によって発生していないかを評価することが重要です。さらに、アノマリーとして認識されるには、その支出が特定の条件セットを満たしている必要があります。

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

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

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

  • 条件: アラートをトリガーする条件は、例えば「週次コストが 5% 増加」といった単一の閾値です。対照的に、アノマリーと分類されるには、コストが複数の条件を満たす必要があります。

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

一般的に、アラートの方がアノマリー検知よりも「感度が高く」、トリガーされやすいといえます。

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

データ値​

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

対応するレポート（Open in Reports ボタンからアクセス）は、最新のデータを反映しており、直近のタイムステップで値がわずかに異なる場合があります。

データの利用可能性​

アノマリー検知システムは、アラートを迅速に行うため、利用可能な中で最も新しい請求データを使用します。

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

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

実際に操作しながら学べるインタラクティブデモをお試しください。

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

参照

FinOps Foundation: Managing Cloud Cost Anomalies

に最終更新