DTU ベースの購入モデルの概要

  • [アーティクル]

適用対象:Azure SQL Database

この記事では、Azure SQL Database の DTU ベースの購入モデルについて説明します。

詳細については、「仮想コアベースの購入モデル」と「購入モデルの比較」を確認してください。

データベース トランザクション ユニット (DTU)

データベース トランザクション ユニット (DTU) は、CPU、メモリ、読み取り、書き込みを組み合わせた測定値を表します。 DTU ベースの購入モデルでのサービス レベルは、固定された容量の付属ストレージ、固定されたバックアップ保有期間、および固定された価格を持つさまざまなコンピューティング サイズによって区別されます。 DTU ベースの購入モデルのどのサービス レベルにも、最小限のダウンタイムでコンピューティング サイズを変更できる柔軟性があります。ただし、データベースへの接続が短時間失われる切り替え期間があります。これは、再試行ロジックを使用することで軽減できます。 単一データベースとエラスティック プールは、サービス レベルとコンピューティング サイズに基づいて時間単位で課金されます。

サービス レベル内にある特定のコンピューティング サイズの単一データベースの場合、Azure SQL データベースでは、そのデータベース (他のデータベースから独立した) に対し、特定のレベルのリソースが保証されます。 この保証によって、予測可能なレベルのパフォーマンスが提供されます。 データベースに割り当てられるリソースの量は、DTU の数として計算され、コンピューティング、ストレージ、および I/O リソースのバンドルされた測定値です。

これらのリソース間の比率は、本来、一般的な現実の OLTP ワークロードになるように設計されたオンライン トランザクション処理 (OLTP) ベンチマーク ワークロードによって決定されます。 ワークロードがこれらのいずれかのリソース量を超えると、スループットが調整され、パフォーマンスが低下してタイムアウトが発生します。

単一データベースの場合、お使いのワークロードによって使用されるリソースは、Azure クラウドにある他のデータベースで使用できるリソースには影響を及ぼしません。 同様に、その他のワークロードによって使用されるリソースが、お使いのデータベースで使用できるリソースに影響を及ぼすことはありません。

A descriptive infographic about the DTU purchasing model. The four sides of the box are Writes, CPU, Reads, and Memory, describing how DTU workloads are a blend of CPU, memory, and read-write rates.

DTU は、さまざまなコンピューティング サイズとサービス レベルのデータベースに割り当てられるリソースの相対量を理解するために最も役立ちます。 次に例を示します。

  • データベースのコンピューティング サイズを引き上げて DTU を 2 倍にするのは、そのデータベースに利用できるリソース セットを 2 倍にすることと同等です。
  • DTU が 1750 である Premium サービス レベルの P11 データベースは、DTU が 5 である Basic サービス レベルのデータベースと比べて、350 倍の DTU コンピューティング能力を提供します。

お使いのワークロードのリソース (DTU) 使用量の詳細を把握するには、クエリ パフォーマンスの分析情報を使用して、次のようにします。

  • CPU/期間/実行回数によって、パフォーマンス向上のためのチューニング対象になり得る上位クエリを特定します。 たとえば、I/O 負荷の高いクエリでは、特定のサービス レベルとコンピューティング サイズで利用可能なメモリをより効率的に使用するメモリ内最適化手法によって、メリットが得られる場合があります。
  • クエリの詳細にドリルダウンして、そのテキストやリソース使用率の履歴を表示します。
  • SQL Database Advisor によって実行されるアクションを示すパフォーマンス チューニングの推奨事項を表示します。

エラスティック データベース トランザクション ユニット (eDTU)

必ずしも必要になるとはかぎらない専用のリソース セット (DTU) を提供する代わりに、これらのデータベースをエラスティック プールに配置できます。 エラスティック プール内のデータベースは、データベース エンジンの 1 つのインスタンスを使用し、同じリソース プールを共有します。

エラスティック プール内の共有リソースは、エラスティック データベース トランザクション ユニット (eDTU) によって測定されます。 エラスティック プールは、幅広く異なる予測できない使用パターンを持つ複数のデータベースに対するパフォーマンス目標を管理するための、簡単かつコスト効率に優れたソリューションを提供します。 エラスティック プールは、プール内の 1 つのデータベースによってすべてのリソースを消費できないことを保証する一方で、プール内の各データベースが常に、最低限必要な量の利用可能なリソースを保持していることを保証します。

プールには、設定価格に合わせて、設定された eDTU 数が与えられます。 エラスティック プールでは、個々のデータベースは、構成された境界内で自動スケーリングすることが可能です。 データベースの負荷が増加すると、需要に対応するため eDTU の消費量が増えます。 データベースの負荷が減少すると、eDTU の消費が減ります。 負荷のないデータベースは eDTU を消費しません。 データベースごとではなく、プール全体に対してリソースがプロビジョニングされるため、エラスティック プールでは管理タスクを簡素化し、プールの予算が予測可能になります。

