実際の動作までは確認できていないのですが、SQL Database で様々なアップデートが発表されました。
- 長期的なバックアップ保有期間 (Preview) のアップデート
- 読み取りスケールアウトのサポート (Preview)
- 新しい利用モデル (vCore モデル) の追加
それぞれについて、ざっくりとみていきたいと思います。
長期的なバックアップ保有期間のアップデート
いろいろなアップデートが行われていますが、次のような変更が行われているようです。
- すべてのリージョンで、長期的なバックアップ保有期間を利用可能
- バックアップ頻度の調整が可能
- 以前は週次の完全バックアップを長期保存する仕組みだったのですが、週次 / 月次 / 年次のバックアップ頻度を設定できるようになりました。
- 年次バックアップの保存期間も変更可能になっています。
- バックアップを取得する際に、Backup Vault が不要になりました。
バックアップ設定の容易性と、バックアップ取得の利便性の向上により、料金を抑えることができるような仕組みの導入が行われていますね。
詳細については、次のドキュメントを参照してください。
- Store Azure SQL Database backups for up to 10 years
- Configure and restore backups from Azure SQL Database long-term backup retention using Azure SQL storage
読み取りスケールアウトのサポート
高可用性と Microsoft Azure SQL Database に記載されている内容とも関係しているのですが、DTU モデルの Premium と今回追加された vCore モデルの Business Critical では、ローカルストレージを使用した「AlwaysOn 可用性グループ」の構成がとられている環境となります。
AlwaysOn 可用性グループの特徴として「アクティブなセカンダリ: 読み取り可能なセカンダリ レプリカ (Always On 可用性グループ)」があります。
この機能は、同期を行っている待機系のサーバー (セカンダリ) を、待機系としてのみ使用するのではなく、読み取り専用サーバーとして利用することで、読み取りワークロードをスケールさせるということができるものです。
この機能が SQL Database でも利用することができるようになっています。
今までは、アクティブ geo レプリケーションを使用して、非同期の読み取り可能セカンダリを作っていましたが、 AlwaysOn 可用性グループが常に設定されているサービスレベルについては、アクティブ geo レプリケーションを設定することなく、AlwaysOn 可用性グループの待機系のサーバーを読み取りで使用するというものです。
通常運用時で稼働しているサーバーを使用しているので、この機能をサポートしているサービスレベルについては、アクティブ geo レプリケーションと異なり、追加費用なく、読み取りで使用できるサーバーが増えることになります。
(読み取りスケールをサポートしていないサービスレベルでは、読み取り専用サーバーを作るためには、引き続きアクティブ geo レプリケーションが必要となります。)
AlwaysOn の場合は、読み取り専用ルーティング を設定する必要があるのですが、SQL Database の場合はそれは不要で、接続文字列に「ApplicationIntent=ReadOnly」を設定するだけでよさそうですね。
詳細については、次のドキュメントを参照して下さい。
新しい利用モデル (vCore モデル) の追加
今回の発表で一番インパクトが大きいのがこちらでしょうか。
SQL Database は今まで DTU モデルでの提供となっており、CPU のコア数等の割り当ての明示的な効果は行われておらず、負荷状況に応じて DTU サイズを調整するというようなリソース体系をとっていました。
このモデルも引き続き提供されていますが、Azure Database for MySQL / PostgreSQL や、SQL Database Managed Instance と同じ考えの「vCore ベースのモデル」が追加されました。
(Single Database モデル / Elastic Database モデルの両方で vCore モデルが利用可能です。)
Managed Instance と同様に、Azure Hybrid Benefit for SQL Server も適用できるようで、ライセンスを抑えるようなこともできるようになっています。
Managed Instance 同様に、「汎用」と「ビジネスクリティカル」の 2 種類のサービス層が提供されており、vCore 数を調整できるようなモデルとなっています。
SQL Server のライセンスを保有している場合や、明示的なリソース割り当ての指標が必要となる場合は、DTU ではなく vCore モデルの方が適しているケースが出てくるのではないでしょうか。
Azure SQL Database の価格 の価格表もすでに更新されています。
DTU と vCore の移行もできるそうなので、使用状況に応じて後からどちらにするかを変更することもできるようです。
DTU の場合は、シンプルな時間課金のみですが、vCore モデルになると、ストレージ / バックアップ / I/O 要求について別途課金が発生する形になりますので、課金体系についても DTU モデルと比較して考慮点が多くなってきます。
「単純に DB を利用したい」という場合には、DTU モデルの方が扱いやすい気がしますね。
ただし、CPU コア数 / メモリサイズ / I/O 性能については予測ができるようになっており、次のドキュメントから確認することができます。
- vCore-based purchasing model (preview)
- Azure SQL Database vCore-based purchasing model limits (preview)
The new vCore-based service tiers will be available in all Azure regions by April 6, 2018
ということなので、利用するまでにはちょっとだけ待つ必要がありますが、かなり興味深いモデルではありますね。