新しいAzureSQLデータベースの標準階層サイズ

Azure SQL Databaseには現在、ワークロード用に選択できる3つのサービス層があります。これらの層は、ベーシック、スタンダード、およびプレミアムで構成されています。 Basicは、5つのDTUの1つのサイズのみをサポートします。プレミアムは125DTUから始まり、4,000DTUまで上がります。プレミアム層は、より高いI / Oワークロード向けに構築された最上位層であり、標準層よりもI / Oあたりの遅延が少なく、DTUあたりのIOPSが1桁多くなります。

2017年8月以前は、標準層は15〜100DTUのDTUサイズのみをサポートしていました。現在プレビューで利用できるのは、CPUを集中的に使用するワークロードに価格最適化のメリットを提供する新しいパフォーマンスレベルとストレージアドオンです。これらにより、標準層は最大3,000のDTUをサポートするようになりました。

この時点で、DTUとは正確には何であるかを自問しているかもしれません。 DTUはデータベーストランザクションユニットであり、CPU、メモリ、データ、およびトランザクションログI/Oを組み合わせたものです。（Andy Mallon、@ AMtwoは、最近「DTUとは何ですか？」でこれに対処しました）CPU、メモリ、またはI / Oを最大化することで、DTUの制限に達することができます。

以前は、標準層は4つのレベルのみを提供していました。15、30、50、および100 DTU、データベースサイズ制限は250 GB、標準ディスクです。 250GBを超えるデータベースがあり、CPU、メモリ、またはI /Oに100DTUを超える必要がない場合は、データベースサイズだけでプレミアム価格を支払うことになります。新しい変更により、標準層に最大1TBのデータベースを含めることができるようになりました。追加のストレージを支払う必要があります。現在、ストレージはプレビュー中に$ 0.085/GBで請求されています。含まれているサイズの250GBから1TBに増やすと、月額$65.79のコストで774GB増加します。

新しい標準プレビューDTUサイズは、200、400、800、1,600、および3,000のDTUオプションをサポートします。 I /OよりもCPUバウンドのSQLServerデータベースワークロードがある場合、これらの標準層オプションを使用すると、多くの費用を節約できる可能性があります。ただし、ワークロードがI / Oバウンドの場合、プレミアム層はスタンダード層よりもパフォーマンスが高くなります。

2つの異なるワークロードを試して、標準層とプレミアム層が互いにどのように異なるかを確認することにしました。他の人が自分で検証できるように、シンプルで再現性のあるテストを作成したかったのです。最初のテストでは、CPUとI/Oの健全な組み合わせを生成したいと思いました。 I / Oよりも多くのCPUをプッシュし、拡張された標準層が同じDTUサイズのプレミアム層よりも優れていることを示すことができることを期待していました。期待した結果が得られませんでした。

このデモを設定するために、3つのGUID列を持つテーブルを作成し、100万行を挿入してから、3つの列のうち2つを新しいIDで更新しました。サンプルコードは以下のとおりです：

CREATE TABLE dbo.TestTable
(
  Table_id UNIQUEIDENTIFIER DEFAULT NEWID(),
  Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(),
  Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40))
);
 
SET NOCOUNT ON;
GO
 
INSERT INTO dbo.TestTable DEFAULT VALUES;
GO 1000000
 
CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable]
(
  [Table_id] ASC,
  [Customer_id] ASC
);
 
SET STATISTICS TIME ON;
 
UPDATE TestTable
  SET Table_id = NEWID(), Customer_id = NEWID();

一連のテストを実行すると、標準層でパフォーマンスが着実に向上し、奇妙なことにCPUと経過時間が増加するS12オプションに到達しました。テストを複数回実行しましたが、S12は一貫して54秒でした。私の最初のテストでは、プレミアム層がスタンダード層を上回っていることは明らかです。たとえば、S9とP2は時間的に最も近いですが、標準のDTUサイズはP2の250に対して、1,600です。このテストは、I/O機能に関するものです。次のグラフは、各テストのサイズ、DTUレベル、コスト、CPU時間、経過時間、および秒単位の時間を示しています。

テストが実行されているときに、モニターダッシュボードで、データI/OとログI/Oの割合がDTUの割合の背後にある原動力であることがわかりました。次のグラフは、S4データベースに対する実行からのものです。

次に、CPUをより多く使用する別の一連のテストを試すことにしました。そのテストでは、次のスクリプトを使用しました：