最小限のデータベース ダウンタイムで、既存のプールに eDTU を追加できます。 同様に、追加の eDTU は、必要がなくなれば、既存のプールからいつでも削除してください。 また、プールに対するデータベースの追加やデータベースの除去は、いつでも可能です。 他のデータベース用に eDTU を予約するには、負荷の高い状況下でデータベースが使用できる eDTU の数を制限します。 データベースのリソース使用率が常に高くプール内の他のデータベースに影響を及ぼす場合は、それをプールから移動して、必要なリソース量が予測可能な単一データベースとして構成します。

リソースのエラスティック プールを使うとメリットがあるワークロード

プールは、リソース使用率の平均が低く、使用率の急上昇が比較的発生しにくいデータベースに適しています。 詳しくは、「SQL Database エラスティック プールを検討すべきとき」をご覧ください。

ワークロードで必要とされる DTU の数を決定する

既存のオンプレミスのワークロードや、SQL Server 仮想マシンのワークロードを SQL Database に移行することを検討している場合は、SKU の推奨事項を参照して必要な DTU のおおよその数を調べます。 既存の SQL Database ワークロードについては、クエリ パフォーマンスの分析情報を使用してデータベース リソースの消費量 (DTU) を把握し、ワークロードを最適化するための詳細な分析情報が得られます。 sys.dm_db_resource_stats 動的管理ビュー (DMV) を使用して、過去 1 時間のリソース消費量を表示できます。 sys.resource_stats カタログ ビューは、過去 14 日間のリソース消費量を表示しますが、データの精度がやや低く、5 分間の平均となります。

DTU 使用率を決定する

データベースまたはエラスティック プールの DTU/eDTU 上限に対する相対的な DTU/eDTU の平均使用率を決定するには、次の式を使用します。

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

この式に入力する値は、sys.dm_db_resource_stats、sys.resource_stats、および sys.elastic_pool_resource_stats DMV から取得できます。 つまり、データベースまたはエラスティック プールの DTU/eDTU 上限に対する DTU/eDTU の使用率を決定するには、特定の時点での avg_cpu_percent、avg_data_io_percent、および avg_log_write_percent から、最大の割合値を選びます。

Note

データベースの DTU 上限は、そのデータベースで使用できる CPU、読み取り、書き込み、およびメモリによって決まります。 ただし、SQL Database エンジンでは、通常、パフォーマンス向上のためにそのデータ キャッシュ用に利用できるすべてのメモリが使用されるため、avg_memory_usage_percent の値は、現在のデータベースの負荷に関係なく、通常は 100% 近くになります。 そのため、メモリが DTU 上限に間接的に影響する場合でも、DTU 使用率の式では使用されません。

ハードウェア構成

DTU ベースの購入モデルでは、お客様は自分のデータベースに使用されるハードウェア構成を選択できません。 データベースは通常、長い間 (通例、数か月)、特定の種類のハードウェアに留まりますが、データベースを別のハードウェアに移すイベントがあります。

たとえば、別のサービス目標にスケール アップまたはスケール ダウンする場合、データ センターにある現在のインフラストラクチャがその容量制限に近づいている場合、あるいは現在使用されているハードウェアが耐用年数終了により使用停止になる場合、データベースを別のハードウェアに移動できます。

データベースを別のハードウェアに移動すると、ワークロード パフォーマンスが変わることがあります。 DTU モデルでは、サービス目標 (DTU の数) が同じである限り、データベースを別の種類のハードウェアに移動しても、DTU ベンチマーク ワークロードのスループットと応答時間がおおむね同じになります。

ただし、Azure SQL Database で実行されている顧客ワークロードは幅が広く、同じサービス目標に別のハードウェアを使用したときの影響がもっと目立つこともあります。 ハードウェアの構成や特徴が違えば、恩恵を受けるワークロードも異なる場合があります。 そのため、DTU ベンチマーク以外のワークロードについては、データベースをある種類のハードウェアから別のものに移した場合、パフォーマンスに違いが見られることがあります。

お客様は、データベースの作成中とスケーリング中に、仮想コア モデルを使用して優先するハードウェア構成を選択できます。 仮想コア モデルでは、単一データベースとエラスティック プールに対して、ハードウェア構成ごとに各サービス目標の詳細なリソース上限が記録されます。 仮想コア モデルでのハードウェアの詳細については、SQL Database のハードウェア構成または SQL Managed Instance のハードウェア構成に関するセクションを参照してください。

サービス レベルの比較

サービス レベルの選択は、主に、ビジネス継続性、ストレージ、およびパフォーマンスの要件に依存します。

