DTU ベースの購入モデルでのサービス レベル

適用対象: Azure SQL Database

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

重要

Azure SQL Managed Instance では、DTU ベースの購入モデルはサポートされていません。

注意

仮想コアベースのサービス レベルの詳細については、仮想コアベースのサービス レベルに関するページを参照してください。 DTU ベースのサービス レベルと仮想コアベースのサービス レベルの違いの詳細については、購入モデルに関するページを参照してください。

DTU ベースのサービス レベルを比較する

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

Basic Standard Premium
対象のワークロード 開発、運用 開発、運用 開発、運用
アップタイム SLA 99.99% 99.99% 99.99%
最大バックアップ保有期間 7 日 35 日 35 日
CPU 低、中、高 中、高
IOPS (概算) * DTU あたり 1-4 IOPS DTU あたり 1-4 IOPS DTU あたり 25 IOPS を超える
IO 待機時間 (概算) 5 ミリ秒 (読み取り)、10 ミリ秒 (書き込み) 5 ミリ秒 (読み取り)、10 ミリ秒 (書き込み) 2 ミリ秒 (読み取り/書き込み)
列ストア インデックス作成 該当なし S3 以上 サポートされています
インメモリ OLTP 該当なし 該当なし サポートされています

* データ ファイルに対するすべての読み取り IOPS と書き込み IOPS (バックグラウンド IO を含む) (チェックポイントと LAZY WRITER)

重要

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

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

ヒント

データベースまたはエラスティック プールに対する実際のリソース管理の制限を確認するには、sys.dm_user_db_resource_governance ビューを照会します。

注意

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

Single Database の DTU と容量の上限

コンピューティング サイズは、単一データベースの場合はデータベース トランザクション ユニット (DTU) で、エラスティック プールの場合はエラスティック データベース トランザクション ユニット (eDTU) で表されます。 DTU と eDTU の詳細については、「DTU ベースの購入モデル」を参照してください。

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

重要

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

エラスティック プールの eDTU、ストレージ、プールされたデータベースの上限

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) は、実際のデータベース ワークロードをシミュレートするベンチマークを使用して較正されます。

実際のデータベース パフォーマンスへのベンチマーク結果の関連付け

すべてのベンチマークは単なる典型値であり、指標である点を理解しておくことが重要です。 ベンチマーク アプリケーションで達成されるトランザクション率は、他のアプリケーションで達成されるトランザクション率と同じにはなりません。 ベンチマークは、さまざまなテーブルやデータの種類を含むスキーマに対して実行されるさまざまなトランザクションの種類のコレクションで構成されます。 ベンチマークはすべての OLTP ワークロードに共通する同じ基本操作を実行しますが、特定のクラスのデータベースまたはアプリケーションを表すものではありません。 このベンチマークの目的は、コンピューティング サイズをスケール アップまたはスケール ダウンしたときに予想されるデータベースの相対的なパフォーマンスの適切なガイドを提供することです。 実際には、データベースのサイズと複雑さはさまざまであり、さまざまなワークロードが発生するため、対応方法も変わります。 たとえば、IO の利用が多いアプリケーションでは IO しきい値に達するまでの時間が短くなったり、CPU の使用量が多いアプリケーションでは CPU の上限に達するまでの時間が短くなったりすることがあります。 負荷が増えている状況で、特定のデータベースがベンチマークと同様に拡張する保証はありません。

ベンチマークとその方法について、以下でさらに詳細に説明します。

ベンチマークの概要

このベンチマークは、オンライン トランザクション処理 (OLTP) ワークロードで最も頻繁に発生する、混在した基本的なデータベース操作のパフォーマンスを測定します。 ベンチマークはクラウド コンピューティングを考慮して設計されていますが、データベース スキーマ、データの設定、およびトランザクションは、OLTP ワークロードでよく使用される基本的な要素を広く表すように設計されています。

スキーマ

スキーマは、広範な操作をサポートするのに十分な多様さと複雑さを備えるように設計されています。 ベンチマークは、6 個のテーブルで構成されるデータベースに対して実行されます。 テーブルは、固定サイズ、スケーリング、拡大という 3 つのカテゴリに分類されます。 2 個の固定サイズ テーブル、3 個のスケーリング テーブル、1 個の拡大テーブルがあります。 固定サイズ テーブルには一定の数の行が含まれます。 スケーリング テーブルにはデータベースのパフォーマンスに比例するカーディナリティがありますが、ベンチマークの途中で変化することはありません。 拡大テーブルのサイズは初期状態の負荷ではスケーリング テーブルと同じように設定されますが、ベンチマークの実行中に行が挿入および削除されることによってカーディナリティが変化します。

スキーマには、整数、数値、文字、日時など、さまざまなデータ型が含まれています。 スキーマにはプライマリ キーとセカンダリ キーが含まれますが、外部キーは含まれません。つまり、テーブルの間に参照整合性制約はありません。

