■概要
DPAは1つの製品モジュールで様々なデータベース製品、DBaaS環境を一元管理できるデータベース監視製品です。
本手順ではDPAの運用開始後、パフォーマンス問題が発生した際にDPAをどう活用して調査を行っていくかについて、
ご説明します。
■DPAの利用方法
まずはおさらいです。
DPA導入後、パフォーマンス問題が起きていない[通常運用時]とパフォーマンス問題が発生した場合の[パフォーマンス問題発生時]
2つの観点でそれぞれの状況で何をすべきかについて以下まとめています。
[通常運用時]
・DBが正常に稼働しているかどうか
※DPA Tips “DPAを使ったデータベース監視基礎編_通常運用時”で紹介
[パフォーマンス問題発生時]
・パフォーマンス問題発生時、DB視点での問題切り分け
・DBにボトルネックがあった場合の遅延SQL特定
・遅延SQLの遅延原因調査
[パフォーマンス問題発生時]
パフォーマンス問題は、大半のシステムで起きる問題ですが、原因が非常に多岐にわたり、
中々即解消とはならない問題です。
まず、パフォーマンス問題が発生した場合の一般的な対応の流れを以下にまとめました。
パフォーマンス問題の起点は、アプリケーション担当者や利用者からの”急に遅くなった”, “遅い気がする”
といった相談であり、真っ先に遅い原因として疑われるのがデータベースです。
データベース観点では、①OSのリソース調査→②データベース固有の調査→③クエリの詳細分析という流れで
問題となる箇所がないかを調べていきます。
ただ、データベース観点の調査はOSやデータベースの知識が必要であり、調査に時間もかかります。
ですが、これらの問題はDPAを利用することで次の点について誰でも・簡単に・短時間で調査ができるようになります。
・パフォーマンス問題発生時、DB視点での問題切り分け
・データベースにボトルネックがあった場合の遅延SQL特定
DPAではAmomaly Detectionという機械語学習の機能により、パフォーマンス問題発生時のDB視点での問題切り分け、
データベースにボトルネックがあった場合の遅延SQL特定が簡単に行えます。
[Amomaly Detection説明]
- DPAに内包された機械学習アルゴリズムで、収集したデータを分析してインスタンス全体の待機時間の予測・実績値比較を行い、
予測値から乖離していた場合に異常として検出する仕組み - 予測は1日の時間帯毎のSQL実行時間変動と曜日毎のSQL実行時間変動
- DPAで予測したSQL実行時間から乖離があった場合、乖離度合いによって”警告(橙色)”、”異常(赤色)”で色分け表示される
- 時間帯・曜日によって似通った処理が実施されるシステムでは有効に働く
- “警告”、“異常”を検出した時点でメール通知させることも可能
[データベース視点での問題切り分け例①]
- 7/4 11:00頃、アプリケーション処理で処理遅延発生
- 該当インスタンスはAmazon Aurora
- DB側の問題かアプリ側の問題か不明なので、切り分けしたい
Amomaly Detectionで通常と異なるSQLワークロードが検出されていないため、
DBサーバ側で遅延SQLは存在しない。処理遅延はDBサーバ側要因ではない、ということが
簡単に切り分け可能です。
[データベース視点での問題切り分け例②]
- 6/22 14:00頃、アプリケーション処理で処理遅延発生!!
- 該当インスタンスは仮想環境上のSQL Server
- DB側の問題かアプリ側の問題か不明なので、切り分けしたい
Amomaly Detectionで通常と異なるSQLワークロードを検出。原因となる遅延SQLも簡単に特定、が可能です。
Amomaly Detectionにより遅延SQLの特定ができましたので、次のステップはなぜ特定したSQLが遅延したかの調査です。
この調査は監視対象データベース製品におけるパフォーマンス問題切り分けの知識が必要となる部分です。
DPAではパフォーマンス問題切り分けの知識がある前提で、待機イベントやブロッキング、CPU、キャッシュ利用状況など、
調査に必要な情報がSQL文に紐づく形で表示されますので、原因分析の手助けとなります。
また、発生していた待機イベントに対する一般的なアプローチのアドバイス機能も用意されています。
あわせて次のTipsもご参照ください。
DPAを使ったデータベース監視基礎編_通常運用時