先日発表された、SQL Database の vCore モデルと従来型の DTU モデルの比較を。
内容としては次の情報の内容をベースとしています。
- アナウンス
- 料金
- ドキュメント
Contents
DTU モデルの特徴
DTU モデルは、サービス階層とパフォーマンスレベルに応じて、
- リソース
- CPU 利用可能上限
- CPU コア数
- 最大メモリサイズ
- データベースリソース
- 最大データベースサイズ
- I/O スループット
- I/O レイテンシー
- 接続関連リソース
- 最大ワーカー数
- 最大ログイン数
- 最大セッション数
が事前に構成された環境として提供されています。
接続関連リソース / データベースリソース以外のリソース割り当てについては、内部的に管理 / 構成されているものとなており、どの程度のリソースが使用できるように設定されているかは利用者には公開されていません。
コンピューティング / ストレージ / I/O のリソース割当が束ねられた DTU という性能の測定尺度で性能が公開されています。
DMV の利用になれているユーザーであれば、ある程度の情報は DMV 経由で把握することができるようになってはいるのですが、ハードウェアの世代の進化に伴う実行環境の変更に伴うリソース割り当ての最適化についても自動的に実施されているようで、リソースの割り当て状況も、日々調整されているように見受けられます。
Azure SQL Database DTU Calculator を使用することで、SQL Server のパフォーマンス情報を元に、対応する DTU の予測もできるようも可能です。
しかし、算出された DTU 値で初期構築を実施し、その DTU サイズでずっと使い続けるというよりは、リソースの使用状況に応じて「データベース作成後にサービス階層 / パフォーマンスレベル」の柔軟に変更する運用を検討するということの方が適しています。
利用する際の費用についても、使用するパフォーマンスレベルに応じたものとなっているため、料金の考え方もシンプルです。
「データベースを使いたい」というニーズに対して、事前にリソースオプションが設定され、利用者がシンプルに使いやすい環境を提供されているモデルなります。
Azure SQL Database DTU-based resource model limits
vCore モデルの特徴
vCore モデルについては、リソースの割り当ては明確なものとなっており、次のような情報は明確に公開されています。
- コンピューティング世代
- vCore数
- データベースリソース
- データベースサイズ
- データファイル
- データベースのデータファイルで使用するディスクサイズは明示的に指定
- 汎用サービス階層 : 最大 1 TB ~ 4 TB
- ビジネスクリティカル階層 : 最大 1 TB
- ログファイル
- トランザクションログの最大サイズは追加したディスクサイズの 30% が自動的に設定される
- 汎用サービス階層 : 最大 307 GB ~ 1.2 TB
- ビジネスクリティカル階層 : 最大 307 GB
- データファイル
- tempdb の配置
- 汎用サービス階層 : Premium Storage の SSD を使用
- ビジネスクリティカル階層 : インスタンスに直接接続された SSD を使用
- サイズは 32GB / vCore
- I/O スループット
- 汎用サービス階層 : 500 IOPS / vCore (最大 7,500 IOPS)
- ビジネスクリティカル階層 : 5,000 IOPS / vCore (最大 80,000 IOPS)
- I/O レイテンシー
- 汎用サービス階層 : 書き込み 5 ~ 7 ms / 読み取り 5 ~ 10 ms
- ビジネスクリティカル階層 : 書き込み 1 ~ 2 ms / 読み取り 1 ~ 2 ms
- データベースサイズ
- メモリサイズ
- 7GB / vCore
- 接続関連リソース
- 最大ワーカー数
- 最大ログイン数
- 最大セッション数
- 料金
- Azure Hybrid Benefit を適用可能
DTU モデルと比較して、リソースについて、様々な情報が公開されていますね。
DTU モデルと vCore モデルについては、相互に変更可能ですので、モデルの移動は柔軟に実施することが可能となっています。
ALTER DATABASE (Azure SQL Database) も拡張されており、SQL からサイズを変更することも可能です。
DTU モデルと vCore モデルのリソースを比較してみたものがこちらになります。
※vCore モデルのバックアップ保持期間は、Preview 中が 7 日となっており、最終的には 35 日になるようです。
Single Database モデルでの比較ですが、vCore モデルの方がすべてのリソースが上かというとそうでもなく、in-Memory OLTP のサポートサイズ / 接続関係 / バックアップ保持期間については、DTU モデルの方が上のものもありますね。
DTU の場合、Standard S3 / Premium P1 で 1 コアが割り当てられているため、これ以上のモデルを使用している場合で vCore に変換する場合は、CPU コア数を意識しておく必要があります。
料金については次のようになっています。
vCore / Managed Instance については、ストレージの料金が別にかかりますので、実際には以下の料金より高くなります。
300 DTU (S4~ S6 / P2 ~ P4 の間) の場合、vCore モデルにすると、価格的なメリットが出てくる可能性があるというような記載があるとおり、S4 ~ S6 を汎用サービス階層 / P2 ~ P4 をビジネスクリティカル階層に変えてみると、コストが抑えられる可能性があるかもですね。