Azure SQL Databaseのデプロイオプション概略 ～ 単一データベース / エラスティックプール / マネージドインスタンス

はじめに

Microsoft AzureのPaaS型データベースであるAzure SQL Databaseの概要を押さえるための記事です。

本記事では、Azure SQL Databaseでサポートされている以下の3種類のデプロイオプションの特徴や、どのように使い分けるかについて、まとめたいと思います。

• 単一データベース (Single database)
• エラスティックプール (Elastic pool)
• マネージドインスタンス (Managed instance)

早速「デプロイオプション」という耳慣れない言葉が出てきましたが、Azure SQL Databaseで選べるデータベースの管理方法のようなもの、という理解で良いと思います。

前置き: Microsoft SQL Serverの用語の整理

本題に入る前に、Microsoft SQL Serverの用語をいくつかご紹介しておきます。
これらを理解していないと、Azure SQL Databaseのデプロイオプションの理解が難しいのです。

用語を理解するに当たって、以下の記事が大変参考になりました。

• データベース エンジンのインスタンス (SQL Server) - SQL Server | Microsoft Docs
• Oracle DBA のための、SQL Server 2017 構成と管理のポイント - 1. SQL Server と Oracle のアーキテクチャ比較 - YouTube
• 第1回　SQL Serverのインストールをチェックする (2/3)：SQL Serverミニマム管理Q＆A - ＠IT

Microsoft SQL Serverのインスタンス

SQL ServerがインストールされたWindowsまたはLinuxサーバーのことを、ここでは便宜上「サーバー」と呼びます。

IaaSの世界では、サーバーとインスタンスがほぼ同じ意味で扱われることがありますが、SQL Serverの世界では違います。

「インスタンス」は、サーバーにインストールされたSQL Serverの実体のことであり、SQL Server データベースエンジンの実行単位を指します。

1台のサーバーに複数のインスタンスをインストールすることができます。例えば、複数のバージョンのSQL Serverをインストールしたり、同一バージョンで設定が異なるSQL Serverをインストールすることができます。

インスタンス1つごとに1つのプロセス (SQL Serverサービス) が作成され、インスタンス単位で実行したり、停止することができます。

インスタンスの管理対象

SQL Serverのインスタンスは、5種類のシステムデータベースと、1つまたは複数のユーザーデータベースを管理します。

システムデータベース

以下の5種類がシステムデータベースです。

名前	説明
master	インスタンスとデータベースの構成情報、インスタンスレベルのオブジェクトを格納
model	ユーザーデータベースのテンプレート
msdb	ジョブ、警告、オペレータを格納し、SQL Serverエージェントが使用する
tempdb	ソート、結合、インデックス操作、行バージョン管理などで使用される作業用データベースで、SQL Server起動時に初期化される
resource	システムオブジェクト (sys) が格納される読み取り専用の隠しデータベース

ユーザーデータベース

文字通り、ユーザーが定義したデータベースオブジェクトとデータを永続的に格納するデータベースです。

包含データベース (Contained Database)

SQL Server 2012から利用可能になった機能で、masterデータベースや他のユーザーデータベースから分離されたユーザーデータベースを指します。

より厳密には以下の定義になります。

データベースの定義およびアクセスに必要なユーザー認証、データベースの設定、メタデータをすべて含み、データベースがインストールされた SQL Server Database Engine のインスタンスに対する構成の依存関係を持たない SQL Server データベース。

包含データベースの何が嬉しいのか

一例ですが、包含データベースの登場前は、masterデータベースに登録されたユーザーアカウント (SID) をユーザーデータベース接続の際の認証に用いていました。
あるユーザーデータベースを別のSQL Serverインスタンスに移行したいとなった場合、masterデータベースのSIDもセットで検討する必要がありました。

包含データベースでは、ユーザーデータベースの中に必要な情報が全部入っています。ですので、上記のような移行を行う場合も、ユーザーデータベースのみを移行すれば済みます。
包含データベースは、ユーザーデータベースの可搬性 (ポータビリティ) を高めるのに役立つ仕組みといえるでしょう。

ここが一番大事なポイントで、Azure SQL Databaseの単一データベースには、包含データベースと同じように、必要な情報が全部入っています。

Azure SQL Databaseのデプロイオプション

長かったですが、これで前置きはおしまいです。
ここから本題で、Azure SQL Databaseのデプロイオプションについて見ていきます。

デプロイオプションごとの主な違い

ユーザーの管理範囲

単一データベース＆エラスティックプールとマネージドインスタンスでは、ユーザーが管理できる範囲に違いがあります。

