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

適用対象: Azure SQL データベース

この記事では、Azure SQL データベースの DTU ベースの購入モデルの概要について説明します。 DTU ベースの購入モデルは、コンピューティング、ストレージ、および I/O リソースのシンプルなバンドルされたメジャーです。 これは、一般的なワークロードを持つほとんどの顧客に最適です。 DTU ベースの購入モデルでは、Basic、Standard、Premium サービス レベルを利用できます。 DTU ベースの購入モデルは、Elastic Pool でも使用できます。

DTU ベースの購入モデルは、仮想コアベースの購入モデルとは異なるので、購入モデルを比較できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プールは、リソース使用率の平均が低く、使用率の急上昇が比較的発生しにくいデータベースに適しています。 詳細については、「Azure SQL データベース のエラスティック プール」を参照してください。

ワークロードで必要とされる 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 から、最大の割合値を選びます。

ハードウェア構成

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

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

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

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

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

サービス レベルの比較

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

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

² 詳細については、「列ストア インデックスを含むデータベースのサービス レベルの変更」を参照してください。

リソース制限

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

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

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

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

詳細については、「DTU 購入モデルを使用したエラスティック プールのリソース制限」を参照してください。

DTU ベンチマーク

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

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

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

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

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

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

関連するコンテンツ

• 単一データベースのDTU ベースのリソース制限
• DTU ベースのリソース制限
• DTU ベンチマーク
• Azure SQL Database の仮想コアと DTU ベースの購入モデルを比較