Azure SQL Database Serverlessってなんぞ?
様々なタイプのSQL Databaseが存在してきていますが、今回Azure SQL Database ServerlessについてPickupしてみたいと思います。
個人的にもいろんなタイプがあって、よくわからなくなってきたのでこのタイミングで整理したいと思って書きました。(笑)
公式ドキュメントは以下。
ここで振り返りますが、現時点(2019/10/26)で以下のタイプのSQL Databaseがあります。ここ2年でだいぶ進化してきましたね。No.4のインスタンスプールについてはまだ知見がないため概要は記載してないです・・・あと間違っていたら指摘ください。
# | 種類 | 概要 |
---|---|---|
1 | Single Database | SQL Serverで管理される単一DB(一般的なRDB) |
2 | Elastic Pool | DTUを共有できるタイプのDB |
3 | Managed Instance | VNet内にデプロイ可能なプライベートなDB |
4 | Managed Instance Pool | ??? |
5 | Serverless | 今回記載するDB!!! |
表でまとめましたが、ではこれまでのSQL Databaseと比べどのような部分が利点なのか整理していきましょう。個人的にはざっと以下の3点かなと思ってます。
- 設定したスペック内で自動でスケーリング
- 費用は実際に利用したCPUおよびメモリ
- ユーザセッションが無い場合は自動停止
設定したスペック内で自動でスケーリング
最大の特徴になるのが自動でスケーリングしてくれる点だと思ってます。
最小仮想Coreと最大仮想Coreを設定し、その間で自動でスケーリングしてくれます。
最小仮想Coreで設定したCore数に関しては必ず確保されます。そして利用形態に応じて内部で最大仮想Core数までスケーリングされます。
ただし1点注意があります・・・
記載している通り必ず内部的にプロビジョニングされているのは、最小仮想Coreで設定した分です。仮に利用が増えスケーリングする際は、最大仮想Core数までリソースを確保しようとします。これがうまく行けば良いですが、仮にプロビジョニングされているサーバの近くでリソースが確保できない場合、、、スケーリングまでに待ちが発生するか、再配置等が実施されるのでは無いかと思っております。
この点を考えると、Serverless以外のタイプであれば事前に指定したスペックでプロビジョニングされているので問題にはならないですね!
この点はServerlessタイプを利用するかどうかの判断ポイントになるのでは無いでしょうか。
費用は実際に利用したCPUおよびメモリ
これまでのSQL DatabaseはDTUベースなら事前にDTUを設定、vCoreベースに関しても事前に設定したvCoreで課金が行われます。
そのため実際に消費しているリソースと設定したスペックに差があればあるだけ、もったいない現象になっておりました!まあクラウドなんで、定期的に見直しできるんですけどね!
それを解決してくれたのが、Serverless!!!
起動している時は実際に利用したCPU、メモリあとはストレージの費用がかかってきます。後述しますが、停止も可能なためその際はストレージのみの費用になります。
非常に効率的にSQL Databaseを利用できるようになりますね!
ユーザセッションが無い場合は自動停止
ユーザセッションが 0であり、ユーザのワークロードで利用しているCPUが0の場合自動停止の設定が可能です。
条件に当てはまってから自動停止になるまでの時間も設定可能です。
またもちろん自動停止機能自体もOffにすることも可能です。
開発環境等で利用する場合、夜なんかは利用者がいないため自動停止機能をONにしておけば利用料が抑えられますね。
再開の条件ですが、いくつかありますがログイン操作等のリクエストがあった際に再開されます。最初のリクエストはおそらくエラーでアクセスできませんが、その数分後からアクセス可能になるかと思います。
自動停止になる条件や、再開の条件については公式サイトを確認してみてください。
つらつらと長く書いてしまいましたが、ユースケースによっては非常に利用するのがありだなと思えるサービスだと思います。上記の通りとりあえず開発環境のSQL Databaseに関してはSingleやElastic PoolタイプではなくServerlessにすぐ変えるべきかなと思いました。