Azure Premium Storage: 高パフォーマンスのための設計

概要

この記事では、Azure Premium Storage を使用する高パフォーマンスのアプリケーションを構築するためのガイドラインを示します。 このドキュメントで説明する手順は、アプリケーションで使用されているテクノロジに適用できるパフォーマンスのベスト プラクティスと組み合わせて使用できます。 ガイドラインを示すために、このドキュメント全体を通じて、Premium Storage で実行されている SQL Server を例として使用しています。

この記事では、ストレージ層のパフォーマンスのシナリオに対処していますが、アプリケーション層を最適化する必要があります。 たとえば、Azure Premium Storage で SharePoint ファームをホストしている場合は、この記事の SQL Server の例を使用してデータベース サーバーを最適化できます。 さらに、最大限のパフォーマンスを得るために、SharePoint ファームの Web サーバーとアプリケーション サーバーを最適化します。

この記事は、Azure Premium Storage でのアプリケーションのパフォーマンスの最適化に関する次のような一般的な質問に答えるのに役立ちます。

  • アプリケーションのパフォーマンスはどのように測定するのか。
  • 予想される高パフォーマンスが得られないのはなぜか。
  • Premium Storage でアプリケーションのパフォーマンスに影響を及ぼすのはどの要素か。
  • 各要素は Premium Storage でアプリケーションのパフォーマンスにどのような影響を及ぼすのか。
  • IOPS、帯域幅、待機時間に最適化するにはどうすればよいか。

Premium Storage で実行されるワークロードは高パフォーマンスに依存するため、Premium Storage 専用のガイドラインを用意しました。 必要に応じて例も示しています。 これらのガイドラインの一部は、Standard Storage ディスクを使用する IaaS VM で実行されるアプリケーションにも適用できます。

Premium Storage の知識がない場合は、作業を始める前にまず、「高パフォーマンスの Premium Storage および Azure VM の非管理対象ディスクと管理ディスク」と「Azure Storage のスケーラビリティおよびパフォーマンスのターゲット」をお読みください。

アプリケーションのパフォーマンス指標

アプリケーションがユーザー要求を処理する速度、アプリケーションが要求ごとに処理するデータの量、アプリケーションが一定時間内に処理する要求の数、要求の送信後、応答が返されるまでのユーザーの待機時間などのパフォーマンス指標を使用して、アプリケーションが問題なく実行されているかどうかを評価します。 これらのパフォーマンス指標は、IOPS、スループットまたは帯域幅、待機時間という専門用語で表されます。

このセクションでは、Premium Storage のコンテキストでの一般的なパフォーマンス指標について説明します。 次の「アプリケーションのパフォーマンス要件の収集」では、アプリケーションのこれらのパフォーマンス指標を測定する方法について説明します。 「アプリケーションのパフォーマンスの最適化」の後半で、これらのパフォーマンス指標に影響する要素と、それらを最適化するための推奨事項について説明します。

IOPS

IOPS は、アプリケーションが 1 秒間にストレージ ディスクに送信する要求の数です。 入力/出力操作は読み取りまたは書き込みであり、順次の場合とランダムの場合があります。 オンライン小売 Web サイトのような OLTP アプリケーションでは、多数の同時ユーザー要求を即座に処理する必要があります。 これらのユーザー要求は、挿入と更新が集中的に行われるデータベース トランザクションであり、アプリケーションはこれらのトランザクションを迅速に処理する必要があります。 そのため、OLTP アプリケーションでは非常に高い IOPS が必要となります。 このようなアプリケーションは、数百万の小さなランダム IO 要求を処理します。 このようなアプリケーションを使用する場合は、IOPS に最適化するようにアプリケーション インフラストラクチャを設計する必要があります。 後述の「 アプリケーションのパフォーマンスの最適化」で、高 IOPS を実現するために考慮する必要があるすべての要素について詳しく説明します。

Premium Storage ディスクを高スケール VM に接続すると、そのディスクの仕様どおりに、保証された数の IOPS がプロビジョニングされます。 たとえば、P30 ディスクでは 5,000 IOPS がプロビジョニングされます。 また、高スケール VM の各サイズにも、維持できる IOPS の上限が設けられています。 たとえば、Standard GS5 VM の IOPS の上限は 80,000 です。

スループット

スループットまたは帯域幅は、アプリケーションが指定された期間にストレージ ディスクに送信するデータの量です。 アプリケーションが大きな IO ユニット サイズで入力/出力操作を実行する場合、高スループットが必要となります。 データ ウェアハウス アプリケーションは、一度にデータの大部分にアクセスするスキャン集中型の操作を発行する傾向があり、一般に一括操作を実行します。 つまり、このようなアプリケーションでは、スループットを高める必要があります。 このようなアプリケーションを使用する場合は、スループットに最適化するようにインフラストラクチャを設計する必要があります。 次のセクションで、これを実現するために調整する必要がある要素について詳しく説明します。

Premium Storage ディスクを高スケール VM に接続すると、そのディスクの仕様どおりにスループットがプロビジョニングされます。 たとえば、P30 ディスクでは 200 MB/秒のディスク スループットがプロビジョニングされます。 また、高スケール VM の各サイズにも、維持できるスループットの上限が設けられています。 たとえば、Standard GS5 VM の最大スループットは 2,000 MB/秒です。

スループットと IOPS の間には、次の式に示すような関係があります。

そのため、アプリケーションが必要とする最適なスループットと IOPS の値を特定することが重要です。 一方を最適化すると、もう一方も影響を受けます。 後述の「 アプリケーションのパフォーマンスの最適化」で、IOPS とスループットの最適化について詳しく説明します。

待機時間

待機時間は、アプリケーションが 1 つの要求を受信し、その要求をストレージ ディスクに送信して、クライアントに応答を送信するまでの所要時間です。 これは、IOPS とスループットに加え、アプリケーションのパフォーマンスの重要な評価基準となります。 Premium Storage ディスクの待機時間は、ディスクが要求の情報を取得し、それをアプリケーションに伝えるまでの所要時間です。 Premium Storage は、一貫した低待機時間を実現します。 Premium Storage ディスクの ReadOnly ホスト キャッシュを有効にすると、読み取り待機時間をさらに短縮できます。 ディスク キャッシュについては、後述の「 アプリケーションのパフォーマンスの最適化」で詳しく説明します。

IOPS とスループットを向上させるためにアプリケーションを最適化すると、アプリケーションの待機時間に影響します。 アプリケーションのパフォーマンスを調整したら、予期しない待機時間の長い動作を回避するために、アプリケーションの待機時間を必ず評価してください。

アプリケーションのパフォーマンス要件の収集

Azure Premium Storage で実行される高パフォーマンスのアプリケーションを設計するときには、まず、アプリケーションのパフォーマンス要件を把握します。 パフォーマンス要件を収集したら、最適なパフォーマンスを実現するためにアプリケーションを最適化できます。

前のセクションで、一般的なパフォーマンス指標、IOPS、スループット、待機時間について説明しました。 これらのパフォーマンス指標の中で、目的のユーザー エクスペリエンスを実現するためにアプリケーションに不可欠な指標を特定する必要があります。 たとえば、1 秒間に数百万のトランザクションを処理する OLTP アプリケーションでは、高 IOPS が最も重要となります。 一方、1 秒間に大量のデータを処理するデータ ウェアハウス アプリケーションでは、高スループットが重要となります。 ライブ ビデオ ストリーミング Web サイトのようなリアルタイム アプリケーションでは、待機時間がきわめて短いことが重要です。

