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には、それぞれどのような特徴があるのかを紹介します。
SQL DatabaseとManaged Instanceの特徴
「Azure SQL Database」（以下、SQL Database）と「Azure SQL Database Managed Instance」（以下、Managed Instance）は、どちらもMicrosoft AzureのPaaS（Platform as a Service）ですが、構成や機能に違いがあります。環境の構成も違いの一つです。各環境の概要は、以下の図1のような構成になります。
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）。既存環境は、直近の移行の有無にかかわらず、機能の違いに関する情報収集に最適な環境です。機能の違いを確認する際にはドキュメントだけでなく、このようなアセスメントツールも活用してみてください。
●リソースの利用形態
SQL Databaseのリソースの基本単位は「データベース」で、「シングルデータベース」という利用形態が一般的です。
シングルデータベースでは、データベース単位でリソースの割り当てを設定できるので、負荷を考慮してリソースのサイズを柔軟に調整できます（図2）。アクセス頻度や時間帯に応じてリソースのサイズを変更することで、コスト削減につなげることもできます。
複数のデータベースを作成する場合には「エラスティックプール」という利用形態も検討してください。エラスティックプールでは、「プール」という単位でリソースを管理し、そのリソースをプール内のデータベースで共有することができます（図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モデルのサイズの設定画面です。
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が、仮想コアモデルのサイズの設定画面です。
仮想コアモデルで選択する必要がある項目は、次の通りです。
- 第4世代／第5世代 のコンピューティング世代
- 仮想コア数（仮想コア数に応じて利用可能なメモリが決まる）
- データの最大サイズ
DTUと異なり、仮想コアの場合は利用可能なCPU／メモリ／IOスループットの情報が明記されています（表3）。
| サービスレベル | 汎用目的 | ビジネスクリティカル | |
|---|---|---|---|
| CPU | 第4世代 | 1〜24仮想コア | |
| 第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 シングルデータベースの仮想コアのサービスレベルとリソース制限 | |||
このような情報が公開されており、DTUより性能が予測しやすくなっていることが、仮想コアの特徴です。DTUから仮想コアに変更すること（または、その逆）も可能なので、既に作成済みのデータベースの購入モデルを変更することもできます。
また、Database Migration Assistantによる推奨サイズの算出は、DTUだけでなく、仮想コアにも対応しているので、既存のSQL Serverの性能情報を基にした仮想コアの対応を確認できます。
価格の情報から仮想コアとDTUと比較すると、仮想コアの方が高コストに見えるかもしれませんが、仮想コアでは予約の購入方法を利用できます。この購入方法によって、大幅にコストを抑えることができます。長期利用が確定している場合には、こちらの購入方法も検討してください。
また、Azureハイブリッド特典を使用することでコストを抑えられるので、特典を利用できる場合はこちらも併せて活用してください。
今回は解説していませんが、仮想コアのモデルでは、最大で100TBのデータベースを利用できるハイパースケールというサービスモデルもあります。大容量のデータベースが必要となった場合は、こちらのサービスモデルの利用も検討してください。
●ネットワーク構成
SQL Databaseはデータベースを管理するための「論理サーバ」を作成すると、接続先名称として利用する「サーバ名」が付与されます。この「サーバ名」はインターネット経由での接続にも利用できるため、さまざまな環境からアクセス可能なデータベースとして使用できます。
標準でファイアウォール機能を備えており、論理サーバ／データベースの2種類の粒度で、接続を許可するIPアドレスの指定やAzure内からのアクセスのみを許可する設定、インターネット経由でのアクセスを全て拒否するといった設定が可能です。
仮想ネットワークエンドポイントの設定を使用すると、自分で作成したAzure内の特定のネットワーク内からのみアクセス可能という制限も行えるので、Azure内からのアクセスも接続元を制御できます（図4）。
Copyright © ITmedia, Inc. All Rights Reserved.