Azure SQL のサービスレベルやオプションを整理してみた

はじめに

Azure SQL 、構成要素とか価格モデルとかオプションとか複雑でだいぶ理解が苦しかったので、観点を整理してみました。

SQL Database と計算リソース

ドキュメントを読んでいると「Azure SQL Database」、「SQL Server」、「論理 SQL Server」等、似たような名称が多数登場し、めちゃくちゃ混乱するかと思います。僕はめちゃくちゃ混乱しました。ここに「エラスティックプール」、「Single Database」、「Azure SQL Managed Instance」、「Azure SQL Database サーバレス」あたりが加わってくると、頭の中では「全部同じじゃないですか」「これだからしろうとはダメだ！もっとよく見ろ！」でおなじみのこち亀の画像が浮かんだりしてきます。

これらはサービスの種類、サービスレベル、オプション等にあたる名称ですが、指し示す対象の理解にあたっては計算リソースに注目すると理解しやすかったので、その観点で整理してみようと思います。

データベース、テーブル

先にこちらの用語を整理しておきます。

まず「テーブル」ですが、これは Excel の表のようなものをイメージすると理解しやすいかと思います。行と列の要素を持った、多数のデータの集合を指します。(1件のデータを「レコード」と言うようです)

これらテーブルをまとめたものを「データベース」と言います。多数の xlsx ファイルを収めたディレクトリを思い浮かべると理解しやすいかと思います。

このデータベースが RDBMS がインストールされた「サーバー」に所属します。

実際に DB のデータにアクセスするときは、サーバーへの接続を確立して認証を通過し、サーバー内のデータベースにアクセスし、その中に含まれるテーブルから必要なレコードを取り出す、というような流れになります。

SQL Server

まず SQL Server ですが、これは雑に言うとパッケージソフトで、Windows Server にインストールして使うソフトウエアです。仮に IaaS (VM) をにインストールする場合、計算リソースは VM に紐づき、 SQL Server がそれを使用します。（図では VM と SQL Server を区別していません）

SQL Server 管理下の各データベースは、 VM が持つ 1 つの計算リソースを共有して使用することになります。

論理 SQL Server + Azure SQL Database (single database)

PaaS である SQL Database は RDBMS をインストールした VM を PaaS 化したもの (これに該当するサービスは別にあります) ではなくデータベースの PaaS です。

データベースの PaaS ですのでそれ単体では成立し得ず、ネットワークやら認証やらのあれこれを任せる「サーバー」に相当する部分が必要となるのですが、それが論理 SQL Server と呼ばれるものです。論理 SQL Server それ自体はコンピューティングリソースを持たず、それぞれの SQL Database が所属するまとまりとして機能し、認証やネットワークに関連する制御を提供します。(ちなみに SQL Database から認証等の機能全てが論理 SQL Server に委任されているというわけではなく、別途色々あったりしますが、ここでは触れません)

計算リソースは 1 つ 1 つの SQL Database が独立して保持しています。

たとえ同じ論理 SQL Server に所属する SQL Database であっても、互いの計算リソースは共有されません。この提供形態を特に single database と呼びます。

論理 SQL Server + Azure SQL Database (エラスティックプール)

single database に対し、いくつかの SQL Database で計算リソースを共有する提供形態を「エラスティックプール」と言います。

エラスティックプールが単なるリソース共有の枠組みで、論理 SQL Server からは独立しているとすれば、下図のように複数の論理 SQL Server にまたがるような構成もできそうな気がするけれど、本当にできるかどうかは未検証です。調べてみようと思います。

エラスティックプールは複数のピークが異なるデータベースをひとまとめにして、全体として負荷を平準化して、単体で稼働させるよりリソースの無駄を削ることを目標として使用されます。ドキュメント記載の図が非常に直感的で分かりやすいです。
https://docs.microsoft.com/ja-jp/azure/azure-sql/database/elastic-pool-overview

Azure SQL Managed Instance

「RDBMS をインストールした VM を PaaS 化したもの」とでもいえるサービスが Azure SQL Managed Instance です。雰囲気的には SQL Server on VM から OS 関連部分の責任を Microsoft 側に切り出したものとでも言えそうです。SQL Server on VM ではユーザーが触れた OS 領域が触れなくなっています。（Microsoft が管理しているので触る必要はそもそもありません）

計算リソースは Azure SQL Managed Instance に割り当てられ、内部に好きな数のデータベース (SQL Database ではない) を作って使います。

従って、計算リソースは Azure SQL Managed Instance に紐づいたものを全てのデータベースで共有して使用することになります。

サーバレス

