Datadogのコストを徹底解説 料金プラン・課金方法・コスト最適化の方法も紹介
はじめに
Datadogには様々な機能やサービスが存在し、
それぞれ個別に単価が設定され、課金方法も異なります。
サービスの数が多く、内容も幅広いので、なかなか理解しづらいと言う人もいるかと思います。
そこでこの記事では、Datadogの各サービスの意味と課金方法について解説します。
また、コスト影響要因からコストを最適化するためのヒントも提示します。
ぜひ参考にしていただければと思います。
Datadog の料金プランと課金方法
Datadogには主に3種類の料金プランが用意されています。
- Free
- Pro
- Enterprise
料金プランの中にさらに3種類の契約タイプが存在し、
オンデマンド使用量とコミット使用量に応じて課金される仕組みとなっています。
- Pay-As-You-Go
- オンデマンドのみ
- Monthly
- 月契約
- オンデマンドとコミット
- Annually
- 年契約
- オンデマンドとコミット
オンデマンドとコミットではそれぞれ単価が異なり、料金プランによっても変わります。
詳しくは以下の料金表にも記載されています
以下は、主なサービス項目と ProプランのMonthly契約の場合の単価一覧をまとめております。
| 項目 | Pro Monthly単価 | 概要 |
|---|---|---|
| Infra Hosts | $18 | 監視するホストの数 |
| Fargate Tasks | $1.20 | 監視するFargateタスクの数 |
| Containers | $1 | 監視するコンテナの数 |
| APM Hosts | $36 | APMトレース対象のホストの数 |
| APM Fargate Tasks | $2.40 | APMトレース対象のFargateタスクの数 |
| Ingested Spans | $0.10 | Datadogに転送されたSpanの数 |
| Indexed Spans | $2.04(15day) | (15日間)インデックスされたSpanの数 |
| Ingested Logs | $0.10 | Datadogに転送されたログの量 |
| Indexed Logs | $1.52(7day) | (7日間)インデックスされたログの量 |
| Synthetics API Test Runs | $6 | APIテストの回数 |
| Synthetics Browser Test Runs | $15 | ブラウザテストの回数 |
Infrastructure
DatadogにおけるInfrastructureとは
監視するホスト,コンテナ,Fargateタスク,設定したカスタムメトリクスなどを対象としており、
それぞれに課金されます。
Infra Hosts
対象
- Datadog Agent を導入し監視対象となっているインフラホスト（物理サーバやEC2などのVM）
- モニタリングするインフラホスト数に基づいて課金される
コスト影響要因
- 1ヶ月の稼働ホスト数
- 1時間あたりの平均稼働ホスト数
最適化ヒント
- 稼働ホスト数を正確にモニタリングし、不要なホストが稼働していないか定期的に確認する
- 必要に応じてホストをスケールインする設定を自動化し、リソースを効率的に管理する
- 非稼働時間帯や利用頻度の低いサーバーには、Datadog Agentの稼働を一時的に停止する
補足
Infra Hosts はDatadogのコストの中でも、多くの割合を占めます。
無駄な監視対象が含まれていないかをDatadogの画面から確認しましょう。
1ヶ月の稼働ホスト数については以下のように確認できます。
DatadogのCost画面に下部に
Usage Summary があり Infrastructure タブから確認できます。
こちらの例の場合だと
Infra Hosts 52.0K と言う表示になっています。
これは、
-
30 COMMITTED: 1時間あたりの平均稼働ホスト数を commit 30 -
30.4K ON-DEMAND: 1ヶ月の稼働ホスト数の総量は 30,400
1ヶ月を時間換算で720時間
30 × 720 + 30,400 = 52,000が1ヶ月のインフラホストの稼働数ということを表しています。
Proプランの場合、コミット単価が$18なので
$18 × 30commit = $540
残りのオンデマンドの単価は契約によって違いますが、
例えば $0.035の場合
$0.035 × 30,400 = $1,064
実際どれくらいの料金がかかったかは
Summaryの中に、
ON-DEMAND COST , COMMITED COST , TOTAL COST で確認ができます。
Fargate Tasks
対象
- AWS Fargate で動作しているタスクで監視対象となっている数
- Agentを導入したFargateタスクからメトリクスを取得
- 主にDatadog Agentコンテナをサイドカーとして起動、タグの設定でメトリクス収集を行う
コスト影響要因
- 実行中のFargateタスク数
最適化ヒント
- タスクの稼働時間や使用状況を確認し、不要なタスクのスケールダウンや停止を検討する
- タグを利用して、リソース別の利用状況を可視化し、無駄を特定する
- スケジューリングの設定を見直し、タスク実行の頻度を最適化する
Containers
対象
- 主にFargate, Kubernetes, GKEなどの環境下で、Datadog Agent を導入しているホストの上に成り立つコンテナ
- コンテナのランタイムデータを収集している
- Datadog Agentコンテナは対象にならない
コスト影響要因
- 監視対象のコンテナ数
- コンテナ数は5分ごとに計測され、これを基に1時間あたりの平均使用量を算出し、無料枠から差し引いた分がオンデマンドとして課金される
最適化ヒント
- コンテナのスケールイン/スケールアウト設定を見直し、最適な数で稼働させる
- KubernetesやFargateなどで稼働しているコンテナにラベルを適切に設定し、監視対象を絞り込む
- プランごとに1ホストで使える無料枠が設定されているので、ホストの数とコンテナの数の適正化をする
(Proプランでは1ホストあたり5コンテナの無料枠を利用できる)
Containersに関しては以下のページに詳細があります。
APM
APMはアプリケーションのパフォーマンス分析に使われ、
ホストやFargateタスクの数、APMスパンの取り込み量やインデックス量によって課金されます。
APM Hosts
対象
- Datadog APMでトレースを収集するホスト
- アプリケーションにAPMエージェントをインストールしてトレースデータを収集することによって対象となる
コスト影響要因
- APMが導入されているホスト数
- スパン・トレースの収集量
最適化ヒント
- トレース対象を最重要なエンドポイントやサービスに限定し、無駄なトレースを削減する
- Datadogのサンプリング設定を活用し、重要でないリクエストのトレース数を減らす
- 必要以上に多くのホストにAPMエージェントを導入しないよう注意する
APM Fargate Tasks
対象
- Fargateで実行中のAPMトレース対象のタスク
- アプリケーションにエージェントを設定したり、タグ付けすることによってメトリクスが収集され課金対象になる
コスト影響要因
- APMスパン・トレースの収集対象のFargateタスクの数
最適化ヒント
- タグ付けを活用して重要なFargateタスクを優先的に監視対象とする
- APMエージェントを最適化し、不要なスパンやトレースを収集しないように設定する
- 実行頻度の高いタスクについてはリソース割り当てを効率化し、タスク数を最小限に抑える
Ingested Spans
対象
- Datadogに取り込まれたAPMトレースの全スパン数
- インデックス化されているスパンは Indexed Spans が対象
コスト影響要因
- APMに取り込まれたスパンのギガバイトの総数に基づき課金される
- 全プラン一律で 1GB あたり 0.10ドル / 月 かかる
最適化ヒント
- APMのフィルターを設定し、収集が不要なスパンをDatadogに取り込まないようにする
- トレースデータの取り込み量をモニタリングし、重要でないデータの収集頻度を低下させる
- 無駄なスパンの生成を回避するため、アプリケーションコードのトレースロジックを見直す
補足
APMにはSpan(スパン)とTrace(トレース)という概念があります。
- Span: アプリケーションへのリクエストの処理時間やエラーなどを表す単位
- Trace: 複数のSpanで構成される一連のリクエストフローのこと
1. HTTPリクエストを受信（Span A）
2. APIサーバがリクエストを処理（Span B）
3. ステータスコード200 or 5xxエラーで処理（Span C）
上記の1,2,3 の一連の流れがTrace
APMはこの Span および Trace の取り込み量によってコストがかかってきます。
Indexed Spans
対象
- APMトレースデータの一部（スパン）が保持フィルターにインデックス化されて検索や分析が可能になったスパン
- デフォルトで15日間の保持期間
コスト影響要因
- インデックス化対象のスパン数
- インデックスの保持期間
最適化ヒント
- インデックス化が必要なスパンを最小限に抑え、検索・分析に不要なデータのインデックス化を防ぐ
- インデックス保持期間によって単価が変わり、期間が長くなるほど高くなるので、保持期間を適切に設定する
- Datadogのインデックスフィルターポリシーを活用し、不要なスパンを除外する
Logs
Datadogにログを転送するように設定すると、
そのログの取り込み量やインデックス量に応じて課金されます。
Ingested Logs
対象
- Datadogに取り込まれる全てのログの量
- インデックスされているログは Indexed Logs の対象
コスト影響要因
- Datadogに収集されるログ量（GB単位）
- 全プラン一律で 1GB あたり 0.10ドル / 月 かかる
最適化ヒント
- ログレベルを見直し、INFOやDEBUGレベルの不要なログを取り込まないように設定する
- 必要なログだけをDatadogに転送するよう、フィルタリングルールを作成する
- ログ量のトレンドを定期的に確認し、異常な増加がないかチェックする
Indexed Logs
対象
- Datadogで特定のクエリやダッシュボードで利用するためにインデックス化されたログ
- 1ヶ月で割り当てるインデックス量を決めることができる
コスト影響要因
- インデックス化対象ログ量（GB単位）
- インデックスの保持期間
最適化ヒント
- 必要なログのみをインデックス化し、不要なログを保存しない
- インデックスの保持期間を用途に応じて短縮し、コストを抑える
- ログの割り当て量をモニタリングし、使用量を制御するアラートを設定する
Synthetics
Synthetics はサイトの外形監視をする目的で利用されます。
外形監視テストは APIテストとブラウザテストがあり、このテストの実行回数や頻度によって課金されます。
またテストを実行するロケーション(リージョン)の数にも影響します。
Synthetics API Test Runs
対象
- Datadog Synthetic Monitoringで実行するAPIテストの回数
- APIテストはHTTPリクエストや認証のチェックなどに使用
コスト影響要因
- テストの実行回数 1万回につき課金される
- テストの頻度
- テストするロケーションの数
最適化ヒント
- テストの実行頻度を調整し、必要以上に頻繁にテストを実行しない
- テスト対象のAPIを優先順位付けし、重要でないエンドポイントはテスト対象から外す
- テストロケーションの数を見直し、必要最小限に抑える
Synthetics Browser Test Runs
対象
- Datadog Synthetic Monitoringで実行するブラウザテストの回数
- 実際のブラウザをシミュレートしてテストを実行するため、1回のテスト実行が課金対象
コスト影響要因
- テストの実行回数 1,000回につき課金される
- テスト対象のページ数
最適化ヒント
- テスト実行回数を最適化するため、変更の多いページや重要なページだけを対象とする
- ブラウザテストのシナリオを簡略化し、コストを抑えつつ必要な監視を実施する
- テストのスケジュールを効率的に設定し、不要な頻度で実行しない
おわりに
Datadogの主要な機能のコストについて解説しました。
コストを効率的に管理し、無駄を削減することによって、定期的にチェックをすることで、
より質の高い運用を実現できます。
この記事がお役に立てれば幸いです。
Discussion