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

　データベースをまたいだクエリの実行はエラスティッククエリ／エラスティックトランザクションという機能で実現できますが、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プロファイラーや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モデルで選択する必要がある項目は、次の通りです。

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

　サービスレベルや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　シングルデータベースの仮想コアモデルのサイズ設定画面

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

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

　このような情報が公開されており、DTUより性能が予測しやすくなっていることが、仮想コアの特徴です。DTUから仮想コアに変更すること（または、その逆）も可能なので、既に作成済みのデータベースの購入モデルを変更することもできます。

　また、Database Migration Assistantによる推奨サイズの算出は、DTUだけでなく、仮想コアにも対応しているので、既存のSQL Serverの性能情報を基にした仮想コアの対応を確認できます。

　価格の情報から仮想コアとDTUと比較すると、仮想コアの方が高コストに見えるかもしれませんが、仮想コアでは予約の購入方法を利用できます。この購入方法によって、大幅にコストを抑えることができます。長期利用が確定している場合には、こちらの購入方法も検討してください。

　また、Azureハイブリッド特典を使用することでコストを抑えられるので、特典を利用できる場合はこちらも併せて活用してください。

　今回は解説していませんが、仮想コアのモデルでは、最大で100TBのデータベースを利用できるハイパースケールというサービスモデルもあります。大容量のデータベースが必要となった場合は、こちらのサービスモデルの利用も検討してください。

●ネットワーク構成

　SQL Databaseはデータベースを管理するための「論理サーバ」を作成すると、接続先名称として利用する「サーバ名」が付与されます。この「サーバ名」はインターネット経由での接続にも利用できるため、さまざまな環境からアクセス可能なデータベースとして使用できます。

　標準でファイアウォール機能を備えており、論理サーバ／データベースの2種類の粒度で、接続を許可するIPアドレスの指定やAzure内からのアクセスのみを許可する設定、インターネット経由でのアクセスを全て拒否するといった設定が可能です。

　仮想ネットワークエンドポイントの設定を使用すると、自分で作成したAzure内の特定のネットワーク内からのみアクセス可能という制限も行えるので、Azure内からのアクセスも接続元を制御できます（図4）。

図4　SQL Databaseのネットワーク構成