次に、アプリケーションの有効期間全体にわたる最大パフォーマンス要件を評価します。 次のサンプル チェックリストを出発点として使用します。 通常時、ピーク時、時間外の各ワークロード期間の最大パフォーマンス要件を記録します。 すべてのワークロード レベルの要件を特定することで、アプリケーションの全体的なパフォーマンス要件を決定できるようになります。 たとえば、電子商取引 Web サイトの通常時のワークロードは、ほぼ毎日処理されるトランザクションです。 この Web サイトのピーク時のワークロードは、休暇シーズンや特売イベント中に処理されるトランザクションです。 通常、ピーク時のワークロードが発生するのは限られた期間ですが、アプリケーションで通常の操作を 2 倍以上に拡張することが必要になる可能性があります。 50 パーセンタイル、90 パーセンタイル、99 パーセンタイルの要件を確認します。 これにより、パフォーマンス要件のすべての外れ値を除外し、適切な値に最適化することに専念できます。

アプリケーションのパフォーマンス要件チェックリスト

パフォーマンス要件 50 パーセンタイル 90 パーセンタイル 99 パーセンタイル
最大で、基本および標準の動的ルーティング ゲートウェイでは合計 10 個の接続が可能です。 1 秒あたりのトランザクション数
% 読み取り操作
% 書き込み操作
% ランダム操作
% 順次操作
IO 要求サイズ
平均スループット
最大 スループット
最小 待機時間
平均待機時間
最大 CPU
平均 CPU
最大 メモリ
平均メモリ使用量
キューの深さ
注意

アプリケーションの予想される将来の成長に基づいて、これらの数値を調整することを検討する必要があります。 パフォーマンスを向上させるために、後でインフラストラクチャを変更するのは困難である可能性があるため、あらかじめ成長に向けた計画を立てることをお勧めします。

既存のアプリケーションを Premium Storage に移行する場合は、まず、そのアプリケーションについて上記のチェックリストを作成します。 次に、Premium Storage でアプリケーションのプロトタイプを作成し、このドキュメントで後述する「 アプリケーションのパフォーマンスの最適化 」に記載されているガイドラインに基づいてアプリケーションを設計します。 次のセクションで、パフォーマンスの測定値の収集に使用できるツールについて説明しています。

プロトタイプについて、既存のアプリケーションと同様のチェックリストを作成します。 ベンチマーク ツールを使用して、ワークロードをシミュレートし、プロトタイプ アプリケーションでパフォーマンスを測定します。 詳細については、「 ベンチマーク 」をご覧ください。 こうすることで、Premium Storage がアプリケーションのパフォーマンス要件に合っているか、上回っているかを判断できます。 その後、実稼働アプリケーションにも同じガイドラインを実装できます。

アプリケーションのパフォーマンス要件を評価するためのカウンター

アプリケーションのパフォーマンス要件を評価する最良の方法は、サーバーのオペレーティング システムによって提供されるパフォーマンス監視ツールを使用することです。 Windows では PerfMon、Linux では iostat を使用できます。 これらのツールでは、前のセクションで説明した各評価基準に対応するカウンターがキャプチャされます。 アプリケーションが通常時、ピーク時、時間外のワークロードを実行しているときに、これらのカウンターの値をキャプチャする必要があります。

PerfMon カウンターは、サーバーのプロセッサ、メモリ、各論理ディスクと物理ディスクに使用できます。 VM で Premium Storage ディスクを使用している場合、物理ディスク カウンターは各 Premium Storage ディスクを対象としており、論理ディスク カウンターは Premium Storage ディスクに作成された各ボリュームを対象としています。 アプリケーションのワークロードをホストするディスクの値をキャプチャする必要があります。 論理ディスクと物理ディスクの間に一対一のマッピングが存在する場合は、物理ディスク カウンターを参照できます。それ以外の場合は、論理ディスク カウンターを参照します。 Linux では、iostat コマンドによって、CPU とディスクの使用レポートが生成されます。 ディスク使用レポートには、物理デバイスまたはパーティションごとの統計が示されます。 データベース サーバーがデータとログに個別のディスクを使用している場合は、両方のディスクでこのデータを収集します。 次の表に、ディスク、プロセッサ、メモリのカウンターを示します。

カウンター Description PerfMon iostat
1 秒あたりの IOPS またはトランザクション数 1 秒あたりにストレージ ディスクに発行された I/O 要求の数。 Disk Reads/sec
Disk Writes/sec
tps
r/s
w/s
ディスク読み取り回数/書き込み回数 ディスク上で実行された読み取り操作と書き込み操作の割合。 % Disk Read Time
% Disk Write Time
r/s
w/s
スループット 1 秒あたりにディスクに対して読み書きされたデータの量。 Disk Read Bytes/sec
Disk Write Bytes/sec
kB_read/s
kB_wrtn/s
待機時間 ディスク IO 要求を完了するまでの合計時間。 Average Disk sec/Read
Average disk sec/Write
await
svctm
IO サイズ ストレージ ディスクに発行される I/O 要求のサイズ。 Average Disk Bytes/Read
Average Disk Bytes/Write
avgrq-sz
キューの深さ ストレージ ディスクに対して読み書きされるのを待機している未処理の I/O 要求の数。 現在のディスク キューの長さ avgqu-sz
最大メモリ アプリケーションをスムーズに実行するために必要なメモリ容量。 % Committed Bytes in Use Use vmstat
最大CPU アプリケーションをスムーズに実行するために必要な CPU 量。 % Processor time % 使用率

詳細については、「iostat」と「PerfMon」をご覧ください。

アプリケーションのパフォーマンスの最適化

Premium Storage で実行されるアプリケーションのパフォーマンスに影響を与える主な要素として、IO 要求の特性、VM サイズ、ディスク サイズ、ディスク数、ディスク キャッシュ、マルチスレッド、キューの深さがあります。 これらの要素の一部は、システムで提供されるノブを使用して制御できます。 ほとんどのアプリケーションでは、IO サイズとキューの深さを直接変更することはできません。 たとえば、SQL Server を使用している場合、IO サイズとキューの深さを選択することはできません。 SQL Server では、最大限のパフォーマンスを得るために、最適な IO サイズとキューの深さの値が選択されます。 パフォーマンスのニーズを満たす適切なリソースをプロビジョニングできるように、この 2 つの要素がアプリケーションのパフォーマンスに及ぼす影響を理解しておくことが重要です。

アプリケーションのパフォーマンスをどの程度最適化する必要があるかを明確にするために、このセクション全体を通じて、作成したアプリケーション要件チェックリストを参照します。 これを基に、このセクションの要素の中で、調整する必要がある要素を特定できるようになります。 アプリケーションのパフォーマンスに対する各要素の影響を監視するには、アプリケーションのセットアップでベンチマーク ツールを実行します。 Windows VM と Linux VM で一般的なベンチマーク ツールを実行する手順については、この記事の最後のセクションである「 ベンチマーク 」をご覧ください。

IOPS、スループット、待機時間の最適化の概要

次の表に、パフォーマンスのすべての要素と、IOPS、スループット、待機時間を最適化する手順の概要を示します。 この概要の後の各セクションで、それぞれの要素についてさらに詳しく説明します。

  IOPS スループット 待機時間