データ生成プログラムによって、初期データベースのデータが生成されます。 さまざまな方法で整数データと数値データが生成されます。 場合によっては、値はある範囲にランダムに分散されます。 それ以外の場合は、値のセットの順序がランダムに変更されて、一定の分散が維持されます。 テキスト フィールドは単語の重み付けされたリストから生成され、現実に近いデータが作成されます。

データベースのサイズは "スケール係数" に基づいて設定されます。 スケール係数 (SF と略記) により、スケーリング テーブルと拡大テーブルのカーディナリティが決まります。 「ユーザーとペーシング」で後述するように、データベース サイズ、ユーザー数、最大パフォーマンスはすべて、相互に比例して拡大します。

トランザクション

ワークロードは、次の表で示すように、9 種類のトランザクションで構成されます。 各トランザクションは、データベース エンジンおよびシステム ハードウェアの特定のシステム特性セットが強調され、他のトランザクションとの違いがはっきりわかるように設計されています。 この方法では、異なるコンポーネントのパフォーマンス全体に対する影響を簡単に評価できます。 たとえば、トランザクション "読み取り (高負荷)" では、ディスクからの読み取り操作が大量に生成されます。

トランザクションの種類 説明
読み取り (低負荷) SELECT、メモリ内、読み取りのみ
読み取り (中負荷) SELECT、ほぼメモリ内、読み取りのみ
読み取り (高負荷) SELECT、ほぼメモリ外、読み取りのみ
更新 (低負荷) UPDATE、メモリ内、読み書き
更新 (高負荷) UPDATE、ほぼメモリ外、読み書き
挿入 (低負荷) INSERT、メモリ内、読み書き
挿入 (高負荷) INSERT、ほぼメモリ外、読み書き
削除 DELETE、メモリ内とメモリ外の混合、読み書き
CPU (高負荷) SELECT、メモリ内、比較的大きい CPU 負荷、読み取りのみ

ワークロード ミックス

トランザクションは、次の表のような全体的混合比率で重み付けされた分布からランダムに選択されます。 全体として読み取り/書き込みの比率は約 2:1 になります。

トランザクションの種類 混合の割合
読み取り (低負荷) 35
読み取り (中負荷) 20
読み取り (高負荷) 5
更新 (低負荷) 20
更新 (高負荷) 3
挿入 (低負荷) 3
挿入 (高負荷) 2
削除 2
CPU (高負荷) 10

ユーザーとペーシング

ベンチマークのワークロードは、一連の接続に対してトランザクションを発行して一定数の同時ユーザーの動作をシミュレートするツールによってもたらされます。 すべての接続とトランザクションはコンピューターによって生成されますが、わかりやすくするため、ここではこれらの接続のことを "ユーザー" と呼びます。 各ユーザーは他のすべてのユーザーとは独立して動作しますが、すべてのユーザーは以下に示すような同じ手順のサイクルを実行します。

  1. データベース接続を確立します。
  2. 終了を通知されるまで繰り返します。
    • ランダムにトランザクションを選択します (重み付けされた分布から)。
    • 選択されたトランザクションを実行して応答時間を測定します。
    • ペーシング遅延だけ待機します。
  3. データベース接続を閉じます。
  4. 終了します。

ペーシング遅延 (手順 2c) はランダムに選択されますが、分布の平均は 1.0 秒になります。 したがって、平均すると、各ユーザーが 1 秒間に生成するトランザクションは多くても 1 つです。

スケーリング ルール

ユーザーの数は、データベースのサイズ (スケール係数単位での) によって決まります。 5 スケール係数単位ごとに 1 人のユーザーがいます。 ペーシング遅延のため、平均すると、1 人のユーザーが 1 秒間に生成するトランザクションは多くても 1 つです。

たとえば、スケール係数が 500 (SF=500) のデータベースの場合、ユーザー数は 100 で、最高 100 TPS を実現できます。 TPS 率を高くするには、ユーザー数を増やし、データベースを大きくする必要があります。

測定期間

有効なベンチマーク実行のためには、少なくとも 1 時間は安定状態で測定を行う必要があります。

メトリック

ベンチマークでの重要なメトリックは、スループットと応答時間です。

  • スループットはベンチマークにおける基本的なパフォーマンス尺度です。 スループットは、単位時間あたりのすべてのトランザクション タイプのトランザクション数で表されます。
  • 応答時間は、パフォーマンスの予測可能性の尺度です。 応答時間の制約はサービスのクラスによって異なり、次に示すように、サービス クラスが高いほど応答時間の要件は厳しくなります。
サービスのクラス スループットの測定 応答時間の要件
Premium 1 秒あたりのトランザクション数 0.5 秒で第 95 百分位数
Standard 1 分あたりのトランザクション数 1.0 秒で第 90 百分位数
Basic 1 時間あたりのトランザクション数 2.0 秒で第 80 百分位数

注意

応答時間のメトリックは、DTU ベンチマークに固有のものです。 その他のワークロードの応答時間は、ワークロードによって異なります。

次のステップ