ここまで、計算リソースは暗黙的に決まった規模のものを念頭に置いてきました。しかしクラウド時代においてはリソースは固定のものではなく、負荷に応じて柔軟にスケールが変化するサービスは数多くあります。 SQL Database における「サーバレス」というのは、「論理 SQL Server が無い」という意味ではなく、クラウドにおけるサーバレス、すなわち雑に言うと「サーバーのサイズは考えなくてよい、負荷に必要な分だけ勝手に増減するから使った分だけ利用料を払ってくれれば良い」の方の意味でのサーバレスです。

これに対して従来のように事前にリソース規模を決めて使用時間に応じた利用料を払う場合は「プロビジョニング済み」と言います。

サーバレスはその性質上 single database に適用されます。エラスティックプールというのは全体としては負荷が概ね一定程度のデータベース群のリソースをまとめることでプール全体としての計算リソース要求量を平準化することで無駄を削る仕組みですが、そもそも単一のデータベースだけで負荷に追随できるサーバレスの場合はプールを組み意味がありません。

(https://docs.microsoft.com/ja-jp/azure/azure-sql/database/serverless-tier-overview, 2021/05/26)

ハイパースケールと BC

ハイパースケールと Business Critical (BC) は、それぞれ SQL Database の価格モデルです。

ちなみに、ここまで説明に登場した SQL Database のプロビジョニング済みやらサーバーレスやらは、価格モデルでいうと「仮想コア ベースの購入オプションにおける汎用目的」というところに属します。

仮想コア ベースの購入オプションの段階として、汎用目的、ハイパースケール、 BC があるという位置づけです。それぞれ実現可能な DB 規模やレイテンシ、冗長化の構成などに差があります。DTU モデル (一定程度の性能のまとまりを DTU として、その量で課金が決まる旧来の価格モデル) でいうところの Basic, Standard, Premium の方が直感的な気がしますが、 Hyperscale だけやたらと容量が大きくできたりとか、単純なクエリ実行性能では BC が最も強そうな気配があるというような差別化が行われてるところを見るに、そう単純な分け方はできなさそうです。

計算リソースに注目することで分類を進めていましたが、BC と Hyperscale の区別にあたっては容量とレイテンシが重要なポイントになりそうです。

汎用目的に比べるとより大規模、より高性能な計算リソースの利用が可能になりますが、汎用目的のプロビジョニング済みに相当するオプションのみとなり、計算リソースの規模は事前に決めておく必要があります。エラスティックプールは BC では可能、Hyperscale では不可能なようです。¹ サーバレスとしては両者とも提供されていないようです。²

各価格モデルの比較表は以下参照してください。
https://docs.microsoft.com/ja-jp/azure/azure-sql/database/service-tiers-general-purpose-business-critical#service-tier-comparison

ハイパースケール

最大 100TB までデータを格納できます。汎用目的、 BC 共に最大 4TB までなので、それ以上の規模のデータベースを必要とする場合には選択肢の筆頭となります。

セカンダリレプリカを複数用意することで可用性が高まり、セカンダリレプリカが1つの場合は 99.95% 、2つ以上で 99.99% の SLA となります。読み出しの性能を稼ぐ目的でも使えそうです。

BC

非常に高速なローカルストレージを備え、汎用目的、ハイパースケール、 BC の3つの購入オプションの中で、最も迅速に応答を返すことができます。

マルチ AZ 構成を取ることで 99.995% の可用性となります。

In-memory OLTP というインメモリで処理を行うオプションが使用可能なようです。データの永続化もサポートしているようで、 Redis を使わないという選択肢があり得るかもと思いました。

まとめ

• SQL Server on VM
• 論理 SQL Server + SQL Database
• SQL Managed Instance

この3つが DB + ネットワーク周りの色々 + 計算リソースとなり、それぞれ大体同じ立ち位置になるようです。

さらに SQL Database は以下のように別れています。

• Single Database
  • プロビジョニング済み
    • DTU (仮想コアの方が自由度が高そうな上位互換に見えたのでこちら今回の記事では取り上げていません)
      • Basic
      • Standard
      • Premium
    • 仮想コア
      • 汎用目的
      • Hyperscale (大容量な DB が必要な場合のオプション)
      • Business Critical (高速応答が必要な場合のオプション)
  • サーバレス
    • 仮想コア
      • 汎用目的
• エラスティックプール
  • DTU
    • Basic
    • Standard
    • Premium
  • 仮想コア
    • 汎用目的
    • Business Critical

なるほどちゃんと本腰入れないと理解できなかったのもむべなるかな。

なお、SQL Managed Instance にも提供オプションがいくつかあるようですが、こちらは力尽きたので割愛しています。

ドキュメントを読みつつ整理していたつもりですが、誤り等がありましたらご指摘頂けますと幸いです。

1. https://azure.microsoft.com/ja-jp/pricing/details/azure-sql-database/elastic/ ↩

2. https://docs.microsoft.com/ja-jp/azure/azure-sql/database/serverless-tier-overview#purchasing-model-and-service-tier ↩