Azureで利用可能なPaaSのSQL Serverの特徴を学ぼう［後編］――Azure SQL DatabaseとAzure SQL Database Managed Instanceの違い：クラウドのSQL Serverを最大限に活用するために（1/2 ページ）

前編では、Microsoft Azureで利用可能なPaaSのSQL Serverの種類と、AzureのPaaS「Azure SQL Database」と「Azure SQL Database Managed Instance」に共通する特徴を解説しました。後編では、SQL DatabaseとManaged Instanceには、それぞれどのような特徴があるのかを紹介します。

» 2019年04月12日 05時00分公開

[小澤真之／Microsoft MVP for Data Platform，＠IT]

SQL DatabaseとManaged Instanceの特徴

Azureで利用可能なPaaSのSQL Serverの特徴を学ぼう［前編］

　「Azure SQL Database」（以下、SQL Database）と「Azure SQL Database Managed Instance」（以下、Managed Instance）は、どちらもMicrosoft AzureのPaaS（Platform as a Service）ですが、構成や機能に違いがあります。環境の構成も違いの一つです。各環境の概要は、以下の図1のような構成になります。

図1　SQL DatabaseとManaged Instanceの構成の違い

　SQL Databaseは「論理サーバ」という管理単位の中にデータベースが作成され、「各データベースが独立したリソース」となり、データベース単位でリソースのサイズを柔軟に調整できます。

　各データベースは論理サーバという管理単位の中に配置されますが、それぞれ独立したリソースとなっているため、データベースをまたがるクエリ実行については注意が必要です。

　データベースをまたいだクエリの実行はエラスティッククエリ／エラスティックトランザクションという機能で実現できますが、SQL Serverとは方法が異なります。

　一方、Managed Instanceは「インスタンスにリソースを割り当て、インスタンス内に各データベースを作成する」という構成で、各データベースは同一インスタンスのリソースを使用します。この構成はSQL Serverと同じなので、SQL Serverと同じ操作性で利用できます。

　また、SQL Databaseとは異なり、データベースが同一インスタンス内に存在しているため、データベースをまたいだクエリもSQL Serverと同様の方法で実行できます。その他、「SQL Serverエージェント」機能のサポートなどもあり、SQL Serverと高い互換性を備えたPaaS環境として利用できます。

　では、SQL DatabaseとManaged Instanceには、この他にどのような特徴があるのかを見ていきましょう。

SQL Database（シングルデータベース／エラスティックプール）の特徴

　データベースが利用できる環境を構築する目的は「情報（データ）を活用（格納／分析）するための領域（データストア）を作成する」ことではないでしょうか。

　SQL Databaseは、この目的に向け、「環境構築に時間をかけず、すぐにデータベースを使い始める」ことができる最適な環境です。さまざまなリソースのサイズが提供されており、ポータルからの簡単な操作ですぐに利用できます。

●SQL Serverとの機能の違い

　前編でも少し触れましたが、SQL DatabaseはSQL Serverのデータベースエンジンを使用したRDBMS（リレーショナルデータベース管理システム）ですが、SQL Serverの一部の機能は利用することができません（機能向上／改善により、以前は機能の違いがあったものが、最新状態では解消されている可能性もありますので、サービスを利用するタイミングで最新の情報を確認してください）。

　代表的な違いとしては、表1のような機能があります。


SQL Serverとの機能の違い	代替案
タイムゾーンがUTC（協定世界時）固定	日本時間を使用する必要がある場合は9時間の差を考慮するように処理を実装する
SQL Serverと同一の方法でデータベースをまたいだクエリを実行できない	エラスティッククエリやエラスティックトランザクションで代替可能かどうかを検討
リンクサーバをサポートしていない	Azure BLOBストレージを介したデータアクセスやAzure Data Factoryなどの機能で外部データ連携が代替可能かどうかを検討
レプリケーションはトランザクション／スナップショットのサブスクライバーのみをサポート	SQL Databaseを起点としたデータ同期が必要な場合、Data Syncで代替可能かどうかを検討
SQL Serverのネイティブバックアップを利用できない（BACKUP／RESTOREステートメントをサポートしていない）	BACPACファイルを使用したデータベースのエクスポート／インポートで代替可能かどうかを検討
Windows認証をサポートしていない	Azure Active Directory認証で認証管理が代替可能かどうかを検討
SQL Serverプロファイラーによるクエリ情報の取得をサポートしていない	拡張イベントで代替可能かどうかを検討
SQL Serverエージェントをサポートしていない	Azure Automationなどの機能で代替可能かどうかを検討
表1　SQL DatabaseとSQL Serverの代表的な機能の違い

　機能の違いには、タイムゾーンやデータベースをまたいだクエリ実行のような開発観点の考慮が必要なもの、SQL ServerプロファイラーやSQL Serverエージェントといった運用観点の考慮が必要なものがあります。

　この他、SQL Serverとの機能の違いについてはこちらの情報を参照してください。

　既存のSQL Server環境がある場合「Database Migration Assistant」で、SQL Databaseに移行する際のアセスメントを実行することで、移行にどのような問題があるのかを確認できます（画面1）。既存環境は、直近の移行の有無にかかわらず、機能の違いに関する情報収集に最適な環境です。機能の違いを確認する際にはドキュメントだけでなく、このようなアセスメントツールも活用してみてください。

画面1　「Database Migration Assistant」を使用したSQL Databaseとの互換性のアセスメント

●リソースの利用形態

　SQL Databaseのリソースの基本単位は「データベース」で、「シングルデータベース」という利用形態が一般的です。