サンプル シナリオ 1 秒あたりに非常に多くのトランザクションを必要とするエンタープライズ OLTP アプリケーション。 大量のデータを処理するエンタープライズ データ ウェアハウス アプリケーション。 オンライン ゲームなど、ユーザー要求にすぐに応答する必要があるほぼリアルタイムのアプリケーション。
パフォーマンスの要素      
IO サイズ IO サイズが小さいほど、IOPS が向上します。 IO サイズが大きいほど、スループットが向上します。  
VM サイズ アプリケーションの要件よりも高い IOPS を提供する VM サイズを使用します。 VM サイズと IOPS の上限については、こちらをご覧ください。 スループットの上限がアプリケーションの要件よりも高い VM サイズを使用します。 VM サイズとスループットの上限については、こちらをご覧ください。 スケールの上限がアプリケーションの要件よりも高い VM サイズを使用します。 VM サイズと上限については、こちらをご覧ください。
ディスク サイズ アプリケーションの要件よりも高い IOPS を提供するディスク サイズを使用します。 ディスク サイズと IOPS の上限については、こちらをご覧ください。 スループットの上限がアプリケーションの要件よりも高いディスク サイズを使用します。 ディスク サイズとスループットの上限については、こちらをご覧ください。 スケールの上限がアプリケーションの要件よりも高いディスク サイズを使用します。 ディスク サイズと上限については、こちらをご覧ください。
VM とディスクのスケールの上限 選択した VM サイズの IOPS の上限が、VM に接続された Premium Storage ディスクによって引き上げられた総 IOPS を上回る必要があります。 選択した VM サイズのスループットの上限が、VM に接続された Premium Storage ディスクによって引き上げられた総スループットを上回る必要があります。 選択した VM サイズのスケールの上限が、接続された Premium Storage ディスクのスケールの上限の合計を上回る必要があります。
ディスク キャッシュ 読み取り IOPS を向上させるには、読み取り負荷の高い操作で、Premium Storage ディスクの ReadOnly キャッシュを有効にします。   読み取り待機時間を短縮するには、読み取り負荷の高い操作で、Premium Storage ディスクの ReadOnly キャッシュを有効にします。
ディスク ストライピング 複数のディスクを使用し、それらのディスクをストライピングすると、IOPS とスループットが集約され、上限が高くなります。 VM あたりの上限の合計が、接続された Premium ディスクの上限の合計を上回る必要があります。    
ストライプ サイズ OLTP アプリケーションで見られる小さなランダム IO パターンでは、ストライプ サイズを小さくします。 たとえば、SQL Server OLTP アプリケーションには、64KB のストライプ サイズを使用します。 データ ウェアハウス アプリケーションで見られる大きな順次 IO パターンでは、ストライプ サイズを大きくします。 たとえば、SQL Server データ ウェアハウス アプリケーションには、256 KB のストライプ サイズを使用します。  
マルチスレッド マルチスレッドを使用して、Premium Storage により多くの要求をプッシュすると、IOPS とスループットが向上します。 たとえば、SQL Server で大きい MAXDOP 値を設定して、より多くの CPU を SQL Server に割り当てます。    
キューの深さ キューの深さが大きいほど、IOPS が向上します。 キューの深さが大きいほど、スループットが向上します。 キューの深さが小さいほど、待機時間が短縮されます。

IO 要求の特性

IO 要求は、アプリケーションが実行する入力/出力操作の単位です。 IO 要求の特性 (ランダムまたは順次、読み取りまたは書き込み、サイズの大小) を特定すると、アプリケーションのパフォーマンス要件の決定に役立ちます。 アプリケーション インフラストラクチャの設計時に適切な判断を下すには、IO 要求の特性を理解することが非常に重要です。

IO サイズは、さらに重要な要素の 1 つです。 IO サイズは、アプリケーションによって生成される入力/出力操作の要求のサイズです。 IO サイズはパフォーマンスに影響を及ぼし、特にアプリケーションが実現できる IOPS と帯域幅に大きな影響を及ぼします。 次の式は、IOPS、IO サイズ、帯域幅/スループットの関係を示しています。

IO サイズを変更できるアプリケーションもあれば、変更できないアプリケーションもあります。 たとえば、SQL Server では最適な IO サイズが自動的に決定され、ユーザーがこれを変更することはできません。 一方、Oracle には、データベースの IO 要求サイズの構成に使用できる DB_BLOCK_SIZE というパラメーターが用意されています。

IO サイズを変更できないアプリケーションを使用している場合は、この記事のガイドラインを使用して、アプリケーションに最も関係するパフォーマンス KPI を最適化します。 たとえば、次のように入力します。

  • OLTP アプリケーションでは、数百万の小さなランダム IO 要求が生成されます。 この種の IO 要求を処理するには、IOPS が向上するようにアプリケーション インフラストラクチャを設計する必要があります。
  • データ ウェアハウス アプリケーションでは、大きな順次 IO 要求が生成されます。 この種の IO 要求を処理するには、帯域幅またはスループットが向上するようにアプリケーション インフラストラクチャを設計する必要があります。

IO サイズを変更できるアプリケーションを使用している場合は、他のパフォーマンス ガイドラインに加え、IO サイズの次の経験則を使用します。

  • IO サイズが小さいほど、IOPS が向上します。 たとえば、OLTP アプリケーションでは 8 KB にします。
  • IO サイズが大きいほど、帯域幅/スループットが向上します。 たとえば、データ ウェアハウス アプリケーションでは 1024 KB にします。

アプリケーションの IOPS とスループット/帯域幅の計算方法について、例を挙げて説明します。 P30 ディスクを使用するアプリケーションがあるとします。 P30 ディスクが実現できる最大 IOPS と最大スループット/帯域幅は、それぞれ 5,000 IOPS、200 MB/秒です。 アプリケーションに P30 ディスクの最大 IOPS が必要であり、8 KB のような小さい IO サイズを使用すると、40 MB/秒の帯域幅が得られます。 しかし、アプリケーションに P30 ディスクの最大スループット/帯域幅が必要であり、1024 KB のような大きい IO サイズを使用すると、IOPS は 200 IOPS に低下します。 そのため、アプリケーションの IOPS とスループット/帯域幅の両方の要件を満たすように IO サイズを調整します。 次の表に、さまざまな IO サイズと、P30 ディスクの対応する IOPS およびスループットを示します。

アプリケーションの要件 I/O サイズ IOPS スループット/帯域幅
最大 IOPS 8 KB 5,000 40 MB/秒
最大スループット 1024 KB 200 200 MB/秒
最大スループット + 高 IOPS 64 KB 3,200 200 MB/秒
最大 IOPS + 高スループット 32 KB 5,000 160 MB/秒

1 つの Premium Storage ディスクの最大値を超える IOPS と帯域幅を得るには、ストライピングされた複数の Premium ディスクを使用します。 たとえば、2 つの P30 ディスクをストライピングすると、10,000 IOPS の合計 IOPS または 400 MB/秒の合計スループットが得られます。 次のセクションで説明するように、ディスクの合計 IOPS と合計スループットをサポートする VM サイズを使用する必要があります。

注意

IOPS とスループットのいずれかを増やすと、もう一方も増加するので、どちらか一方を増やしたときには、ディスクまたは VM のスループットまたは IOPS の上限に達していないことを確認してください。

