はじめに
こんにちは、SREチームの森原(@daichi_morihara)です。
今回はDatadogのログのコスト削減に関して最近行った取り組みを共有していきたいと思います。AWSやGCPなどのクラウドに関してはコスト削減・最適化に積極的に取り組んでいる一方で、Datadogに関してはあまりできていない、、というケースは多いのではないでしょうか？
(Datadogを使用している場合に限りますが。)
弊社でもDatadogのコスト最適化はあまり行えておらず、提供するサービスのスケールに伴ってDatadogのログコストが着々と増加してきたため、コスト削減に取り組むに至りました。
Datadogログコストの構造
Datadogのログコストは主に2つの要素によって構成されます。
ログの取り込み（Log Ingestion)：Datadogに送信されたログの収集・処理・パースするのに発生するコストです。ボリュームベースの料金体系（例：1GBあたり$0.10など）が適用されます。Datadogへのログの送信量を削減することでこのコストを削減することができます。
ログのインデックス化（Log Indexing)： Datadogログにかかるコストの主要因です。インデックス化とは、Log Explorerでの検索・ダッシュボードでの可視化・モニターでのアラート発報などを可能にするため、ログを高速に検索可能な形式で保存するプロセスを指します。コストはログの取り込みに比べて大幅に高く（例：15日間保持で100万ログイベントあたり$2.55など）、インデックス化されるログの量と保持期間の長さに応じて決定されます。保持期間が長ければ長いほど、コストは増加します。
これらの価格はコミットメント契約などによって変動しますが、Datadog Pricing Comparison | Datadogを参照して一例として挙げています。
| 目的 | 課金モデル | 主な最適化手法 | |
|---|---|---|---|
| ログの取り込み | 受信した全ログの収集、パース、処理 | 取り込みGBあたりの従量課金 | ログ転送時のフィルタリング |
| ログのインデックス化 | ログを検索・分析可能にし、保持する | ログイベント数と保持期間に応じた階層型課金 | 除外フィルター、メトリクスへの変換、保持期間の最適化 |
Datadogログのコストに関してまとめた表
Datadogログコスト削減方法
本題のコスト削減方法です。今回は次の２つを行いました。
- ALB(Application Load Balancer)ログをインデックス化の対象外にする
- インデックスログの保持期間を環境毎に設定する
それぞれの実装方法について説明していきます。
1. ALBのログをインデックス化の対象外にする
Datadog上でのALBのログは、リクエスト成功率やレイテンシーといったSLI/SLOの計測のために使用されていました。しかし、その用途以外でDatadogではALBログは使用されていないためインデックス化の対象外にできると判断しました。ALBログがDatadog上でSLI/SLOの文脈以外で使われていないのは、S3に保存されたログをAWS Athenaを用いて分析・調査を行っているという背景があるからです。
ALBログをインデックス対象外にしつつSLI/SLO関連のデータを抽出する方法は次の通りです。
1. Logs Pipelineを使用してログに必要なattributeを設定する。
1.1. Grok Parserでログからattributeを抽出する。
1.2. ステータスコードをもとにCategory Processorでok, notice, warning, errorに分類されたstatus_categoryというattributeを追加する。
1.4. Category ProcessorでURL path normalizationを行い、path_normalizedというattributeを追加する。
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
ALBログの例
{
"http": {
"status_code": 200,
"method": "GET",
"useragent": "curl/7.38.0",
"version": "1.1",
"url": "http://www.example.com:80/"
},
"elb": {
"performance": {
"response_processing_time": 0.057,
"request_processing_time": 0.073,
"backend_processing_time": 1.048
},
"backend_status_code": 200,
"name": "my-loadbalancer"
},
"date_access": 1431560383945,
"network": {
"bytes_written": 29,
"destination": {
"port": 80,
"ip": "10.0.0.1"
},
"client": {
"port": 2817,
"ip": "192.168.131.39"
},
"bytes_read": 0
}
}
1.1のGrok Parserにより抽出したattributeの例
1.2〜1.4の過程でstatus_category, duration, path_normalizedというattributeが追加される
2. Generate Metricsを使用して、1で作成したattributeからリクエスト数やレイテンシーのメトリクスを作成する。
このメトリクスをHTTP Method・ステータスコード・リクエストパス・環境・ALB名といったattributeでグループ分けできるように設定する。
source:elb @http.url_details.path_normalized:* Measure: Duration group by: @http.method, @http.status_code, @http.url_details.path_normalized env, name
Generate Metricsでレイテンシーのメトリクスを作成するクエリの例
3. インデックスでALBログを除外対象に設定する。(除外対象にするにはALBログと判断できるタグがログに付与されていることが前提条件となります。)
これらの設定によりALBのログをインデックス化することなく、以下の写真のように、リクエスト成功率やレイテンシーのSLIを算出することができました！
弊社の場合Datadogに転送されるログのおよそ7割がAWS ALBのアクセスログでした。この膨大なログのインデックス化を止めることができたので、大きなコスト削減を行うことができました。
補足(最大限コスト削減したい場合のアプローチ)
弊社ではS3にあるALBログのDatadogへの転送はDatadog公式のAWS Lambda関数を用いて行なっています。この公式Lambdaの代わりに、以下のどちらかの機能を持ったLambdaを自作するというアプローチもありました。
- ログからメトリクスを作成し、メトリクスのみをDatadogに転送
- フィルタリングをかけて必要な項目のみを含んだログをDatadogに転送
これによりDatadogのログ取り込み量のコストも抑えることができます。しかしログのインデックス化のコストが支配的であること・Lambdaを自作する作業工数を考慮して、今回はLambdaの自作までは行いませんでした。
2. インデックスログの保持期間を環境毎に設定する
次に着手したのは、インデックスログの保持期間の見直しです。
これまでは環境（dev/stg/prodなど）によらず、すべてのログを一律で同じ保持期間のインデックスログとしていました。しかし、本番環境以外のログを本番環境と同じ期間保持する必要性はありません。
よって環境ごとにインデックスを分割し、それぞれに適切な保持期間を設定することでコスト削減を行いました。また前提条件として、環境ごとにインデックスログの保持期間を変更するためには全てのログにenv:prod, env:devといった環境を識別するタグが一貫して付与されている必要があります。
- 本番環境のログ: 原因調査等で過去のログが必要になる場合があるため、保持期間は90日*1
- 本番環境以外のログ: 開発やテストでの利用が主なので、保持期間は30日
最後に
Datadogログのコスト削減の取り組みについて紹介しました。作業自体はとてもシンプルでサクッと終わった一方で、およそ70%のログコストを削減することができました。作業量に対するリターンが非常に高く、取り組んで良かったと満足しています。今後Datadogのログコスト削減に取り組まれる方に参考にしていただけると幸いです。
85%〜90%ほど90日保持のインデックスログを削減できました！
(21日は月次の大量のバッチ処理による影響です)
*1:インデックスログとは別に全環境のログのアーカイブはS3に保存されています。
