【テクニカル・上級編】Datadog Database Monitoring (DBM)で遅いSQLを徹底特定！PostgreSQL/MySQLのクエリ最適化術 – 運用監視・オブザーバビリティ活用バイブル

Datadog Database Monitoring (DBM) を極限まで使い倒す：クエリ最適化の「深淵」を覗く

世の中の多くのエンジニアは、Datadog Database Monitoring (DBM) を単なる「遅いクエリランキング表示機」だと思っている。だが、それはフェラーリで近所のコンビニに買い物に行くようなものだ。

DBMは、DBエンジンの内部状態とアプリケーションの実行コンテキストを橋渡しする「観測可能なメタデータ・エンジン」である。本稿では、SREとDBAが血眼になって探している「ボトルネックの正体」を、DBMの深層から引きずり出すための極限のハックを伝授する。

—

1. DBMの内部構造を理解する：エージェントの負荷を制御せよ

DBMは `pg_stat_statements` や MySQL の `performance_schema` からメトリクスを吸い上げる。だが、高トラフィックなDBでは、`collection_interval` をデフォルトのまま放置してはならない。

メモリ消費とオーバーヘッドの最適化

エージェントがDBから取得するクエリの正規化（Normalization）は、実はDBAの頭痛の種だ。大量のバインド変数が含まれるクエリを正規化する際、エージェント側のCPU/メモリ負荷が跳ね上がる。

ハック： `conf.yaml` で `query_samples` のサンプリングレートを適切に制限しつつ、`explain_plans` を特定の重要クエリにのみ絞り込め。
注意： 全クエリの `EXPLAIN` を取得するのは愚策だ。`EXPLAIN ANALYZE` はDBに対して実実行を伴うため、負荷の高いクエリでこれを乱発すると、それ自体がDoS攻撃になりかねない。

conf.yaml の最適化例
instances:

host: localhost

port: 5432
# サンプリングを間引くことで、スループットが数万QPSのDBでも安全に監視する
query_samples:
enabled: true
sample_rate: 0.1
# EXPLAIN計画の取得は、実行時間が100msを超えるものに限定
explain_plans:
enabled: true
collect_all_plans: false
min_duration: 100

—

2. 「待機イベント」こそが真のボトルネックである

遅いSQLを特定する際、`duration`（実行時間）だけを見るのはアマチュアだ。「なぜ遅いのか」を語るのは常に「待機イベント（Wait Events）」である。

DBMの `wait_event_type` を分析せよ。

`IO:DataFileRead` が多い場合： インデックスの欠如ではない。物理メモリ（Buffer Cache）への載り方が悪いか、IOPSの限界だ。
`Lock:Tuple` が多い場合： N+1問題以前に、アプリケーション側のトランザクション分離レベルか、`SELECT FOR UPDATE` の設計ミスを疑え。

極限のワークフロー：
1. Datadog上の `DBM Wait Time` ビューを開く。
2. クエリの duration ではなく `Lock` 待機時間を軸にソートする。
3. そのクエリが「どのAPサービスから」呼ばれているかを `trace_id` 連携で追跡する。

—

3. APMトレースとDBMの結合：N+1問題の完全撲滅

DBM単体では「遅いクエリ」は見つかるが、「なぜそのクエリが100回連続で投げられているか」はAPMの力が必要だ。

最強の連携：Spanタグの注入
アプリケーションコードから、そのクエリが実行されたコンテキスト（コントローラー名やユーザーID）をDBMにメタデータとして流し込め。

Python/Datadog APM 連携ハック
from ddtrace import tracer

def get_user_data(user_id):
with tracer.trace(“db.query.context”) as span:
# このタグがDBMのクエリ詳細に付与され、
# どのエンドポイントがこのクエリを誘発したかが一撃で分かる
span.set_tag(“db.query.origin”, “user_profile_api”)
return db.execute(“SELECT FROM users WHERE id = %s”, (user_id,))

—

4. 自動化：Datadog API を叩く「自律的改善スクリプト」

手動でダッシュボードを見る時代は終わった。閾値を超えた「悪意あるクエリ」を検知し、GitHub Issuesを起票するスクリプトをCI/CDに組み込むべきだ。

悪意ある低速クエリをDD API経由で抽出し、Slackへ通知する骨子
API Key等の管理は環境変数で行う
DD_API_KEY=”xxx”
DD_APP_KEY=”yyy”

curl -X POST “https://api.datadoghq.com/api/v1/query” \
-H “DD-API-KEY: ${DD_API_KEY}” \
-H “DD-APPLICATION-KEY: ${DD_APP_KEY}” \
-d ‘{
“query”: “avg:postgresql.db.query.time.avg{host:db-prod} by {query_signature} > 500”,
“from”: “now-1h”,
“to”: “now”
}’ | jq ‘.series[0].pointlist’ # ここで得られたシグネチャを元にEXPLAINを自動取得する

—

5. 伝説的アーキテクトからの提言：DBMを使いこなす極意

多くのチームが失敗する最大の要因は、「DBMのグラフを眺めること」自体を目的にしてしまうことだ。

インデックスは魔法ではない： DBMでインデックス不足を指摘されたからといって、無闇にインデックスを貼るな。Write負荷が爆発する。実行計画を見て、`Index Scan` が本当にコスト効率が良いのか（`Index Only Scan` が効くか）を常に評価せよ。
SREと開発の境界線： DBMの「クエリ・シグネチャ」を共有せよ。開発者に対して「このSQLが遅い」と言うのではなく、「このシグネチャ `0xabc123…` の実行計画を見ると、結合順序が逆転している」と伝えよ。

結論：
DBMは、あなたのDBが悲鳴を上げる前に「言葉」を翻訳してくれる通訳だ。その通訳から得た情報を、単なる「チケット」にするのではなく、エンジニアリングの「改善サイクル」に組み込め。

真のオブザーバビリティとは、「問題が起きた時に速く直すこと」ではなく、「問題が起きる前にSQLの深淵を制御下に置くこと」にある。今すぐDBMの深い設定項目を開き、デフォルト値という名の幻想を捨て去れ。