Cloud SQL for SQL Server のベータ版を触ってみる at SE の雑記

GCP の Cloud SQL for SQL Server がベータとして利用できるようになったようです。

アルファ版は触る機会がなかったのですが、ベータ版は Public に公開されているようでしたので、この機会に触ってみました。
ドキュメントと価格については英語版であれば公開されているようです。

使用できる SQL Server の機能については Cloud SQL for SQL Server features? に記載されています。
AWS の RDS for SQL Server と同様に、Cloud SQL for SQL Server も「製品版の SQL Server を PaaS として提供」したものとなりますので、使用できる機能についてはざっくりと把握しておくことは重要かと。

Contents

1 使用できるエディション
2 インスタンスの作成
3 コンソールから変更可能な SQL Server の設定
4 SQL Server のバージョン
- 4.1 Minor version support
5 実行環境
6 ユーザーの権限
7 自分で取得したデータベースバックアップの利用
8 可用性環境について

使用できるエディション

Cloud SQL for SQL Server は、現時点では「SQL Server 2017」の次のエディションを使用することができるようになっています。

Express
Web
Standard
Enterprise

基本的な動作環境については、CPU / メモリ / ストレージのサイズによって課金が発生しますが、これに CPU のコア単位で使用するエディションの使用時間が加算されるという課金モデルのようですね。
(SQL Server インスタンスは、ライセンスに対して最低 10 分間課金され、10分後からは 1 分単位で課金されるらしいです)

インスタンスの作成

インスタンス作成の詳細については Creating instances に記載されています。
ファーストステップについては Quickstart for Cloud SQL for SQL Server を確認するとよさそうですね。
インスタンスの作成が完了すると、次のようにインスタンスが作成されます。

今回はパブリック IP アドレス経由での接続で試していますので、パブリック IP に対して「sqlserver」(初期ユーザーの固定名) を使用して、インスタンスの作成時に指定したパスワードで接続を行うことができます。
(パブリック IP の接続については、承認済みネットワークを指定する形になりますので、許可された IP からの接続のみ可能となります)
現時点では、インスタンス作成時に

照合順序
タイムゾーン

は指定できないようですので、照合順序は「SQL_Latin1_General_CP1_CI_AS」、タイムゾーンは「UTC」で固定となるようです。

コンソールから変更可能な SQL Server の設定

PaaS の SQL Server の環境については、SQL Server の管理者権限は基本的に付与されないため、SQL Server のインスタンスで設定変更が可能なものは、「PaaS 側で許可されている設定のみ」が基本的な考え方となります。
Cloud SQL for SQL Server については、コンソールからもいくつかの設定を変更することができるのですが、設定できる項目は、「トレースフラグ」と「sys.configurations」の設定内容の二種類となるようです。

トレースフラグについては、1204 / 1222 / 1224 / 2528 / 3205 / 3226 / 3625 / 4199 / 4616 / 7806 のみが設定可能となっているようです。
sys.configuration の設定も主要なものは入っていそうですが、MAXDOP はインスタンスレベルでは設定できないようになっているようでこちらについては、データベーススコープの構成で設定する必要があるようですので、インスタンスレベルとデータベースレベルの 2 種類の構成を組み合わせていく必要がありそうです。

SQL Server のバージョン

2019/10/27 時点では、SQL Server 2017 CU 16 が動作しているようですね。

Cloud SQL のマイナーバージョンのポリシーについては Database version policies に次のように記載されています。

Minor version support

Cloud SQL performs periodic maintenance to ensure stability and security of database instances. Maintenance includes minor version updates for each database engine. Cloud SQL determines the target minor version for each database engine, and can upgrade the target minor version at any time.
When the target minor version is different from the minor version for a Cloud SQL instance, Cloud SQL will upgrade that version during the next maintenance cycle. You can control the day and time when maintenance restarts occur by setting a maintenance window for your instance.

SQL Server の場合は、CU (累積修正プログラム) がマイナーバージョンとなりますので、CU の適用に関してはメンテナンスウィンドウで定期的に実行される形になるでしょうね。