Basic Standard Premium
対象のワークロード 開発、運用 開発、運用 開発、運用
アップタイム SLA 99.99% 99.99% 99.99%
Backup geo 冗長、ゾーン冗長、ローカル冗長のバックアップストレージの選択肢、1 〜 7 日の保持期間（既定では 7 日）
最長 10 年間の長期保有期間		 geo 冗長、ゾーン冗長、ローカル冗長のバックアップストレージの選択肢、1 〜 35 日の保持期間（既定では 7 日）
最長 10 年間の長期保有期間		 ローカル冗長(LRS)、ゾーン冗長(ZRS)、geo 冗長(GRS)ストレージの選択肢
1 から 35 日 (既定では 7 日間) のデータ保有、最大 10 年間の長期保有が可能
CPU 低 低、中、高 中、高
IOPS (概算)* DTU あたり 1-4 IOPS DTU あたり 1-4 IOPS >DTU あたり 25 IOPS
IO 待機時間 (概算) 5 ミリ秒 (読み取り)、10 ミリ秒 (書き込み) 5 ミリ秒 (読み取り)、10 ミリ秒 (書き込み) 2 ミリ秒 (読み取り/書き込み)
列ストア インデックス作成 該当なし Standard S3 以降 サポートされています
インメモリ OLTP 該当なし 該当なし サポートされています

* データ ファイルに対するすべての読み取り IOPS と書き込み IOPS。これにはバックグラウンド IO (チェックポイントと遅延ライター) が含まれます。

重要

Basic、S0、S1、S2 のサービス目標では、1 未満の仮想コア (CPU) が提供されます。 CPU 負荷の高いワークロードの場合は、S3 以上のサービス目標をお勧めします。

Basic、S0、および S1 のサービス目標では、データベース ファイルは Azure Standard Storage に格納されます。ここでは、ハード ディスク ドライブ (HDD) ベースのストレージ メディアが使用されます。 これらのサービス目標は、パフォーマンス変動の影響を受けにくい、開発、テスト、その他のアクセス頻度の少ないワークロードに最適です。

ヒント

データベースまたはエラスティック プールに対する実際のリソース管理の制限を確認するには、sys.dm_user_db_resource_governance ビューを照会します。 単一データベースの場合、1 つの行が返されます。 エラスティック プール内のデータベースの場合、プール内のデータベースごとに行が返されます。

注意

Azure 無料アカウントの Basic サービス レベルで、Azure SQL Database の無料データベースを取得できます。 詳細については、「Azure の無料アカウントでマネージド クラウド データベースを作成する」をご覧ください。

リソース制限

リソース制限が単一データベースとプールされたデータベースで異なります。

単一データベースのストレージ制限

Azure SQL Database では、コンピューティング サイズは、単一データベースの場合はデータベース トランザクション ユニット (DTU) で、エラスティック プールの場合はエラスティック データベース トランザクション ユニット (eDTU) で表されます。 詳細については、「単一データベースに関するリソース制限」を確認してください。

Basic Standard Premium
最大ストレージ サイズ 2 GB 1 TB (テラバイト) 4 TB
最大 DTU 5 3000 4000

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。

エラスティック プールの制限

詳細については、「プールされたデータベースに関するリソース制限」を確認してください。

Basic Standard Premium
データベースあたりの最大ストレージ サイズ 2 GB 1 TB (テラバイト) 1 TB (テラバイト)
プールあたりの最大ストレージ サイズ 156 GB 4 TB 4 TB
データベースあたりの最大 eDTU 数 5 3000 4000
プールあたりの最大 eDTU 数 1600 3000 4000
プールあたりのデータベースの最大数 500 500 100

重要

現在、1 TB を超える Premium レベルのストレージは、中国東部、中国北部、ドイツ中部、ドイツ北東部、を除くすべてのリージョンで利用できます。 これらのリージョンでは、Premium レベルのストレージの最大容量は 1 TB です。 詳しくは、P11-P15 の現在の制限事項に関するページをご覧ください。

重要

場合によっては、未使用領域を再利用できるようにデータベースを縮小する必要があります。 詳細については、「Manage file space in Azure SQL Database」(Azure SQL Database でファイル領域を管理する) を参照してください。

DTU ベンチマーク

DTU の各測定に関連付けられている物理的な特性 (CPU、メモリ、IO) は、実際のデータベース ワークロードをシミュレートするベンチマークを使用して較正されます。

DTU ベンチマークに関連するスキーマ、使用されるトランザクションの種類、ワークロードの組み合わせ、ユーザーとペーシング、スケーリング ルール、メトリックについて説明します。

DTU ベースと仮想コアの購入モデルの比較

DTU ベースの購入モデルは、コンピューティング、ストレージ、および I/O リソースのバンドルされた測定値に基づいています。一方の Azure SQL Database の仮想コア購入モデルは、コンピューティング リソースとストレージ リソースを個別に選択してスケーリングできます。

仮想コアベースの購入モデルでは、SQL Server の Azure ハイブリッド特典を使用してコストを節約したり、Azure SQL Database で DTU ベースの購入モデルでは使用できないサーバーレスおよびハイパースケールのオプションを提供したりすることもできます。

詳細については、Azure SQL Database の仮想コアと DTU ベースの購入モデルの比較に関する記事を参照してください。

次の手順

購入モデルと、関連する概念の詳細については、次の記事を参照してください。