SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Azure SQL Database serverless (プレビュー) を触ってみました

leave a comment

Build 2019 で発表された Azure SQL Database serverless を少し触ってみました。
ドキュメントはこちらから。

基本的な考え方としては AWS の Aurora サーバーレス に通じるものがあるのかと。
(Azure SQL Database serverless は、現時点では最大 4 コアのモデルまでの小さなサイズでの提供となっていますので、スケール面での考え方は異なりますが)

■Azure SQL Database serverless とは?

Serverless とついていますが、サーバーがないわけではありません。
Azure SQL Database serverless は「プロビジョニングされたコンピュートリソースを持たない」Azure SQL Database の新しい利用方法となります。
従来からのシングルデータベースモデル
従来からの「シングルデータベースモデル」は、DTU / vCore モデルの 2 種類があります。
今回リリースされた Serverless は、vCoreモデルとなりますので、比較対象はこちらです。
vCore モデルは、設定しているパフォーマンスレベルに応じたリソース (CPU / メモリ) が事前に割り当てられたものとなります。
つまり「事前にリソースがプロビジョニングされているコンピュートリソース」で動作していることになります。
次の画像は、General Purpose service tier: Storage sizes and compute sizes の内容です。
Serverless は vCore モデルの汎用目的 Gen5 で動作しますので比較対象はこのモデルとなります。
image
使用しているコンピューティングサイズに応じて、CPU とメモリのリソースが固定的に確保されています。
ポータルのシングルデータベースの設定が次の画面になります。
image
従来からのシングルデータベースについては「プロビジョニング済み」として表示されており、「設定したリソースが固定的に確保された状態」で動作します。
指定したコンピューティングリソースが確保されていることが保証され、常に一定の CPU / メモリの割り当てが行われた状態で稼働しますので安定した性能が出せるのが従来からのモデルです。
 
Serverless
SQL Database Serverless については、ディスクの性能については事前に割り当てられた性能内になりますが、CPU / メモリについては、最小と最大の範囲の中で「可変的なリソース」としての利用となります。
次の画像は、Serverless compute tier resource limits の内容となります。
image
ポータルの Serverless の設定が次の画像になります。
image
CPU としては「最小 vCore 数」と「最大 vCore 数を」設定し、vCore 数に応じてメモリサイズが決まります。
つまり「可変的なリソース」での利用となります。
「最小 vCore」に指定したコア数 / メモリが常に使用することができ、急に負荷が上昇した際にも「最大 vCore」に指定した範囲までであれば、自動的にスケールされます。
(最大のリソース要求を満たすのに十分なサイズを持つ環境上で実行されますが、数分以内にリソース要求を満たすことができない場合は、自動的にロードバランシングされ、要求を満たすことができる環境に、リコンフィギュレーションされる可能性があるそうです)
 

■Serverless のリソースの特徴

Serverless にはいくつかの特徴があり、利用シナリオに応じた特徴については Scenarios に記載されています。
セミナーで紹介するために作ったスライドがこちらになります。
image
 
Serverless の最大の特徴は、次のようなものではないでしょうか。

  • 可変的なリソースの利用
  • コンピューティングリソースは秒単位での課金
  • 一定時間アイドル時間が続くと一時停止状態となる

 
可変的なリソースの利用
前述のとおり、Serverless では、最小と最大の vCore 数を設定し、設定したコア数に応じて利用可能なメモリも 2.1 ~ 12GB の間で、自動的にスケーリングされます。
従来型のシングルデータベースでは、設定しているリソースの固定的な確保となります。
データベースの負荷状況によっては、次のようなことが発生する可能性が考えられます。

  • 設定しているリソースがオーバースペックになっている
  • 設定しているリソースでは不足している

リソースの調整は、利用者が行う必要があるため、負荷が低い時にはスペックを落とし、負荷が上がってきたときにはスペックを上げるということを手動または、利用者が独自に構築した仕組みにより自動的に行われるようにする必要があります。
Serverless の場合は、負荷状況に応じて、最小~最大の範囲で自動的にスケーリングしますので、最大 vCore までの範囲であれば、サーバーの負荷に応じて自動的にスケールダウン / スケールアップが行われます。
最大 vCore の範囲までであれば、アクセスのスパイクにも耐えられるかと。
(現時点では 4 vCore が最大サイズとなっていますので、自動的なスケールの優位性が出るのは、「汎用目的 Gen5 4 vCore モデルまで」になる可能性がありますが)
要求されたリソースの確保に時間がかかる場合は、他の環境にバランシングされる可能性があるということですので、接続のリトライについては考慮しておく必要があるかと思いますが。
 
