SQL Database Managed Instance の Public Preview が始まりました の続きですが、ドキュメントもいろいろと出ていますので、情報を集めてみました。
数回に分けてまとめていきたいと思います。
Contents
SQL Database Managed Instance の特徴
SQL Database Managed Instance の特徴ですが、What is a Managed Instance (preview)? にまとめられています。
Azure SQL Database Managed Instance は、Azure SQL Database の新しい種類であり、オンプレミス (Box) の SQL Server と 100% に近い互換性を持った、PaaS 型のマネージドサービスとして提供されます。
また、互換性だけでなく、VNET の実装も持っており、セキュリティについても閉じられたネットワークに配置するというような、セキュアな構成が取れるようになっています。
SQL Database
SQL Database も SQL Server のデータベースエンジンをベースとした、PaaS 型のマネージドサービスですが、次のドキュメントに記載されているような、非互換のものがいくつかありました。
SQL Database は、「論理サーバー」という単位に対して、複数のデータベースを配置することが可能となっていますが、論理サーバー配下のデータベースについては、それぞれ別のサーバーにホストされている可能性があります。
論理サーバーはあくまでもデータベースにアクセスするためのエンドポイントとなっていました。
「論理的には一つのサーバーとしてまとまっているように見えるが、各データベースは、異なるサーバーにホストされている」というようなデータベースの管理モデルとなっています。
クロスデータベースのクエリ等が Elastic Query を介しての実行になるのも、論理的には一つのサーバーに紐づいているが、物理的に異なる環境に配置されているからとなります。
このモデルの特徴的な管理方法としては、DB ごとに異なる環境に配置されているため、
- DB 単位で柔軟に価格帯を変えることができる
- 特定 DB のリソース使用状況が、他の DB に影響を与えない
(Single Database Model の場合。Elastic Database モデルの場合は他の DB のリソース使用に影響を与える)
というような点があるかと思います。
SQL を使用した DB 間の依存関係が疎結合な場合は、アプリケーションの実装もしやすいですので、単一の DB で完結するシステムなどは、SQL Database の「Managed Database」モデルはコストメリットとしても利便性が高いのではないでしょうか。
Managed Instance
Managed Instance については、その名の通り「Managed Instance」モデルの管理となります。
SQL Database は、「DB 単位でのリソース提供」モデルですが、Managed Instance は、「インスタンス単位でのリソース提供」となり、一つの物理的な SQL Server 上に複数のデータベースを配置することができるような環境となっています。
インスタンス内に複数のデータベースを作成することができ、各データベースは同一のサーバー内に配置されていますので、クロスデータベースのクエリも、SQL Server と同じ利用方法で使用することができるようになっています。
SQL Database と Managed Instance の違いについては、次のドキュメントに記載されています。
使用できる機能や構文についてはこれらの情報を確認すると良いかと。
- Feature comparison: Azure SQL Database versus SQL Server
- Azure SQL Database Managed Instance T-SQL differences from SQL Server
Managed Instance は SQL Server からの Lift & Shift が意識されたサービスとなっていますが、SQL Server の機能のうち、いくつかサポートされていないものがありますので、何がサポートされていないかはきちんと把握しておく必要があります。
(もちろん、SQL Database より、サポートされている機能は多いです)
AWS のサービスである、RDS for SQL Server に近い Azure のサービスとなるかと思いますが、RDS は、「製品版の SQL Server」をベースにしたサービスであるため、Managed Instance とは サポートされている機能 にも違いはありますので、自分が利用したい環境としてどちらが良いかというのには機能的な面でも差はあるかと。
パフォーマンスについてはサービス層が Managed Instance service tier に記載されています。
Managed Instance タイプのサービスとなりますので、インスタンス単位でパフォーマンスが決まり、CPU コア数 / ディスクスループット / DB サイズにより課金が変わってきます。
SQL Server と近い互換性を持っているという他にも、次のような特徴があります。
- SQL Server 2005 以降のバックアップをリストア可能
- VNET に統合された環境として展開を行う
データベースの移行
まずは、データベースの移行方法についてみていきたいと思います。
既存のデータベースを、SQL Database に移行する場合、SQL Server データベースを Azure SQL Database に移行する に書かれている方法を検討する必要がありました。
Bacpac によるデータベースの移行、Data Migration Assistant (DMA) を使用した移行、Azure Database Migration Service (DMS) を使用した移行 が一般的な方法となるかと思いますが、これらで共通しているのは、
- スキーマとデータがエクスポートされた形式のファイル
を使用して、データベースの移行が行われているため、移行効率がデータベースのバックアップを使用した場合より低かったのではないでしょうか。
SQL Database では、SQL Server で取得しているネイティブなバックアップをリストアすることができませんでしたが、Managed Instance では、SQL Server のネイティブバックアップを使用した移行がサポートされています。
(Bacpac 等を使用した以降もサポートされています。)
これについては、SQL Server instance migration to Azure SQL Database Managed Instance に記載されており、SQL Server 2005 以降のインスタンスを移行する方法として情報が記載されています。
Managed Instance では「Azure BLOB ストレージ」に配置した 「SQL Server の標準機能で取得したバックアップファイル」をリストアすることが可能となっています。
(FileStream / FileTable / Polybase 等の Managed Instance でサポートされていない機能が使用されていないことが前提ですが)
Datamigration Service で Managed Instance に移行する場合 もネイティブバックアップが使用された移行となっています。
ネイティブバックアップを使用した移行は、移行効率がよく、互換性レベルについても次のようなものがサポートされています。
Compatibility levels
- Supported compatibility levels are: 100, 110, 120, 130, 140
- Compatibility levels below 100 are not supported.
- The default compatibility level for new databases is 140. For restored databases, compatibility level will remain unchanged if it was 100 and above.
すべてのネイティブバックアップをリストアできるというわけではなく、複数ログファイルで構成されているデータベースはリストア不可というような制限もありますので、「移行に適したデータベース構成となっているか」については意識しておく必要はあります。
Managed Instance のデータベースの COPY ONLY BACKUP をユーザー主体で取得することも可能ですので「特定の時間断面のデータを残す」や、「データベースのバックアップを使用した他の環境への移行」も対応している形になるのでないでしょうか。
(データベースのバックアップが、どのバージョンの SQL Server にリストアできるかは調査する必要があります)
SQL Database では実施できなかった、RDS for SQL Server の SQL Server データベースのインポートとエクスポート と近い運用が可能になっているかと。
VNET に統合された環境
SQL Database も最近、VNET のサービスエンドポイントを使用使用したセキュリティ制御が可能になりました。
また、ADO.NET 4.5 用の 1433 以外のポート に書かれているような、Azure 内部からのアクセスにダイレクトルートを使用すると行った、外部へのトラフィックを抑える仕組みが導入されていますが、「VNET に統合された環境」となっているわけではなく、Azure ストレージのようなパブリックな分離境界に配置された環境を、セキュリティ設定で分離するというようなアプローチとなっていました。
Managed Instance については、この考えとは異なり、現状は、仮想マシンのように「必ず VNET に参加させる」必要があります。
Configure a VNet for Azure SQL Database Managed Instance
すべての VNET に参加させることができるかというと、そういうことはなく、「他に関連付けられていない専用のサブネット」を持っている必要がある等の制約があります。
Requirements
For Managed Instance creation you need dedicate subnet inside the VNet that conforms to the following requirements:
- Be empty: The subnet must not contain any other cloud service associated to it, and it must not be Gateway subnet. You won’t be able to create Managed Instance in subnet that contains resources other than managed instance or add other resources inside the subnet later.
- No NSG: The subnet must not have a Network Security Group associated with it.
- Have specific route table: The subnet must have a User Route Table (UDR) with 0.0.0.0/0 Next Hop Internet as the only route assigned to it. For more information, see Create the required route table and associate it
- Optional custom DNS: If custom DNS is specified on the VNet, Azure’s recursive resolvers IP address (such as 168.63.129.16) must be added to the list. For more information, see Configuring Custom DNS.
- No Service endpoint: The subnet must not have a Service endpoint (Storage or Sql) associated to it. Make sure that Service Endpoints option is Disabled when creating VNet.
- Sufficient IP addresses: The subnet must have minimum of 16 IP addresses. For more information, see Determine the size of subnet for Managed Instances
そのため、既存の Azure のシステムと接続する必要がある場合には、VNET ピアリング 等を利用した接続が必要になるケースもあるのではないでしょうか。
分離境界としては、完全に VNET に統合されたものとなっていますので、その論理ネットワークは、専用の環境となっているため、ネットワークのセキュリティレベルとしては、SQL Database より強固なものとなっているのではないでしょうか。
脅威検知にも対応しているため、SQL Database が持っているセキュリティ機能も利用することが可能です。
このほかにも様々な情報がありますので続きは後日。