IO サイズがアプリケーションのパフォーマンスに及ぼす影響を監視するには、VM とディスクでベンチマーク ツールを実行します。 複数のテスト実行を作成し、実行ごとに異なる IO サイズを使用して影響を確認します。 詳細については、この記事の最後のセクションである「 ベンチマーク 」をご覧ください。

高スケール VM サイズ

アプリケーションの設計を始めるときに、最初に行うことの 1 つとして、アプリケーションをホストする VM の選択があります。 Premium Storage には、高いコンピューティング能力と高いローカル ディスク I/O パフォーマンスを必要とするアプリケーションを実行できる、高スケール VM サイズが用意されています。 これらの VM は、高速プロセッサ、高いメモリ対コア比、ローカル ディスク用ソリッド ステート ドライブ (SSD) を提供します。 Premium Storage をサポートする高スケール VM の例として、DS シリーズ VM、DSv2 シリーズ VM、GS シリーズ VM があります。

高スケール VM は、CPU コア数、メモリ容量、OS/一時ディスク サイズが異なるさまざまなサイズで提供されます。 各 VM サイズには、VM に接続できるデータ ディスクの最大数も設けられています。 そのため、選択した VM サイズは、アプリケーションで利用できる処理能力、メモリ容量、ストレージ容量に影響します。 また、計算およびストレージ コストにも影響します。 例として、DS シリーズ、DSv2 シリーズ、GS シリーズの最大 VM サイズの仕様を次に示します。

VM サイズ CPU コア数 メモリ VM のディスク サイズ 最大で、基本および標準の動的ルーティング ゲートウェイでは合計 10 個の接続が可能です。 データ ディスク キャッシュ サイズ IOPS 帯域幅キャッシュ IO の上限
Standard_DS14 16 112 GB OS = 1023 GB
ローカル SSD = 224 GB
32 576 GB 50,000 IOPS
512 MB/秒
4,000 IOPS、33 MB/秒
Standard_GS5 32 448 GB OS = 1023 GB
ローカル SSD = 896 GB
64 4224 GB 80,000 IOPS
2,000 MB/秒
5,000 IOPS、50 MB/秒

利用可能なすべての Azure VM サイズの一覧については、Windows VM のサイズLinux VM のサイズに関するページをご覧ください。 アプリケーションの目的のパフォーマンス要件を満たし、拡張できる VM サイズを選択します。 これに加え、VM サイズを選択するときは、次の重要な考慮事項に注意してください。

スケールの上限
IOPS の上限は、VM あたりとディスクあたりで異なり、互いに独立しています。 アプリケーションが、VM と VM に接続された Premium ディスクの制限の範囲内で IOPS を引き上げていることを確認します。 制限を超えると、アプリケーションのパフォーマンスが調整されます。

たとえば、アプリケーションの要件が最大 4,000 IOPS であるとします。 これを実現するために、DS1 VM に P30 ディスクをプロビジョニングします。 P30 ディスクは、最大 5,000 IOPS を実現できます。 ただし、DS1 VM は 3,200 IOPS に制限されています。 そのため、アプリケーションのパフォーマンスは、3,200 IOPS という VM の制限による制約を受けることになり、パフォーマンスが低下します。 このような状況を防ぐには、アプリケーションの要件を満たす VM サイズとディスク サイズを選択します。

運用コスト
多くの場合、Standard Storage を使用するよりも、Premium Storage を使用する方が全体的な運用コストが削減される可能性があります。

たとえば、16,000 IOPS を必要とするアプリケーションがあるとします。 このパフォーマンスを実現するには、Standard_D14 Azure IaaS VM が必要です。Standard_D14 Azure IaaS VM では、32 個の 1 TB Standard Storage ディスクを使用することで、最大 IOPS が 16,000 になります。 各 1 TB Standard Storage ディスクは、最大 500 IOPS を実現します。 この VM の推定月額料金は 1,570 ドルです。 32 個の Standard Storage ディスクの月額料金は 1,638 ドルです。 推定合計月額料金は 3,208 ドルになります。

しかし、Premium Storage で同じアプリケーションをホストした場合、必要な VM サイズが小さくなり、必要な Premium Storage ディスク数も減るので、全体的なコストが削減されます。 Standard_DS13 VM なら、4 つの P30 ディスクを使用して 16,000 IOPS の要件を満たすことができます。 DS13 VM の最大 IOPS は 25,600 であり、各 P30 ディスクの最大 IOPS は 5,000 です。 全体として、この構成では 5,000 x 4 = 20,000 IOPS を実現できます。 この VM の推定月額料金は 1,003 ドルです。 4 つの P30 Premium Storage ディスクの月額料金は 544.34 ドルです。 推定合計月額料金は 1,544 ドルになります。

次の表に、このシナリオの Standard Storage と Premium Storage のコストの内訳を示します。

  Standard Premium
VM の月額料金 1,570.58 ドル (Standard_D14) 1,003.66 ドル (Standard_DS13)
ディスクの月額料金 1,638.40 ドル (32 x 1 TB ディスク) 544.34 ドル (4 x P30 ディスク)
合計月額料金 3,208.98 ドル 1,544.34 ドル

Linux ディストリビューション

Azure Premium Storage を使用すると、Windows を実行する VM と Linux を実行する VM で同レベルのパフォーマンスが得られます。 さまざまな Linux ディストリビューションがサポートされています。リストについては、こちらをご覧ください。 ワークロードの種類によって、適しているディストリビューションが異なることに注意してください。 パフォーマンスのレベルは、ワークロードが実行されるディストリビューションによって異なります。 アプリケーションで Linux ディストリビューションをテストし、最適なディストリビューションを選択します。

Premium Storage で Linux を実行するときは、高パフォーマンスを確保するために、必要なドライバーについて最新の更新プログラムを確認してください。

Premium Storage のディスク サイズ

現在、Azure Premium Storage には 3 種類のディスク サイズが用意されています。 ディスク サイズによって、IOPS、帯域幅、ストレージのスケールの上限がそれぞれ異なります。 アプリケーションの要件と高スケール VM のサイズに応じて、Premium Storage の適切なディスク サイズを選択します。 次の表に、3 種類のディスク サイズとその機能を示します。

ディスクの種類 P10 P20 P30
ディスク サイズ 128 GiB 512 GiB 1024 GiB (1 TB)
ディスクあたりの IOPS 500 2300 5000
ディスクあたりのスループット 100 MB/秒 150 MB/秒 200 MB/秒

選択するディスク数は、選択したディスク サイズによって異なります。 1 つの P30 ディスクまたは複数の P10 ディスクを使用して、アプリケーションの要件を満たすことができます。 選択時には以下の考慮事項に注意してください。

スケールの上限 (IOPS とスループット)
IOPS とスループットの上限は、Premium ディスク サイズごとに異なり、VM のスケールの上限から独立しています。 ディスクの総 IOPS と総スループットが、選択した VM サイズのスケールの上限を超えていないことを確認します。

たとえば、アプリケーションの要件が最大 250 MB/秒のスループットであり、DS4 VM と 1 つの P30 ディスクを使用しているとします。 DS4 VM が提供できる最大スループットは 256 MB/秒です。 しかし、1 つの P30 ディスクのスループットの上限は 200 MB/秒です。 そのため、アプリケーションは 200 MB/秒というディスクの制限による制約を受けることになります。 この制限を克服するには、VM に複数のデータ ディスクをプロビジョニングします。