SET STATISTICS TIME ON;
 
SELECT SUM(CONVERT(BIGINT, t1.object_id) 
         + CONVERT(BIGINT, t2.object_id) 
         + CONVERT(BIGINT, t3.object_id) 
         + CONVERT(BIGINT, t4.object_id))
  FROM sys.objects t1
  CROSS JOIN sys.objects t2
  CROSS JOIN sys.objects t3
  CROSS JOIN sys.objects t4;

この一連のテストのモニターダッシュボードで私が観察したのは、CPUパーセンテージがDTUパーセンテージの唯一のドライバーであったということです。標準層で一連のテストを行ったところ、テストは約27秒で横ばいになり、S4サイズで開始されたようです。奇妙なことに私を驚かせたのは、200 DTUのS4が完了するのに27秒かかり、250DTUの対応するP2が38秒かかったことです。 500DTUのP4はより同等でした。このデモのコスト差を見ると、プレビュー中のS4のコストはわずか150.01ドルですが、P4のコストは1,860ドルです。 S4は、1,700ドル強のコスト削減を実現します。 250DTUのP2が予想どおりに機能したと想像してみましょう。 P2の価格は930ドルで、S4よりも780ドル高くなります。

2番目のデモのすべてのテストの完全な結果は、次のグラフに含まれています。

最初のデモとは異なり、これは100％CPU駆動でした。クロスジョインを1つ追加しようとしましたが、デモではセッションごとに数分ではなく数時間かかりました。将来のテストのために、より現実的なOLTPワークロードをプッシュするいくつかの追加シナリオを考え出すようにします。 1つはCPUが高く、もう1つはI / Oバウンドが高く、2つを適切にブレンドしたものです。

下のグラフから、S4データベースに対するこの実行では、CPUがほぼ50％で急上昇し、DTUの割合が正確に一致していることがわかります。

私がテストした2つの異なるワークロードから、重要なI / Oワークロードがある場合はプレミアム層が必要になることは明らかですが、ワークロードがほとんどCPUにバインドされており、重要なI / Oが必要ない場合は、より高い標準階層では、プレミアム階層よりも大幅に節約できます。

Azure SQLデータベースへの移行を検討している場合、DTU計算機は、サイジングの開始点のアイデアを得るのに最適な場所です。ただし、執筆時点では、DTU計算機は拡張された標準階層を考慮していません。 DTU計算機の優れている点は、CPU、IOP、およびログ使用率を分析して、DTUレベルの推奨事項の推進要因を通知することです。たとえば、最後のデモを4 vCPU、4GB仮想マシンで実行したところ、DTU計算機がP2を推奨しました。「詳細を表示」を選択すると、次のメッセージが表示されました。

CPUのサービス層/パフォーマンスレベル – CPU使用率のみに基づいて、SQL ServerワークロードをPremium–P2に移行することをお勧めします。このサービス階層/パフォーマンスレベルは、CPU使用率の約100.00％をカバーする必要があります。

Iopsのサービス階層/パフォーマンスレベル – Iops使用率のみに基づいて、SQLServerワークロードをBasicに移行することをお勧めします。このサービスティア/パフォーマンスレベルは、Iops使用率の約89.92％をカバーする必要があります。

注：ワークロードの約10.08％が、より高いサービス層/パフォーマンスレベルに分類されます。データベースをAzureに移行した後、上記の情報セクションに記載されているガイダンスを使用して、データベースのパフォーマンスを評価する必要があります。

ログのサービス階層/パフォーマンスレベル –ログの使用率のみに基づいて、SQLServerワークロードをBasicに移行することをお勧めします。このサービス階層/パフォーマンスレベルは、ログ使用率の約100.00％をカバーする必要があります。

このワークロードはCPUに大きく依存していることがわかっているため、ワークロードを調整してCPU要件を減らすことができない場合は、標準層で最大3,000のDTUを使用できます。 250 DTUのP2に月額930ドルを費やすよりも、月額150ドルで200 DTUのS4（または月額300.02ドルで400 DTUのS6）の方がはるかに経済的なオプションです。

結論として、Azure SQLデータベースの移行のサイズの適切な開始点を決定するのに役立つツールがありますが、絶対に最善の方法は、ワークロードをテストすることです。本番データベースのコピーを移行し、本番ワークロードをキャプチャし、そのワークロードをAzure SQLデータベースに対して再生すると、本当に必要なDTUサイズをよりよく理解できます。