コンピューティングリソースは秒単位での課金
従来型のシングルデータベースは「時間課金」でデータベースが存在している時間に応じて、固定的に一定のコストがかかります。
(1 時間に満たない利用の場合は繰り上げられて課金されていたかと)
これは、サーバーの負荷が低く CPU が使用されていない状態 / サーバーの負荷が高く CPU が頻繁に使用されている状態のどちらだったとしても、コンピューティングリソースについては、固定的な請求が発生するということになります。
 
Serverless については「CPU とメモリの最大使用量に応じた秒課金」となります。
(メモリについては、メモリの使用量を vCore に換算し (3GB = 1vCore) 、CPU の使用率が低くてもメモリの使用状況が高い場合には、それに応じた vCore での課金となるようです)
サーバーの負荷が低い状態出ればコストが抑えられることになります。
サーバーの負荷が高い状態となった場合は最大 vCore までスケーリングし、その分のコストが発生しますが、負荷が落ち着けば、コストが自動的下がりますので、高負荷になるタイミングに波がある場合には、Serverless の方が安価に運用できる可能性があります。
負荷が高い状態となり CPU 使用状況が変化した場合も、高い状態の課金は秒単位での課金となります。
1 時間の中で 10 分だけ最大 vCore まで使用した場合、10 分間だけ最大 vCore での課金となり、それ以外の時間帯については、落ち着いた使用状況の vCore での課金となり、1 時間の範囲の中でも細やかなコストでの運用を行うことができます。
 
一定時間アイドルが続くと一時停止状態となる
汎用目的の構成ですが、ストレージとしては、「Azure Premium ストレージをリモートストレージとして利用」する構成となっています。
これについては、General Purpose サービス レベル – Azure SQL Database で解説されています。
汎用目的については次のような構成となっています。

コンピューティングレイヤーとストレージレイヤーが分離されている環境となっています。
(ビジネスクリティカルの場合は、高速なサーバーのローカルストレージが使用されています)
ローカルストレージを使用していませんので、「コンピューティングリソースを停止してもストレージ上のデータはリモートに残っている状態」となります。
SQL Data Warehouse に近い考え方ですね。
この構成になっていることも大きな理由だと思いますが、Serverless では「一定時間非アクティブ (ユーザーからのアクセスがない) な場合は、コンピューティングリソースを一時停止する」という動作を有効化することができます。
(一時停止をしないという設定もできます)
image
現時点では最小の間隔が 6 時間となっており長めです。
(Aurora サーバーレスの場合は、5 分の非アクティブ時間で一時停止相当のようです。SQL Database Serveless の 6 時間は長いと思いますので、最終的には Aurora サーバーレスのような短い時間で停止できるようにしてもらいたいですね。)
一時停止されると、ポータルには次のような表示が行われます。
image
一時停止になったかについては「sys.dm_operation_status」からも確認できます。
image
一時停止中は、コンピューティングリソースの課金も停止し、この期間中はコストとしてはストレージコストのみ発生する形となります。
一時停止後に、Autopause and autoresume の自動再開のアクションが行われた場合、コンピューティングリソースが再開されるようになります。
次の画像は、コンピューティングリソースの課金の状況を表したものになるのですが、6 時間のアイドル状態が続いた後は一時停止し、請求も止まっていることが確認できますね。
image
一時停止後の初回アクセス時に、コンピューティングリソースが起動するため、最初のアクセスについてはアクティブになるまで時間がかかります。
これについては、ConnectivityLatency に記載されています。

Connectivity

If a serverless databases is paused, then the first login will resume the database and return an error stating that the database is unavailable. Once the database is resumed, the login must be retried to establish connectivity. Database clients with connection retry logic should not need to be modified.

Latency

The latency to autopause or autoresume a serverless database is generally on the order of 1 minute.

自動停止からの再開は約 1 分程度かかる可能性がありますので、初期のウォームアップについては多少の時間がかかります。
こちらについても接続の再試行により、一時停止後の初回アクセスには備える必要があります。
再開した以降はコンピューティングリソースは稼働した状態ですので、接続の遅延はないかと。
一時停止したタイミングで、メモリ上のキャッシュもクリアされますので、再開後はキャッシュがゼロの状態での利用となります。
 
ざっくりとですが、serverless を触って、確認した情報をまとめてみました。
最大の vCore 数が少ないのと、6 時間の非アクティブ時間で一時停止というのは期間が長すぎるのではと思っていますが、この辺は GA までに調整されると嬉しいですね。

Share

Written by Masayuki.Ozawa

5月 11th, 2019 at 11:47 pm

Leave a Reply