注意

キャッシュで処理される読み取りはディスクの IOPS とスループットに含まれないので、ディスクの制限の対象にはなりません。 キャッシュには、VM あたりの IOPS とスループットの別の上限が設けられています。

たとえば、最初は読み取りと書き込みがそれぞれ 60MB/秒と 40MB/秒であったとします。 時間が経つにつれて、キャッシュがウォームアップされ、処理されるキャッシュからの読み取りが増加します。 これにより、ディスクからの書き込みスループットが向上します。

ディスク数
アプリケーションの要件を評価して必要なディスク数を決定します。 各 VM サイズにも、VM に接続できるディスク数の上限が設けられています。 通常、これはコア数の 2 倍です。 選択した VM サイズが必要なディスク数をサポートできることを確認します。

Premium Storage ディスクは、Standard Storage ディスクよりも高いパフォーマンス機能を備えています。 そのため、Standard Storage を使用する Azure IaaS VM から Premium Storage にアプリケーションを移行する場合、アプリケーションの同等以上のパフォーマンスを実現するために必要な Premium ディスク数が減る可能性があります。

ディスク キャッシュ

Azure Premium Storage を利用する高スケール VM には、BlobCache と呼ばれる多層キャッシュ テクノロジがあります。 BlobCache では、仮想マシンの RAM とローカル SSD を組み合わせてキャッシュに使用します。 このキャッシュは、Premium Storage の永続ディスクと VM のローカル ディスクで使用できます。 既定では、このキャッシュは、OS ディスクでは Read/Write に設定され、Premium Storage でホストされるデータ ディスクでは ReadOnly に設定されます。 Premium Storage ディスクでディスク キャッシュを有効にすると、高スケール VM は基になるディスクのパフォーマンスを上回るきわめて高いレベルのパフォーマンスを実現できます。

警告

Azure ディスクのキャッシュ設定を変更すると、対象となるディスクをデタッチして再アタッチします。 オペレーティング システム ディスクの場合は、VM が再起動されます。 ディスク キャッシュの設定を変更する前に、この中断の影響を受ける可能性があるすべてのアプリケーションまたはサービスを停止します。

BlobCache の機能の詳細については、Inside の Azure Premium Storage に関するブログ記事をご覧ください。

適切なディスク セットでキャッシュを有効にすることが重要です。 Premium ディスクでディスク キャッシュを有効にするかどうかは、そのディスクで処理されるワークロードのパターンによって決まります。 次の表に、OS ディスクとデータ ディスクの既定のキャッシュ設定を示します。

ディスクの種類 既定のキャッシュ設定
OS ディスク ReadWrite
データ ディスク なし

データ ディスクの推奨されるディスク キャッシュ設定を次に示します。

ディスク キャッシュ設定 この設定を使用するときの推奨事項
なし 書き込み専用ディスクと書き込み負荷の高いディスクでは、ホスト キャッシュを None に構成します。
ReadOnly 読み取り専用ディスクと読み取り/書き込みディスクでは、ホスト キャッシュを ReadOnly に構成します。
ReadWrite アプリケーションが、必要に応じてキャッシュ データの永続ディスクへの書き込みを適切に処理できる場合にのみ、ホスト キャッシュを ReadWrite に構成します。

ReadOnly
Premium Storage データ ディスクの ReadOnly キャッシュを構成することで、読み取り待機時間を減らし、アプリケーションの読み取り IOPS と読み取りスループットを大幅に向上させることができます。 これは、次の 2 つの理由によります。

  1. VM のメモリおよびローカル SSD 上のキャッシュから実行される読み取りは、Azure BLOB ストレージ上のデータ ディスクからの読み取りよりもはるかに高速です。
  2. Premium Storage では、ディスクの IOPS とスループットのために、キャッシュからの読み取りはカウントされません。 そのため、アプリケーションは、総 IOPS と総スループットを向上させることができます。

ReadWrite
既定では、OS ディスクは ReadWrite キャッシュが有効になっています。 最近、データ ディスクでも ReadWrite キャッシュのサポートが追加されました。 ReadWrite キャッシュを使用する場合、データをキャッシュから永続ディスクに適切な方法で書き込む必要があります。 たとえば、SQL Server では、永続ストレージ ディスクへのキャッシュ データの書き込みを独自に処理します。 必要なデータの永続化を処理しないアプリケーションで ReadWrite キャッシュを使用すると、VM がクラッシュした場合にデータが失われる可能性があります。

たとえば、次の手順を実行することで、Premium Storage で実行されている SQL Server にこれらのガイドラインを適用できます。

  1. データ ファイルをホストする Premium Storage ディスクに "ReadOnly" キャッシュを構成します。
    a. データ ページをデータ ディスクから直接取得するよりも、キャッシュから取得する方がはるかに高速であるため、キャッシュからの高速読み取りによって、SQL Server のクエリ時間が短縮されます。
    b. キャッシュからの読み取りに対応すると、Premium データ ディスクで提供される追加のスループットが得られます。 SQL Server は、さらに多くのデータ ページの取得や、バックアップと復元、バッチ読み込み、インデックスの再構築などの他の操作のために、この追加のスループットを使用できます。
  2. ログ ファイルをホストする Premium Storage ディスクに "None" キャッシュを構成します。
    a. ログ ファイルの操作は、主に書き込み負荷の高い操作です。 そのため、ReadOnly キャッシュによるメリットはありません。

ディスク ストライピング

高スケール VM が Premium Storage の複数の永続ディスクに接続されている場合、ディスクをストライピングすることで、IOPS、帯域幅、ストレージ容量を集約できます。

Windows では、記憶域スペースを使用してディスクをストライピングできます。 プールのディスクごとに 1 つの列を構成する必要があります。 そうしないと、ディスク間でのトラフィックの分散が不均等になるため、ストライプ ボリュームの全体的なパフォーマンスが予想よりも低くなる可能性があります。

重要: サーバー マネージャーの UI を使用して、ストライプ ボリュームの列の総数を最大 8 列に設定できます。 8 個を超えるディスクを接続するときは、PowerShell を使用してボリュームを作成します。 PowerShell を使用すると、列数をディスクと同じ数に設定できます。 たとえば、1 つのストライプ セットに 16 個のディスクがある場合、New-VirtualDisk PowerShell コマンドレットの NumberOfColumns パラメーターで 16 列を指定します。

Linux では、MDADM ユーティリティを使用してディスクをストライピングします。 Linux でのディスク ストライピングの詳しい手順については、「 Linux でのソフトウェア RAID の構成」をご覧ください。

ストライプ サイズ
ディスク ストライピングの重要な構成の 1 つに、ストライプ サイズがあります。 ストライプ サイズ (ブロック サイズ) は、アプリケーションがストライプ ボリュームで対応できるデータの最小チャンクです。 構成するストライプ サイズは、アプリケーションの種類と要求パターンによって異なります。 間違ったストライプ サイズを選択すると、IO の不均衡が生じ、アプリケーションのパフォーマンスが低下する可能性があります。