実行環境

Cloud SQL for SQL Server の実行環境ですが、先ほど書いたように、SQL Server 2017 CU16 が動作しているのですが、それを実行する環境は、SQL Server on Linux のコンテナー版となるようです。

Windows 版ではなく Linux 版 (かつ、コンテナー版) を使用しているのは面白いですね。
SSMS のサーバーのプロパティがこちらです。

CPU のコア数は、インスタンスの作成時に指定したコア数となっています。
メモリについては、「4GB」で指定したのですが、実際の割り当ては少し少なめの割り当てとなっているようですね。
(SQL Server on Linux はデフォルトの設定では割り当てられているメモリの 80% を上限として使用する設定となっていますが、その辺との絡みもあるのかもしれないですね)

ユーザーの権限

PaaS ベースの SQL Server では基本的に「制限されたユーザー権限」が割り当てられた初期ユーザーにより、操作を行っていくことになります。
そのため「SQL Server に対しての管理者権限 (sysadmin)」が付与されることはありません。
(これを許可してしまうと基盤を維持するための操作 / 設定が変更されてしまうことになりますので)
初期で作成される「sqlserver」というログインですが、「CustomerDbRootRole」というデータベースロールに所属しているログインとなっており、ロールによって権限が付与されています。

このロールには次のような権限が付与されています。
(sqlserver には、ALTER の DENY も個別に付与されていますので、以下の画像の権限 + ALTER の DENY が初期ログインの権限となります)

明示的に様々な権限が拒否されていますね。
インスタンスレベルでは限定された操作のみが可能となっています。
作成したデータベースについては、コンソールで作成した場合でも「sqlserver」が所有者となるような制御 (EXECUTE AS LOGIN = ‘sqlserver’ 実行後に CREATE DATABASE を実行する) が行われているようです。

自分で取得したデータベースバックアップの利用

SQL Database Managed Instance や、RDS for SQL Server で使用することができる自分で取得したデータベースバックアップ (.BAK) の利用も可能なようですね。
Cloud SQL の場合は「インポート」「エクスポート」が SQL Server のネイティブバックアップを使用したものとなるようです。
(バックアップはインスタンス全体のバックアップとなるようですね)
Checking the status of import and export operations
GCP の Storage に配置したネイティブバックアップをリストアしたり、Storage にバックアップを取得して、それをダウンロードするという利用ができるようです。
SQL Server から見た場合は次のようなクエリでインポート / エクスポートが実行されているようですね。

		USE [master]
		exec sp_enable_traceflag 3605,0,1
		exec sp_enable_traceflag 3014,0,1
		BACKUP DATABASE [master]
		TO DISK = N'/var/opt/mssql/importexport/e95ae3f5-b406-4ba4-89c2-96c1d08ff163.bak'
		WITH NAME = N'master-Full Database Backup', NOUNLOAD, STATS = 5

「importexport」というディレクトリに対して、バックアップの出力を行うと、それが Storage に出力されているようです。

可用性環境について

Cloud SQL for SQL Server では、同一リージョン内の異なるゾーンに対してフェールオーバーができる高可用性環境を作成することができます。

この実装方式については、Overview of the high availability configuration に記載されている方式となるようですね。
SSMS から確認できるように、Cloud SQL for SQL Server では、クラスター化や、HADR (AlwaysOn 可用性グループ) は無効な状態となっています。

SQL Server の機能ではなく、ディスクを同期させることで、可用性を担保できる構成としているみたいですね。

RDS for SQL Server の場合は、管理用のデータベースがインスタンス内に作成されて、その DB を活用しながら構成の維持管理が行われていますが、Cloud SQL for SQL Server については、管理用のデータベースはインスタンス内には存在していません。
healthcheck_agent / monitor_agent / health_agent という Go のエージェントプログラムが、「CloudDbSqlRoot」というログインで実行されて構成の管理を実施するというようなシンプルな環境となっているみたいですね。

SE の雑記