Azure SQL Database の価格 / リソースの制限の比較 で確認し 料金計算ツール で計算すれば問題はないのですが、Single Database モデルの利用料金の考え方について。
基本的な利用料金については、DTU / vCore / Hyperscale によって考え方が変わる部分と共通的な部分があります。
本投稿の内容が不正確なものだったとしても一切の責任を負うことはできませんので、あらかじめご了承ください。
利用料金の正確な内容については Microsoft の公式の情報が正しいものとなり、本投稿の情報は自分が後から見直すためのメモです。
Contents
DTU モデルの基本利用料
DTU モデルの場合、コンピューティング / SQL ライセンス / ストレージの料金が合算されたものが利用料金となります。
DTU モデルの場合、パフォーマンスレベルによって使用される CPU コア数は固定されておらず、同一のパフォーマンスレベルでも利用可能なコア数が変わってきます。
そのため、コア数に応じてライセンスコストが変わるという考え方はなく、パフォーマンスレベルの価格としてコンピューティングと SQL ライセンスが包括された利用料となっています。
また、ストレージについても個別の利用料は設定されておらず、DTU としての基本利用料に含まれています。
付属ストレージと追加ストレージという考え方あり、パフォーマンスレベルによって既定の付属ストレージが含まれており、それについては、基本利用料で使用することができるのですが、付属ストレージを超え、サポートされる最大ストレージ容量までのサイズについては、追加ストレージとして、付属ストレージを超過した分は追加でコストが発生します。
コンピューティングとストレージのコストが分離していない
- コンピューティングリソースは特定サイズを固定的に割り当てられているものではないため、使用可能コア数が変動する
という特徴があるため、Azure ハイブリッド特典 (AHB) や予約容量というような固定的なリソースによる割引を受けることができません。
しかし、AHB / 予約容量を使用していない vCore / Hyperscale と比較すると、安価に利用することができるケースが多いかと思います。
vCore モデルの基本利用料金
vCore モデルは、DTU モデルとは異なり
- コンピューティング
- SQL ライセンス
- ストレージ
が個別のコストとして計算されます。
vCore モデルについては DTU とことなり、いくつかの構成要素が個別にコストが発生します。
コンピューティング
コア / メモリ等の H/W の基本リソースについてのコストとなります。
コンピューティング部分については「予約 (Reserved)」の適用対象となり、従量課金の他に、1 年 / 3 年の予約容量を使用することができ、長期間の利用が決まっているのであれば、予約容量を使用することで割引を受けることができます。
DTU モデルと比較すると、単純に従量課金を利用するだけだと vCore モデルはコストが高くなるケースが多いのですが、予約容量をうまく活用することで DTU 相当またはそれより低いコストにすることができる可能性があります。
SQL ライセンス
DTU モデルではこの部分は基本利用料金に含まれているのですが、vCore モデルについては、コンピューティングとは別に SQL Server のソフトウェアライセンスが追加で発生します。
SQL ライセンスはコア数に応じて変化しますので、コア数が多くなると SQL ライセンスも増加することになります。SQL ライセンス部分については予約容量の対象となっておらず、AHB でのみ割引を受けることができるようになります。
SQL ライセンスについては、汎用目的 (GP: General Purpose) とビジネスクリティカル (BC: Business Critical) によって、コア単位のライセンスの単価が変わってきます。
インストールタイプの SQL Server と似たような考え方で書くと、
- 汎用目的: SQL Server Standard ライセンス相当
- ビジネスクリティカル: SQL Server Enterprise ライセンス相当
となるかと思います。
次の画像は、2 コアの環境の SQL ライセンスとなり、左が汎用目的、右がビジネスクリティカルの価格となります。
同一のコア数のライセンスですが、サービスレベルによって内容が異なっていますね。
これについては、SQL Server 向け Azure ハイブリッド特典では、具体的にはどのような権限が付与されますか。 を参照しておくとよいのかと思いますが、AHB で SQL Server のライセンスをAzure で使用しようとした場合には、保持しているライセンスによって、SQL Database のコア係数が変わってきます。
Standard Edition のライセンスについては、
- 1 コアライセンス: 汎用目的 1 コア
- 4 コアライセンス: ビジネスクリティカル 1 コア
となっており、Standard Edition のライセンスでビジネスクリティカルを使用する場合には、4 コア分のライセンスが必要となります。
Enterprise Edition のライセンスについては、
- 1 コアライセンス: 汎用目的 4 コア / ビジネスクリティカル 1 コア
となっています。
汎用目的のほうが必要となる SQL Server ライセンスが少なくなっており、SQL ライセンスのコスト差はこれを意識しておくとよいのではないでしょうか。
ストレージ
ストレージについては、データストレージサイズを指定することでログサイズも決まり、使用するストレージサイズに応じた GB のコストとなります。
この部分については、選択したサイズに応じたコストとなりますのでわかりやすいかと。
汎用目的とビジネスクリティカルでは使用するストレージ (リモートストレージ or ローカルストレージ) が異なりますので、GB 辺りの容量単価が異なり、SQL ライセンスと同様にストレージコストは汎用目的のほうが低くなります。
Hyperscale の基本利用料金
Hyperscale の基本的な考え方は vCore と近いものとなります。
レプリカの考え方が vCore と異なるため、この部分では差が出ますが、コンピューティング / SQL ライセンス / ストレージが分割されたコスト体系となっています。
コンピューティング
こちらについての考え方が vCore と同様です。
コア数に応じてコストが変わり、予約についても利用することができます。
- 汎用目的
- Hyperscale
- ビジネスクリティカル
という順でコンピューティングのコストは安くなっており、Hyperscale はビジネスクリティカルと比較するとコンピューティングコストは抑えることができます。
次の画像は、2 コアの場合の 汎用目的 / ビジネスクリティカル / Hyperscale となりますが、ビジネスクリティカルと比較すると Hyperscale はコストがだいぶ抑えられますね。
SQL ライセンス
こちらについても vCore と同様です。
コア数に応じてコストが変わり、AHB を利用することができます。
SQL ライセンスのコア単位のコストですが、汎用目的相当となるようです。
次の画像は汎用目的 / ビジネスクリティカル / Hyperscale となります。
Hyperscale の SQL ライセンスのコア単位のコストは汎用目的相当となっているようです。
AHB を利用する際の Standard Edition のライセンスで考えると、Standard 1 コアライセンスで、Hyperscale も 1 コア分使用することができるため、ビジネスクリティカルよりはコアライセンスが抑えられるというのはここからも確認できますね。
ライセンスコストは次のようになり、Hyperscale はコンピューティングライセンスだけでなく、SQL ライセンスについてもビジネスクリティカルよりコストを抑えることができます。
- 汎用目的 / Hyperscale
- ビジネスクリティカル
ストレージ
ストレージコストはサイズに応じたコストが GB 単位で発生します。
vCore モデルとは異なり、ログストレージのコストはなく、データストレージのコストのみとなっています。
次の画像は汎用目的 / ビジネスクリティカル / Hyperscale の順のストレージコストとなります。
GB 当たりの単価については Hyperscale が一番安価となっていますね。
- Hyperscale
- 汎用目的
- ビジネスクリティカル
の順でコストが安くなっており、Hyperscale はログストレージのコストが無いため、ストレージコストは最も安価となりそうです。
Hyperscale のストレージで注意が必要なのは、投稿時点では DBCC SHRINK に対応していない点です。ファイルサイズを縮小するという方法が提供されていませんので、一度ストレージが拡張されると、データを削除しても、確保したストレージサイズの課金を削減する方法がないということです。
バックアップストレージのコスト
バックアップストレージのコストは DTU / vCore と Hyperscale で大きく異なります。今回のバックアップコストについては短期保有 (PITR) 向けのバックアップを指しています。
DTU / vCore のバックアップストレージのコスト
DTU / vCore のバックアップストレージのコストについては、バックアップ ストレージのコスト に記載されています。
短期保有バックアップについては無償利用分が含まれており、データの更新頻度が極端に多いのではないのであれば、バックアップコストは無償利用分で担保できる可能性があるのが特徴です。
Hyperscale のバックアップストレージのコスト
Hyperscale のバックアップストレージのコストについては バックアップ ストレージのコスト に記載されています。
Hyperscale については、無償分のバックアップストレージは含まれていないため、データの変更量に応じたバックアップコストが発生します。
Hyperscale はビジネスクリティカルより安価なコストとなるリソースが多いですが、バックアップストレージのコストについては vCore モデルより高くなる傾向があります。
バックアップコストが極端に高くなっている場合は、短期保有バックアップの保持期間を短くすることでバックアップコストを調整する必要があるかもしれません。
読み取りレプリカのコスト
SQL Database では読み取りレプリカを作成する方法としては、
- 可用性レプリカ内の読み取りレプリカを利用する
- geo レプリケーションでレプリカを利用する (アクティブ geo レプリケーション)
の 2 種類の方法があります。
今回対象とする読み取りレプリカは「1.」になります。
geo レプリケーションでレプリカを作成する場合については、Azure SQL Database の価格 のアクティブ geo レプリケーションに記載されています。
geo セカンダリでは、それぞれ同じ構成のプライマリ データベースと同じ価格が請求されます。
アクティブ geo レプリケーションの場合は、プライマリの構成と同一の価格が請求されますので、利用形態に応じた固有の考え方はなく、プライマリのコストを倍にすればよいかと思います。
DTU / vCore の読み取りレプリカのコスト
DTU: Premium / vCore: ビジネスクリティカルについては、読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードする に記載されている読み取りレプリカを使用することができます。
Premium および Business Critical サービス レベルでは、余分なコストをかけることなく、この追加の処理能力を使用してパフォーマンス上のメリットをアプリケーションで得ることが可能です。
Premium / ビジネスクリティカルについては可用性レプリカの中の 1 台を非同期の読み取り専用レプリカとして提供する形となり、通常のレプリカ構成の中から読み取りレプリカを使用することができるようになるため、追加のコストを発生させることなく読み取りワークロード用のレプリカを使用することができます。
ただし、読み取りレプリカは 1 台しか提供されないため、複数台の読み取りレプリカが必要となった場合には、アクティブ geo レプリケーションを構成する必要があり、この方法で構築した場合には読み取りワークロード向けの追加コストが発生しｍさう。
Hyperscale の読み取りレプリカのコスト
Hyperscale の読み取りレプリカについては、Hyperscale セカンダリ レプリカ に記載されています。読み取りワークロード用のレプリカは無償で提供はされておらず、
- 高可用性レプリカ
- 名前付きレプリカ
の 2 種類のレプリカがあり、読み取りワークロードをオフロードするためにはいずれかのレプリカを追加コストを発生させて使用する必要があります。
Hyperscale については、どちらのレプリカを使用してもコストの基本的な考え方は変わりません。
前述のとおり、基本料金としてはコンピューティングと SQL ライセンスがありますが、レプリカ側でコストとして発生するのはコンピューティングとなり、SQL ライセンスは発生せずに利用することができます。
コンピューティングコストについては、レプリカ側も予約容量の対象となりますので、予約の仕組みを活用することでコストを抑えることができます。
Azure SQL Database の Single Database モデルの基本的な利用料金については上記の内容を考慮する必要があるのではないでしょうか。
サービスレベルを変えることでコストも大きく変化してきますがどのような内容がコストの発生対象になっているかを把握しておくことで、どの部分のコストが抑えられた効果が出ているのかを理化することができます。
改めて調べてみると、Hyperscale は最速の環境ではありませんが、汎用目的よりは高速な環境となるため、コスト / 性能のバランスが良い利用形態となるのかもしれませんね。