たとえば、アプリケーションによって生成された IO 要求がディスクのストライプ サイズよりも大きい場合、ストレージ システムは、複数のディスクのストライプ ユニット境界にまたがって要求を書き込みます。 該当のデータにアクセスするときが来ると、要求を完了するために複数のストライプ ユニットにわたってシークしなければなりません。 このような動作の累積的影響により、パフォーマンスが大幅に低下する可能性があります。 一方、IO 要求サイズがストライプ サイズよりも小さい場合や、要求の特性がランダムの場合、IO 要求が同じディスクに追加されていく可能性があり、これがボトルネックとなって、最終的に IO パフォーマンスが低下することがあります。

アプリケーションが実行するワークロードの種類に応じて、適切なストライプ サイズを選択します。 小さなランダム IO 要求には、小さいストライプ サイズを使用します。 これに対して、大きな順次 IO 要求には、大きいストライプ サイズを使用します。 Premium Storage で実行するアプリケーションについて、ストライプ サイズの推奨事項を確認します。 SQL Server の場合、OLTP ワークロードには 64KB、データ ウェアハウス ワークロードには 256KB のストライプ サイズを構成します。 詳細については、「 Azure Virtual Machines における SQL Server のパフォーマンスに関するベスト プラクティス 」をご覧ください。

注意

ストライピングできる Premium Storage ディスクの最大数は、DS シリーズ VM では 32 個、GS シリーズ VM では 64 個です。

マルチスレッド

Azure では、超並列のプラットフォームとして Premium Storage が設計されました。 そのため、マルチスレッド アプリケーションは、シングルスレッド アプリケーションよりもはるかに高いパフォーマンスを実現します。 マルチスレッド アプリケーションでは、タスクを複数のスレッドに分割し、VM とディスクのリソースを最大限に活用することで実行効率を高めます。

たとえば、アプリケーションが 2 つのスレッドを使用して単一コアの VM で実行されている場合、CPU は 2 つのスレッドを切り替えて効率化できます。 一方のスレッドがディスク IO の完了を待機している間、CPU はもう一方のスレッドに切り替えることができます。 このようにして、2 つのスレッドは単一のスレッドよりも多くの処理を実行できます。 VM に複数のコアがある場合、各コアがタスクを並行して実行できるので、実行時間がさらに短縮されます。

市販のアプリケーションでは、シングルスレッドまたはマルチスレッドの実装方法を変更できないことがあります。 たとえば、SQL Server はマルチ CPU とマルチコアに対応できます。 ただし、クエリを処理するときに、どのような条件下で 1 つまたは複数のスレッドを利用するかは SQL Server が決定します。 SQL Server は、マルチスレッドを使用してクエリを実行し、インデックスを構築できます。 クエリで大規模なテーブルを結合し、データをユーザーに返す前に並べ替える必要がある場合、SQL Server は複数のスレッドを使用すると考えられます。 ただし、SQL Server がクエリを実行する際に単一のスレッドと複数のスレッドのどちらを使用するかをユーザーが制御することはできません。

アプリケーションのこのマルチスレッド (並列処理) に影響を与える変更可能な構成設定があります。 たとえば、SQL Server の場合、"並列処理の最大限度" 構成がこれに該当します。 MAXDOP と呼ばれるこの設定では、SQL Server が並列処理時に使用できるプロセッサの最大数を構成できます。 個々のクエリやインデックス操作の MAXDOP を構成できます。 これは、パフォーマンス クリティカルなアプリケーションのためにシステムのリソースのバランスをとる場合に役立ちます。

たとえば、SQL Server を使用するアプリケーションが、大規模なクエリとインデックス操作を同時に実行しているとします。 大規模なクエリよりも、インデックス操作のパフォーマンスを高める必要があると仮定します。 このような場合、インデックス操作の MAXDOP 値を、クエリの MAXDOP 値よりも大きい値に設定します。 これにより、SQL Server は大規模なクエリに割り当てることができるプロセッサよりも多くのプロセッサをインデックス操作に利用できます。 SQL Server が各操作に使用するスレッドの数を制御するわけではないことに注意してください。 制御できるのは、マルチスレッド専用のプロセッサの最大数です。

SQL Server の 並列処理の次数 の詳細をご覧ください。 アプリケーションのマルチスレッドに影響を与えるこのような設定とパフォーマンスを最適化する構成を確認してください。

キューの深さ

キューの深さ (キューの長さまたはキューのサイズ) は、システムで保留中の IO 要求の数です。 キューの深さの値によって、アプリケーションが準備できる IO 操作の数が決まります。IO 操作はストレージ ディスクによって処理されます。 これは、この記事で説明したアプリケーションの 3 つのパフォーマンス指標 (IOPS、スループット、待機時間) のすべてに影響します。

キューの深さとマルチスレッドは密接に関係しています。 キューの深さの値は、アプリケーションがどの程度のマルチスレッドを実現できるかを示します。 キューの深さが大きい場合、アプリケーションはより多くの操作を同時に実行できます。つまり、マルチスレッドのスレッド数が多いということです。 キューの深さが小さい場合、アプリケーションは、マルチスレッド化されていても、同時実行できるだけの十分な数の要求を準備できなくなります。

通常、市販のアプリケーションでは、キューの深さを変更することはできません。これは、キューの深さが正しく設定されていないと、メリットよりもデメリットの方が大きくなるからです。 最適なパフォーマンスを得るために、アプリケーションによってキューの深さの適切な値が設定されます。 ただし、アプリケーションで発生するパフォーマンスの問題をトラブルシューティングできるように、この概念を理解しておくことが重要です。 また、システムでベンチマーク ツールを実行することによって、キューの深さの影響を確認できます。

一部のアプリケーションには、キューの深さに影響を与える設定が用意されています。 例として、前のセクションで説明した SQL Server の MAXDOP (並列処理の最大限度) 設定が挙げられます。 MAXDOP は、SQL Server のキューの深さの値を直接変更するわけではありませんが、キューの深さとマルチスレッドに影響を及ぼします。

大きなキューの深さ
キューの深さが大きい場合、ディスク上での操作が増えます。 ディスクは、キューにある次の要求を事前に認識します。 そのため、ディスクは操作を事前にスケジュールし、最適な順序で操作を処理できます。 アプリケーションがディスクに送信する要求が増えるので、ディスクはより多くの並列 IO を処理できます。 最終的に、アプリケーションは IOPS を向上させることができます。 アプリケーションが処理する要求が増えるので、アプリケーションの総スループットも向上します。

通常、アプリケーションは、接続されたディスクごとに 8 ~ 16 個以上の未処理の IO がある状態のときに最大スループットを実現できます。 キューの深さが 1 の場合、アプリケーションはシステムに十分な数の IO をプッシュしなくなり、一定期間の処理量が減少します。 つまり、スループットが低下します。

たとえば、SQL Server でクエリの MAXDOP 値を "4" に設定すると、クエリの実行に最大 4 つのコアを使用できることが SQL Server に通知されます。 SQL Server は、クエリの実行に最適なキューの深さの値とコア数を決定します。

**
キューの深さの値が非常に大きい場合、欠点もあります。 キューの深さの値が大きすぎると、アプリケーションは IOPS を大幅に引き上げようとします。 IOPS が十分にプロビジョニングされた永続ディスクをアプリケーションが使用できる場合を除き、これはアプリケーションの待機時間に悪影響を及ぼす可能性があります。 次の式は、IOPS、待機時間、キューの深さの関係を示しています。

