Azure SQL DatabaseのDTUモデルとvCoreモデルのマッピングクエリで比較してみた

いわさです。

Azure SQL Databaseには複数の購入モデルがあります。

私はこれまでDTUベースしか使ったことが無かったのですが、CPUやメモリなどどの程度のリソースなのかよくわかってないまま、ワークロードを評価してメトリクスからDTUの過不足を判断し調整することが多かったです。
今はvCoreベースが推奨されており、DTUベースからvCoreベースに移行するにあたってコア数やメモリ数のマッピング用T-SQLが公開されており、移行のための見積もりに利用することが出来ます。

vCoreベースと他クラウドの比較ができていれば、DTUからvCoreへのマッピング情報はAzureからAWSやGCPなどへの移行時も参考になるのではないかなと思い、全価格レベルで確認してみました。

DTUベースの購入モデルとvCoreベースの購入モデル

https://docs.microsoft.com/en-us/azure/azure-sql/database/purchasing-models より

DTUベースはリソース構成の細かいカスタマイズは出来ず、DTUを調整してパフォーマンスをコントロールします。
vCoreベースは個別にリソース調整が可能です。

私はDTUシンプルで好きでした。
シンプルですが、少し無駄なリソースが発生することが多いイメージでしょうか。

Gen4とGen5

Azure SQL Database は Gen4(Haswell)とGen5(Broadwell, Skylake)が混在しています。
vCoreモデルの新規構築時はGen4は現在は選択することは出来ません。

今回の検証で知ったのですが、DTUモデルについてはまだGen4が使われることがあるようです。
同じ価格レベル、同じリージョンでもスケールアップ、スケールダウンしたタイミングでランダムでGen4かGen5のハードが割り当てられる感じでしょうか。
米国西部2リージョンだとGen4は一度も引きませんでしたが、東日本リージョンでは2割程度の確率でGen4を引いてました。

評価方法

以下のURLで公開されているT-SQLをDTUデータベース上で実行し評価していきたいと思います。
東日本と米国西部リージョンで評価しました。

WITH dtu_vcore_map AS
(
SELECT rg.slo_name,
       DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS dtu_service_tier,
       CASE WHEN rg.slo_name LIKE '%SQLG4%' THEN 'Gen4'
            WHEN rg.slo_name LIKE '%SQLGZ%' THEN 'Gen4'
            WHEN rg.slo_name LIKE '%SQLG5%' THEN 'Gen5'
            WHEN rg.slo_name LIKE '%SQLG6%' THEN 'Gen5'
            WHEN rg.slo_name LIKE '%SQLG7%' THEN 'Gen5'
       END AS dtu_hardware_gen,
       s.scheduler_count * CAST(rg.instance_cap_cpu/100. AS decimal(3,2)) AS dtu_logical_cpus,
       CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS decimal(4,2)) AS dtu_memory_per_core_gb
FROM sys.dm_user_db_resource_governance AS rg
CROSS JOIN (SELECT COUNT(1) AS scheduler_count FROM sys.dm_os_schedulers WHERE status = 'VISIBLE ONLINE') AS s
CROSS JOIN sys.dm_os_job_object AS jo
WHERE dtu_limit > 0
      AND
      DB_NAME() <> 'master'
      AND
      rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
       dtu_hardware_gen,
       dtu_memory_per_core_gb,
       dtu_service_tier,
       CASE WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
            WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
            WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
       END AS vcore_service_tier,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.7
       END AS Gen4_vcores,
       7 AS Gen4_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus
       END AS Gen5_vcores,
       5.05 AS Gen5_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.8
       END AS Fsv2_vcores,
       1.89 AS Fsv2_memory_per_core_gb,
       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.9
       END AS M_vcores,
       29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;

クエリは単純で、dm_user_db_resource_governanceから実際の構成と容量情報を取得・計算し、係数で世代間を調整しています。
概算見積もりくらいに考えておいたほうが良いかもしれませんが、指標にはなると思います。

sys.dm_user_db_resource_governance については以下を参考にしてください。

評価結果

Gen4, Gen5

Fsv2シリーズ、Mシリーズ

• Fsv2シリーズ：Intel® 8168 (Skylake) プロセッサ
• Mシリーズ：Intel® E7-8890 v3 2.5 GHz プロセッサおよび Intel® 8280M 2.7 GHz (Cascade Lake) プロセッサ

所感

繰り返しますが、この数値はあくまで指標で、ワークロード毎の評価は必要です。
ただ、全くマシンリソースが意識出来ていなかった状態からすると、これだけ情報を得れるだけでも役立ちそうです。

私はAzure SQL Database では小規模のワークロードを設計することが多く、S0~S3くらいで足りていました。
データベース外でキャッシュを活用していたとしても、この程度のリソースだったのかと少し驚きました。

どういう規模・特性のワークロードがどの程度のDTUが必要か、ざっくり見積もれる人は多いと思いますので、これを参考にvCoreベースでの見積もりに活かせれると便利だなと感じました。