はじめに
こんにちは、@snowqueen_tgです。
データベースのサーバー監視というと、まず思い浮かぶのは「サーバーが落ちていないか」の確認ではないでしょうか。
ただ、サーバーが稼働中＝正常、とは限りません。
- クエリの実行に時間がかかっている
- CPUやメモリに負荷が集中している
- ロックによって処理が待たされている
- 接続数が上限に近づいている
サーバー自体は動いていても、こういった問題が裏で進行しているケースは珍しくありません。
そこで今回は、データベースのサーバー監視で押さえておきたい主要なメトリクスを整理してみました。
📊 監視で見るべき3つの領域
データベースの状態は、単一の数値だけでは判断できません。複数のメトリクスを組み合わせて、初めて全体像が見えてきます。
大きく分けると、3領域がポイントです 👇
1️⃣ クエリパフォーマンス
まず確認したいのが、実行時間の長いクエリです。
ただし、「遅い」という事実だけで原因は分かりません。
- 待機時間
- CPU使用量
- データの読み取り・書き込み回数
- 実行回数
例えば、Disk I/Oの待機が長ければインデックス、CPU使用量が高ければクエリの処理内容に問題ある可能性があります。
実行時間とほかのメトリクスを組み合わせることで、見直すべきポイントを絞り込めます。
2️⃣ CPU・メモリ・Disk I/O
次に、データベースサーバーのリソース使用状況を確認。
CPU使用率
CPU使用率の一時的な上昇は、必ずしも問題ではありません。注意したいのは、高い状態が続いている場合です。
主な原因として、次のようなものが考えられます。
- インデックス不足による大量データの走査
- 非効率なクエリの繰り返し
- 同時実行される処理の増加
- サーバースペックの不足
すぐにサーバーを増強するのではなく、負荷が高くなった時間帯のクエリも確認しましょう。
メモリとキャッシュ
データベースは、よく使うデータをメモリに保持し、ディスクへのアクセスを減らしています。
その利用状況を確認する指標の一つが、バッファキャッシュヒット率（Buffer Cache Hit Ratio）です。
ヒット率が低下するとディスクからの読み取りが増え、クエリが遅くなる可能性があります。ただし、適切な値は環境によって異なるため、通常時の値や過去の推移と比較して判断します。
Disk I/O・Network I/O
Disk I/Oでは、以下の項目を確認します。
- 読み取り・書き込み回数
- I/Oの待機時間
- ディスクの応答時間
- 使用容量
Disk I/Oとクエリ実行時間が同時に増えている場合は、ストレージがボトルネックになっている可能性があります。
また、大量のデータをやり取りしている環境では、Network I/Oも確認が必要です。
3️⃣ 接続数・セッション・ロック
CPUやメモリに余裕があっても、接続やロックによって処理が遅くなることがあります。
接続数
接続数が上限に達すると、新しい接続を確立できず、エラーや応答遅延につながります。
特にコネクションプールを利用している場合は、次の項目を確認します。
- 使用中・待機中の接続数
- 接続上限
- 接続が解放されるまでの時間
接続数の推移を記録しておけば、将来的に必要なリソースも予測しやすくなります。
ロック
ロックはデータの整合性を守るために必要ですが、長時間解放されないと、ほかのクエリが待たされます。
確認したいのは 👇
- ロックを保持しているセッション
- ロックの解放を待っているセッション
- 長時間継続しているトランザクション
- 待機時間
CPU使用率が低いのに処理が進まない場合は、ロックやセッションの待機を確認してみましょう。
🔗 メトリクスは単体ではなく、関連性で見る
データベース監視では、メトリクスを一つずつ眺めるのではなく、同じ時間帯に何が連動して変化したかを見ることが重要です。
「クエリが遅い」という結果だけを見ても、根本原因までは分かりません。
複数のメトリクスを時系列で突き合わせることで、問題の発生箇所を絞り込みやすくなります。
また、適切な基準値は環境によって異なります。平常時の値を把握し、過去の傾向と比較することも大切です。
🛠 Navicat Monitorでまとめて確認する
複数のデータベースサーバーを個別に確認するのは、台数が増えるほど負担になります。
Navicat Monitorは、MySQL、MariaDB、PostgreSQL、SQL Serverに対応したエージェントレス型のリモートサーバー監視ツールで、対象サーバーに専用エージェントをインストールせずにデータベースやOSのメトリクスを収集できます。
- 長時間実行されているクエリ（実行時間・待機タイプ・読み書き回数）
- CPUおよびメモリ使用量
- ディスク使用量、Network I/O
- 接続数とセッション、テーブルロック
履歴を保存できるため、「いつからパフォーマンスが低下したのか」を後から追跡できるのも実務上ありがたいポイントです。
カスタムメトリック
Navicat Monitorでは、標準メトリクスに加えて、SQLクエリを使ったカスタムメトリックも作成できます。
たとえば特定テーブルの業務上の数値を定期的に取得し、しきい値を超えたら通知する、といった使い方が可能です。
アラート
しきい値に加えて「その状態が何分間続いたら通知するか」も設定できます。一時的な変動による不要な通知を抑えられます。
通知方法は、メール、SMS、SNMP、Slackに対応しており、チームの運用に合わせて選択できます。
📝 まとめ
データベース監視は、単に「稼働しているか」を確認するだけでは不十分です。
- クエリの実行時間・待機時間・リソース使用状況をあわせて確認する
- 接続数やロックによる待機も監視対象に含める
- メトリクス同士の関連性や過去の推移を見る
- 適切なしきい値と継続時間を設定し、問題が起きる前に検知する
サーバーが停止してから対応するのではなく、普段と異なる兆候を早めに捉えられるかどうかが、安定したデータベース運用の分かれ目になります。
今回は監視の全体像を整理しました。今後は、スロークエリやロックなど、個別の監視項目についても詳しく調べてみたいと思います。
✨ちなみに、「Navicat」は、MySQL・MariaDB・PostgreSQL・SQL Serverなど主要なデータベースに対応しています。
今回紹介した監視の考え方を実際に手を動かして試したい方は、ぜひNavicat Monitorもチェックしてみてください！
製品のご購入をご希望の法人のお客様は、こちらをご利用ください。
TenGenesis株式会社日本総代理店：https://japan-navicat.com/
Navicat Monitor：https://jp.navicat.com/products/navicat-monitor
Navicat公式サイト：https://jp.navicat.com/
Linkedin：https://www.linkedin.com/company/navicat-japan/
X：https://x.com/navicat_jp