キューの深さを大きな値に構成するのではなく、待機時間に影響を及ぼさずにアプリケーションに十分な IOPS を提供できる最適な値に構成します。 たとえば、アプリケーションの待機時間を 1 ミリ秒にする必要がある場合、5,000 IOPS を実現するために必要なキューの深さは、QD = 5000 x 0.001 = 5 になります。

ストライプ ボリュームのキューの深さ
ストライプ ボリュームの場合、すべてのディスクのキューの深さがそれぞれピーク時のキューの深さになるように、十分なキューの深さを維持します。 たとえば、キューの深さ 2 をプッシュするアプリケーションがあり、ストライプに 4 つのディスクがあるとします。 2 つの IO 要求が 2 つのディスクに送信されると、残りの 2 つのディスクはアイドル状態になります。 そのため、すべてのディスクがビジー状態になるようにキューの深さを構成します。 次の式は、ストライプ ボリュームのキューの深さを決定する方法を示しています。

調整

Azure Premium Storage では、選択された VM サイズとディスク サイズに応じて、指定された数の IOPS とスループットがプロビジョニングされます。 アプリケーションが、VM またはディスクが対応できるこれらの上限を超えて IOPS やスループットを引き上げようとすると、これを抑制するように調整されます。 これは、アプリケーションのパフォーマンスの低下という形で現れます。 これにより、待機時間が長くなり、スループットや IOPS が低下する可能性があります。 Premium Storage によって調整が行われないと、リソースが対応できる範囲を上回り、アプリケーションが完全に失敗する可能性があります。 そのため、調整によるパフォーマンスの問題を回避するために、常にアプリケーションの十分なリソースをプロビジョニングします。 前の VM サイズとディスク サイズのセクションで説明した考慮事項に注意してください。 ベンチマークは、アプリケーションをホストするために必要なリソースを把握するための最適な方法です。

ベンチマーク

ベンチマークは、アプリケーションのさまざまなワークロードをシミュレートし、ワークロードごとにアプリケーションのパフォーマンスを測定するプロセスです。 以前に説明した手順を使用して、アプリケーションのパフォーマンス要件を収集しました。 アプリケーションをホストする VM でベンチマーク ツールを実行することで、アプリケーションが Premium Storage を使用して実現できるパフォーマンス レベルを確認できます。 このセクションでは、Azure Premium Storage ディスクと共にプロビジョニングされた Standard DS14 VM のベンチマークの例を示します。

一般的なベンチマーク ツールである Iometer (Windows) と FIO (Linux) を使用しました。 これらのツールは、ワークロードのような実稼働をシミュレートする複数のスレッドを起動し、システム パフォーマンスを測定します。 これらのツールを使用して、通常はアプリケーションに合わせて変更できないブロック サイズやキューの深さなどのパラメーターを構成することもできます。 これにより、さまざま種類のアプリケーション ワークロードに対応するために、Premium ディスクと共にプロビジョニングされた高スケール VM でパフォーマンスを最大限に引き上げる柔軟性が得られます。 各ベンチマーク ツールの詳細については、「Iometer」と「fio」をご覧ください。

以下の例に従うために、Standard DS14 VM を作成し、11 個の Premium Storage ディスクを VM に接続します。 11 個のディスクのうち、10 個のディスクのホスト キャッシュを "None" に構成し、これらのディスクを NoCacheWrites というボリュームにストライピングします。 残りのディスクでは、ホストキャッシュを "ReadOnly" に構成し、このディスクを使用して CacheReads というボリュームを作成します。 この設定を使用して、Standard DS14 VM から最大の読み取り/書き込みパフォーマンスが得られます。 Premium ディスクを使用する DS14 VM の詳しい作成手順については、「仮想マシンのデータ ディスク用に Premium Storage アカウントを作成する」をご覧ください。

キャッシュのウォームアップ
ReadOnly ホスト キャッシュを使用するディスクでは、ディスクの制限を超えた高 IOPS を実現できます。 ホスト キャッシュからこの最大の読み取りパフォーマンスを得るには、まず、このディスクのキャッシュをウォームアップする必要があります。 これにより、ベンチマーク ツールが CacheReads ボリュームで促進する読み取り IO が、直接ディスクにヒットするのではなく、実際にキャッシュにヒットするようになります。 キャッシュ ヒットにより、キャッシュが有効化された 1 つのディスクから追加の IOPS が得られます。

重要:
VM を再起動するたびに、キャッシュをウォームアップしてからベンチマークを実行する必要があります。

Iometer

Iometer ツールをダウンロード します。

テスト ファイル
Iometer では、ベンチマーク テストを実行するボリュームに格納されたテスト ファイルを使用します。 Iometer は、このテスト ファイルでの読み取りと書き込みを促進して、ディスクの IOPS とスループットを測定します。 このテスト ファイルを用意していない場合は、Iometer によって作成されます。 CacheReads ボリュームと NoCacheWrites ボリュームに iobw.tst という名前の 200 GB のテスト ファイルを作成します。

アクセス仕様
IO 要求サイズ、% 読み取り/書き込み、% ランダム/順次の各仕様は、Iometer の [Access Specifications] タブを使用して構成します。 以下に示すシナリオごとにアクセス仕様を作成します。 アクセス仕様を作成したら、適切な名前 (例: RandomWrites_8K、RandomReads_8K) を付けて保存します。 テスト シナリオを実行するときに、対応する仕様を選択します。

最大書き込み IOPS シナリオのアクセス仕様の例を次に示します。

最大 IOPS テストの仕様
最大 IOPS に達するように、小さな要求サイズを使用します。 8K の要求サイズを使用し、ランダム書き込み/読み取りの仕様を作成します。

アクセス仕様 要求サイズ ランダム % 読み取り %
RandomWrites_8 K 8 K 100 0
RandomReads_8 K 8 K 100 100

最大スループット テストの仕様
最大スループットに達するように、大きな要求サイズを使用します。 64K の要求サイズを使用し、ランダム書き込み/読み取りの仕様を作成します。

アクセス仕様 要求サイズ ランダム % 読み取り %
RandomWrites_64 K 64 K 100 0
RandomReads_64 K 64 K 100 100

Iometer テストの実行
次の手順を実行して、キャッシュをウォームアップします。

  1. 次に示す値を使用して、2 つのアクセス仕様を作成します。

    名前 要求サイズ ランダム % 読み取り %
    RandomWrites_1 MB 1 MB 100 0
    RandomReads_1 MB 1 MB 100 100
  2. 次のパラメーターを使用して、キャッシュ ディスクの初期化の Iometer テストを実行します。 ターゲット ボリュームに 3 つのワーカー スレッドを使用し、キューの深さとして 128 を使用します。 [Test Setup] タブでテストの [Run time] を 2 時間に設定します。

    シナリオ ターゲット ボリューム 名前 時間
    キャッシュ ディスクの初期化 CacheReads RandomWrites_1 MB 2 時間
  3. 次のパラメーターを使用して、キャッシュ ディスクのウォームアップの Iometer テストを実行します。 ターゲット ボリュームに 3 つのワーカー スレッドを使用し、キューの深さとして 128 を使用します。 [Test Setup] タブでテストの [Run time] を 2 時間に設定します。

    シナリオ ターゲット ボリューム 名前 時間
    キャッシュ ディスクのウォームアップ CacheReads RandomReads_1 MB 2 時間