単一データベース＆エラスティックプールでは、ユーザーは主にデータベースを管理します。マネージドインスタンスでは、データベースエンジンのインスタンス (の一部機能) とインスタンス上で動作するデータベースを管理します。

以下の図は SQL Database Managed Instance が始まります – Microsoft Japan Data Platform Tech Sales Team Blog からの引用です。

リソースの占有/共有

単一データベースは、1つのデータベースごとに専用のリソース (コンピューティング、メモリ、ストレージ) を持ちます。
エラスティックプールは、複数のデータベースがリソースを共有します。いわば単一データベースの集合のようなイメージです。
マネージドインスタンスは、1つのインスタンスごとに専用のリソースを持ちます。

デプロイオプションの使い分け

ここでは、デプロイオプションごとの使い分けのポイントとユースケース例について記載します。
いずれも私見ですので、ご検討の際には公式ドキュメントを併せて見て頂くことを推奨します。

• Azure SQL で適切なデプロイ オプションを選択する | Microsoft Docs
• Azure SQL Database の単一データベースとは | Microsoft Docs
• エラスティック プールを使用した複数の SQL Database の管理 | Microsoft Docs
• Azure SQL Database Managed Instance の概要 | Microsoft Docs

単一データベース

データ構造がシンプルで複数のデータベースに分ける必要がない、かつデータベースの負荷が予測できる場合、単一データベースが適しています。

ユースケース例

• リクエスト数が一定のアプリケーション
  • 単一データベースがマッチするユースケースです。データベースのスペックは負荷に合わせて決定します。
• 特定の時間帯にリクエスト数が増加するアプリケーション
  • リクエスト数が増加する時間帯にデータベースのスケールアップ、リクエスト数が落ち着く時間帯にデータベースのスケールダウンを行うプログラムを組むことで、コストを押さえられます。
  • スケールアップ/スケールダウンが完了するタイミングで短時間の接続の中断が発生する可能性があるため、アプリケーション側で一時的な接続エラーの再試行ロジックを実装しておいた方が無難です。

エラスティックプール

負荷特性の異なる複数のデータベースをリソース効率よく管理したい場合、エラスティックプールが適しています。
エラスティックプールは単一データベースの集合のようなもので、既存のプールに単一データベースを追加することができますし、既存のプールから単一データベースを切り出すこともできます。

新規でアプリケーションを開発する場合などに、単一データベースとエラスティックプールのどちらを使うかで迷ったら、まずは単一データベースでシンプルに始めて、必要になったらエラスティックプールに切り替えるという戦略でも問題ないと思います。

ユースケース例

• 複数の企業にサービスを提供するアプリケーションで、企業ごとのデータを別々のデータベースで管理するマルチテナントのアプリケーション
  • この種のアプリケーションでは、アクセス数が非常に多い企業とそうでない企業が混在していたり、企業ごとにアクセス数が多くなるタイミングにばらつきがあったりしますが、それらを正確に予測することが難しい場合が多いです。
  • エラスティックプールでまとめて管理し、リソース使用率が低い状態をなるべく作らないことで、コスト効率を高めることができます。
• マスターデータを扱うデータベース、顧客データを扱うデータベースなど負荷特性の異なる複数のデータベースを扱うアプリケーション
  • この場合もエラスティックプールが有効な選択肢になると思います。
  • データベースごとの負荷特性が予測できる場合、複数の単一データベースという形でも実現できると思います。一方で管理対象のデータベースの数が増える分、運用負荷が上がる可能性もありますから、この辺りの使い分けはケースバイケースで考えるべきでしょう。

マネージドインスタンス

マネージドインスタンスは、オンプレミスやIaaSのSQL Serverからできるだけ手間をかけずにAzure SQL Databaseに移行したいユーザー向けのデプロイオプションです。

最新の SQL Server オンプレミス (Enterprise Edition) データベースエンジンと100%近い互換性があるため、最小限のアプリケーションおよびデータベース変更のみで、オンプレミスやIaaSのアプリケーションをクラウドに移行 (リフト アンド シフト) することができます。

ドキュメントをざっと読む限り、リフトアンドシフト以外のユースケースは見当たりませんでしたので、Azure上で新しくアプリケーションを開発＆デプロイする場合などには、マネージドインスタンスは検討対象から外してしまって問題なさそうです。

おわりに

Azure SQL Databaseのデプロイオプションの概略についてまとめてみました。分かりにくいところや間違っているところなどありましたら、遠慮なくコメントまたは編集リクエストを頂けると幸いです。

以上です。