　シングルデータベースでは、データベース単位でリソースの割り当てを設定できるので、負荷を考慮してリソースのサイズを柔軟に調整できます（図2）。アクセス頻度や時間帯に応じてリソースのサイズを変更することで、コスト削減につなげることもできます。

図2　シングルデータベースのリソースの利用形態

　複数のデータベースを作成する場合には「エラスティックプール」という利用形態も検討してください。エラスティックプールでは、「プール」という単位でリソースを管理し、そのリソースをプール内のデータベースで共有することができます（図3）。

図3　エラスティックプールのリソースの利用形態

　「データベースによって負荷が高くなる時間が異なり、ピークタイムがずれる」というような、“瞬間的に一定の性能が必要だが、恒常的に高い性能は不要”という場合は、エラスティックプールが適しています。

　データベースの数が多い場合は、各データベースをシングルデータベースで作成するよりも、エラスティックプールで作成することでコストを抑えられる可能性があります。シングルデータベースとエラスティックプールはデータベースを作成した後でも、相互に変更することができます。

　データベースの数やデータベース利用者が増えた場合には、利用形態を変更することで、さまざまなメリットを得られる可能性があります。状況に応じて利用形態の変更を検討してください。

●購入モデル

　SQL Databaseには「DTU」と「仮想コア」という2つの購入モデルがあり、リソースサイズをこの2種類のモデルから選択できます。

■DTU
　DTUは「Database Transaction Unit」の略です。データベースを利用する際には「CPUコア数がxxで、メモリがxxGB、ディスク性能がxxxxIOPS/MB/sec」というような「利用可能なリソース」を基に利用する環境のサイズを検討することが多いのではないでしょうか。

　DTUの購入モデルについては、割り当てられているリソースの具体的な値は公開されておらず、DTUという相対的な単位で性能（利用可能なリソース）が表現されます。

　例えば、200DTUという性能であれば、100DTUの2倍のリソースが割り当てられており、トランザクションのスループットが2倍になるというような考え方ができます。しかし、それぞれのDTUで利用可能なリソースの明示的な値については提示されていません。

　以下の画面2が、DTUモデルのサイズの設定画面です。

画面2　シングルデータベースのDTUモデルのサイズ設定画面

　DTUモデルで選択する必要がある項目は、次の通りです。

Basic／Standard／Premiumのサービスレベルの設定
各サービスレベルに応じたDTUのサイズの指定
データベースの最大サイズ

　サービスレベルに応じて、利用可能な機能／基本性能／DTUなどのリソース制限が異なりますので、利用目的に応じたサービスレベルを選択する必要があります（表2）。


サービスレベル		Basic	Standard	Premium
DTU		5	10、20、50、100、200、400、800、1600、3000	125、250、500、1000、1750、4000
基本性能	IOスループット	DTU当たり 2.5 IOPS		DTU当たり 48 IOPS
基本性能	IO待機時間	読み込み：5ミリ秒書き込み：10ミリ秒		読み込み／書き込み：2ミリ秒
最大ストレージサイズ		2GB	1TB	4TB
バックアップ保有期間		7日	35日	35日
読み取り可能レプリカ		なし	なし	あり
利用可能な機能	列ストアインデックス	不可	S3以上は利用可能	利用可能
利用可能な機能	インメモリOLTP	不可	不可	利用可能
表2　シングルデータベースのDTUのサービスレベルとリソース制限

　サービスレベルやDTUのサイズについては、データベースの作成後も状況に応じて柔軟に変更することができます。

　現在、SQL Serverを利用しており、SQL Serverの負荷状況を基にして対応したDTUが知りたい場合には、Azure SQL Database DTU CalculatorやDatabase Migration Assistantを使用してください。これらのツールで、SQL Serverの負荷状況に応じたDTUの推奨サイズを算出できます。

　DTUは安価にデータベースを利用できますが、割り当てられているリソースは“相対的”なものになり、DTUの考え方に慣れていないとサイズの判断に悩むことがあります。利用可能なリソースの具体的な情報が提示されていて、性能を予測しやすい環境が望ましい場合には、次に紹介する「仮想コア」モデルを検討してください。

■仮想コア
　仮想コアでは「汎用目的」と「ビジネスクリティカル」の2種類のモデルが提供されており、使用するハードウェアのコンピューティング世代についても、第4世代／第5世代という2種類から選べます。これらの組み合わせによりリソースの制限が変わります。

　以下の画面3が、仮想コアモデルのサイズの設定画面です。

画面3　シングルデータベースの仮想コアモデルのサイズ設定画面

　仮想コアモデルで選択する必要がある項目は、次の通りです。

第4世代／第5世代のコンピューティング世代
仮想コア数（仮想コア数に応じて利用可能なメモリが決まる）
データの最大サイズ

　DTUと異なり、仮想コアの場合は利用可能なCPU／メモリ／IOスループットの情報が明記されています（表3）。


サービスレベル		汎用目的	ビジネスクリティカル
CPU	第4世代	1～24仮想コア
CPU	第5世代	1～80仮想コア
メモリ	第4世代	コア当たり 7GB
メモリ	第5世代	コア当たり 5.1GB
最大ストレージサイズ		4TB	4TB
利用ストレージ		Azure Premiumストレージ	ローカルSSDストレージ
IOスループット		コア当たり 500 IOPS 最大 7000 IOPS	コア当たり 5000 IOPS 最大20万IOPS
バックアップ保有期間		7～35日	7～35日
読み取り可能レプリカ		なし	あり
利用可能な機能	列ストアインデックス	利用可能	利用可能
利用可能な機能	インメモリOLTP	不可	利用可能
表3　シングルデータベースの仮想コアのサービスレベルとリソース制限