キャッシュ ディスクをウォームアップしたら、下記のテスト シナリオを実行します。 Iometer テストを実行するために、ターゲット ボリューム ごとに 3 つ以上のワーカー スレッドを使用します。 次の表に従って、ワーカー スレッドごとに、ターゲット ボリュームを選択してキューの深さを設定し、保存済みのテストの仕様のいずれかを選択して、対応するテスト シナリオを実行します。 表では、各テストを実行したときの IOPS とスループットの予想される結果も示しています。 すべてのシナリオで、8KB の小さな IO サイズと 128 の大きなキューの深さが使用されます。

テスト シナリオ ターゲット ボリューム 名前 結果
最大 読み取り IOPS CacheReads RandomWrites_8 K 50,000 IOPS
最大 書き込み IOPS NoCacheWrites RandomReads_8 K 64,000 IOPS
最大 合計 IOPS CacheReads RandomWrites_8 K 100,000 IOPS
NoCacheWrites RandomReads_8 K    
最大で、基本および標準の動的ルーティング ゲートウェイでは合計 10 個の接続が可能です。 読み取り MB/秒 CacheReads RandomWrites_64 K 524 MB/秒
最大 書き込み MB/秒 NoCacheWrites RandomReads_64 K 524 MB/秒
合計 MB/秒 CacheReads RandomWrites_64 K 1000 MB/秒
NoCacheWrites RandomReads_64 K    

次のスクリーンショットは、合計 IOPS と合計スループットのシナリオでの Iometer テストの結果を示しています。

読み取りと書き込みの合計最大 IOPS

読み取りと書き込みの合計最大スループット

fio

FIO は、Linux VM でストレージのベンチマークを実行する一般的なツールです。 FIO では、さまざまな IO サイズ、順次読み取り/書き込み、ランダム読み取り/書き込みを柔軟に選択できます。 FIO は、ワーカー スレッドまたはワーカー プロセスを起動して、指定された I/O 操作を実行します。 各ワーカー スレッドがジョブ ファイルを使用して実行する必要がある I/O 操作の種類を指定できます。 以下の例に示すシナリオごとに、ジョブ ファイルを 1 つ作成しました。 これらのジョブ ファイルで仕様を変更して、Premium Storage で実行されるさまざまなワークロードのベンチマークを実行できます。 各例では、 Ubuntuを実行する Standard DS 14 VM を使用しています。 「 ベンチマーク 」の最初に記載されている設定を使用し、ベンチマーク テストを実行する前にキャッシュをウォームアップします。

開始する前に、 FIO をダウンロード し、仮想マシンにインストールします。

Ubuntu に対して次のコマンドを実行します。

apt-get install fio

ディスクでの書き込み操作を促進するための 4 つのワーカー スレッドと、読み取り操作を促進するための 4 つのワーカー スレッドを使用します。 書き込みワーカーは、キャッシュが "None" に設定された 10 個のディスクを含む "nocache" ボリュームのトラフィックを促進します。 読み取りワーカーは、キャッシュが "ReadOnly" に設定された 1 つのディスクを含む "readcache" ボリュームのトラフィックを促進します。

最大書き込み IOPS
最大書き込み IOPS を得るために、次の仕様でジョブ ファイルを作成します。 ファイル名を "fiowrite.ini" にします。

[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=8k

[writer1]
rw=randwrite
directory=/mnt/nocache
[writer2]
rw=randwrite
directory=/mnt/nocache
[writer3]
rw=randwrite
directory=/mnt/nocache
[writer4]
rw=randwrite
directory=/mnt/nocache

これまでのセクションで説明した設計ガイドラインに沿った次の重要事項に注意してください。 IOPS を最大限に高めるために、これらの仕様が不可欠となります。

  • 256 の大きなキューの深さ。
  • 8KB の小さなブロック サイズ。
  • ランダム書き込みを実行する複数のスレッド。

次のコマンドを実行して、FIO テストを 30 秒間実行します。

sudo fio --runtime 30 fiowrite.ini

テストの実行中、VM と Premium ディスクが提供している書き込み IOPS の数を確認できます。 次のサンプルに示すように、DS14 VM は書き込み IOPS の上限である 50,000 IOPS を実現しています。

最大読み取り IOPS
最大読み取り IOPS を得るために、次の仕様でジョブ ファイルを作成します。 ファイル名を "fioread.ini" にします。

[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=8k

[reader1]
rw=randread
directory=/mnt/readcache
[reader2]
rw=randread
directory=/mnt/readcache
[reader3]
rw=randread
directory=/mnt/readcache
[reader4]
rw=randread
directory=/mnt/readcache

これまでのセクションで説明した設計ガイドラインに沿った次の重要事項に注意してください。 IOPS を最大限に高めるために、これらの仕様が不可欠となります。

  • 256 の大きなキューの深さ。
  • 8KB の小さなブロック サイズ。
  • ランダム書き込みを実行する複数のスレッド。

次のコマンドを実行して、FIO テストを 30 秒間実行します。

sudo fio --runtime 30 fioread.ini

テストの実行中、VM と Premium ディスクが提供している読み取り IOPS の数を確認できます。 次のサンプルに示すように、DS14 VM は 64,000 を超える読み取り IOPS を実現しています。 これは、ディスクとキャッシュのパフォーマンスの合計です。

最大読み取り/書き込み IOPS
読み取りと書き込みの最大合計 IOPS を得るために、次の仕様でジョブ ファイルを作成します。 ファイル名を "fioreadwrite.ini" にします。

[global]
size=30g
direct=1
iodepth=128
ioengine=libaio
bs=4k

[reader1]
rw=randread
directory=/mnt/readcache
[reader2]
rw=randread
directory=/mnt/readcache
[reader3]
rw=randread
directory=/mnt/readcache
[reader4]
rw=randread
directory=/mnt/readcache

[writer1]
rw=randwrite
directory=/mnt/nocache
rate_iops=12500
[writer2]
rw=randwrite
directory=/mnt/nocache
rate_iops=12500
[writer3]
rw=randwrite
directory=/mnt/nocache
rate_iops=12500
[writer4]
rw=randwrite
directory=/mnt/nocache
rate_iops=12500

これまでのセクションで説明した設計ガイドラインに沿った次の重要事項に注意してください。 IOPS を最大限に高めるために、これらの仕様が不可欠となります。

  • 128 の大きなキューの深さ。
  • 4KB の小さなブロック サイズ。
  • ランダム読み取り/書き込みを実行する複数のスレッド。

次のコマンドを実行して、FIO テストを 30 秒間実行します。

sudo fio --runtime 30 fioreadwrite.ini

テストの実行中、VM と Premium ディスクが提供している読み取りと書き込みの合計 IOPS を確認できます。 次のサンプルに示すように、DS14 VM は 100,000 を超える読み取りと書き込みの合計 IOPS を実現しています。 これは、ディスクとキャッシュのパフォーマンスの合計です。

**
読み取りと書き込みの最大合計スループットを得るには、大きなブロック サイズ、大きなキューの深さ、読み取り/書き込みを実行する複数のスレッドを使用します。 ブロック サイズとして 64KB、キューの深さとして 128 を使用します。

次のステップ

Azure Premium Storage の詳細については、次の記事をご覧ください。

SQL Server ユーザーは、SQL Server のパフォーマンスのベスト プラクティスに関する次の記事をご覧ください。