Azure SQL Database でリソースの使用状況を把握するときに参照しておきたい情報をまとめておきたいと思います。
Contents
リソースの上限についての基本情報
SQL Database は価格レベルによって使用可能なリソースの上限が変わるため、最初は次の情報から確認を行うことになります。
- 仮想コア購入モデルを使用した単一データベースに対するリソース制限
- 仮想コア購入モデルを使用したエラスティック プールに対するリソース制限 (Elastic Pool を使用する場合)
- DTU 購入モデルを使用した単一データベースのリソース制限
- DTU 購入モデルを使用したエラスティック プールのリソース制限 (Elastic Pool を使用する場合)
SQL Database は 仮想コアモデル / DTU モデル の 2 種類のモデルがあり、それぞれで基本動作としてどのようなリソース制限がかかるかについてはこの情報を確認します。
リソース管理の動作については次の情報にも記載されています。
この情報は適宜メンテナンスされており、SQL Database のリソース割り当ての動作を把握するために重要な内容が多く含まれていますので、定期的に見直してみると新しい発見があるかと思います。
Elastic Pool / Hyperscale を使用する場合には、次の情報も合わせて確認をしておきます。
DTU モデルについて
DTU モデルについては DTU ベンチマーク の測定値により使用可能なリソースが決められており、具体的な使用可能なリソースの情報は公開されていません。
また、DTU モデルはフェールオーバーによりデータベースがホストされるハードウェアが変わった場合、リソースの割り当てサイズが変わる可能性があります。
DTU モデルは使用可能なリソースに透明性が無く、現在使用しているリソースサイズが恒久的に割り当てられるというものではないため、「どれだけリソースが使用可能か」を把握するのが難しいのですが、vCore と比較すると低コストで使用することがでます。
vCore モデルがリリースされてかなりの年数が経過した昨今でも、DTU モデルが使用されるケースは多くあります。
基本的なリソース使用状況の確認
基本的なリソース使用状況の確認としては、SQL を実行して確認 / Azure Monitor メトリックから確認する方法の 2 種類があります。
SQL を実行することで確認
基本的なリソース使用状況の確認については、次の情報に記載されています。
一般的には、次のシステムビュー / DMV のデータを参照することになります。
- sys.resource_stats
- sys.elastic_pool_resource_stats (Elastic Pool を使用する場合)
- master データベースで参照可能な論理サーバー内の 各 DB 単位の 5 分間隔の情報
- 14 日間分の情報の保持
- sys.dm_db_resource_stats
- sys.dm_elastic_pool_resource_stats (Elastic Pool を使用する場合)
- ユーザーデータベースで参照可能な接続している DB の 15 秒間隔の情報
- 1 時間分の情報の保持
SQL Database の運用環境では、一般ユーザーは master データベースの接続は許可せず、ユーザーデータベースを直接指定した接続のみを許可することが多いのではないでしょうか。
そのため、実際の環境では、sys.resource_stats は強い権限を持つ管理者でのみ参照可能となっており、一般的な DB 運用担当者では、 sys.dm_db_resource_stats を参照する機会のほうが多いかと思います。
Azure Monitor メトリックから確認
SQL だけでなく、標準で取得されているメトリックから情報を確認することもでき、DB へのアクセス権限だけでなく、Azure リソースへのアクセス権限も保持している場合は、Azure Monitor メトリックから情報を確認することができます。
使用可能なメトリックは次の情報に記載されています。
Azure Monitor メトリック参照時の考慮点
上述の情報はプラットフォームメトリックとして取得されており、リソースを作成すると診断設定を設定しなくても自動的に取得が行われています。
Retention of metrics に記載されていますが、Azure Monitor メトリックは 93 日間保持されており、Azure Portal からは保持されている期間の中で、最大 30 日間分の期間を指定して保持されている情報を参照することができます。(取得されている 93 日間分のデータをすべて表示することは Azure Portal から実施することはできません)
93 日間以上のパフォーマンスデータの保持 / 柔軟な検索を実施したい場合には辛酸設定でメトリックの情報をエクスポートすることを検討しておきます。
詳細なリソース情報の確認
ここまでの情報は基本的な情報を確認するために使用するものとなります。
SQL Database のリソース制限は、次の機能で実現されています。
SQL Database から利用可能なリソース制御の基本はリソースガバナーで実行されています。
基本的な使用可能なリソースの把握
ユーザーデータベースで使用可能なリソースの基本情報については、次の情報で確認することができます。
この情報を確認することでユーザーデータベースがどの程度リソースを使用できるかを把握することができます。
リソースガバナーの設定
sys.dm_user_db_resource_governance はユーザーワークロード寄りの情報となります。
バックグラウンドタスクを含む、システムワークロードの情報も含めて、リソースガバナーによるリソース制御の情報を確認したい場合は次の情報を参照します。
データベースエンジン観点で、バックグラウンドタスクとユーザーワークロードでどのようなリソース制御が行われているかについては、この情報を確認することで把握することができます。
バックグラウンドタスクを含めたリソース使用状況の把握
ユーザーワークロードのリソース使用状況の取得については sys.dm_db_resource_stats から取得できるというのは前述のとおりです。
バックグラウンドタスクを含めて、リソース使用状況を確認したい場合は、次の情報を参照します。
- sys.dm_resource_governor_resource_pools_history_ex
- sys.dm_resource_governor_workload_groups_history_ex
また、Azure Monitor メトリックで「instance」とついているものは、バックグラウンドタスクを含めたものとなっているため、バックグラウンドタスクの詳細な単位での情報にはなりませんが、全体的な情報についてはメトリックからも確認できます。
自動的な情報の取得
詳細な情報の取得については、Azure Monitor メトリックではなく、DMV から情報を取得する必要があり、定期的に DMV から情報を取得 / 保持しておく必要があります。
SQL Database では Database Watcher という機能がありこの機能を使用することで、Azure Data Explorer (ADX) に情報を蓄積していくことができます。
各種 DMV の情報が取得されていますので、Azure Monitor メトリックで取得されている情報より詳細な情報を履歴として取得することができます。
現在は、ユーザーが任意の情報を Database Watcher で取得するということはできないのですが、Roadmap に構成可能なデータコレクションが含まれていますので、今後、ユーザーが任意の情報を Database Watcher で取得することができるかもしれませんね。