Azure Premium Storage: ハイ パフォーマンス用に設計する
適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ 均一スケール セット
この記事では、Azure Premium Storage を使用して高パフォーマンスのアプリケーションを構築するためのガイドラインを示します。 このドキュメントで説明する手順は、アプリケーションで使用されているテクノロジに適用できるパフォーマンスのベスト プラクティスと組み合わせて使用できます。 ガイドラインを示すために、このドキュメント全体を通じて、Premium Storage で実行されている SQL Server を例として使用しています。
この記事では、ストレージ層のパフォーマンスのシナリオに対処していますが、アプリケーション層を最適化する必要があります。 たとえば、Premium Storage で SharePoint ファームをホストしている場合は、この記事の SQL Server の例を使用してデータベース サーバーを最適化できます。 また、最大限のパフォーマンスを得るために、SharePoint ファームの Web サーバーとアプリケーション サーバーを最適化できます。
この記事は、Premium Storage でのアプリケーションのパフォーマンスの最適化に関する次のような一般的な質問に答えるのに役立ちます。
- アプリケーションのパフォーマンスはどのように測定できるのか。
- 予想されるハイ パフォーマンスが得られないのはなぜか。
- Premium Storage でアプリケーションのパフォーマンスに影響を及ぼすのはどの要素か。
- 各要素は Premium Storage でアプリケーションのパフォーマンスにどのような影響を及ぼすのか。
- 1 秒あたりの入出力操作 (IOPS)、帯域幅、待ち時間はどのように最適化できるのか。
Premium Storage で実行されるワークロードは高パフォーマンスに依存するため、Premium Storage 専用のガイドラインが用意されています。 必要に応じて例も示します。 これらのガイドラインの一部は、Standard Storage ディスクを使用するサービスとしてのインフラストラクチャ (IaaS) VM で実行されるアプリケーションにも適用できます。
Note
ときには、ディスク パフォーマンスの問題のように見えるものが、実際にはネットワークのボトルネックであることもあります。 このような場合は、ネットワーク パフォーマンスを最適化する必要があります。
ディスクのベンチマークの実行を検討している場合は、次の記事を参照してください。
- Linux の場合:Azure Disk Storage 上のアプリケーションのベンチマーク
- Windows の場合: ディスクのベンチマークの実行
VM で高速ネットワークがサポートされる場合は、それが有効になっていることを確認してください。 有効になっていない場合は、Windows と Linux の両方で、既にデプロイされている VM 上で有効にすることができます。
Premium Storage を初めてご使用になる場合は、作業を始める前に、まず IaaS VM 用の Azure ディスクの種類の選択に関する記事と、Premium ページ BLOB ストレージ アカウントのスケーラビリティ ターゲットに関する記事をお読みください。
アプリケーションのパフォーマンス指標
Microsoft では、次のような業績評価指標を使用して、アプリケーションが問題なく実行されているかどうかを評価します。
- アプリケーションがユーザー要求を処理する速度。
- 要求ごとにアプリケーションが処理するデータ量。
- 特定の期間にアプリケーションが処理する要求数。
- ユーザーが要求を送信してから、応答を得るまでの待機時間。
これらのパフォーマンス指標は、IOPS、スループットまたは帯域幅、待機時間という専門用語で表されます。
このセクションでは、Premium Storage のコンテキストでの一般的なパフォーマンス指標について説明します。 「ディスクのパフォーマンス アプリケーション チェックリスト」セクションでは、アプリケーションのパフォーマンス指標を測定する方法について説明します。 「アプリケーションのパフォーマンスの最適化」の後半で、これらのパフォーマンス指標に影響する要素と、それらを最適化するための推奨事項について説明します。
IOPS
IOPS は、アプリケーションが 1 秒間にストレージ ディスクに送信する要求の数です。 入力/出力操作は読み取りまたは書き込みであり、順次の場合とランダムの場合があります。 オンライン小売 Web サイトのようなオンライン トランザクション処理 (OLTP) アプリケーションでは、多数の同時ユーザー要求を即座に処理する必要があります。 これらのユーザー要求は、挿入と更新が集中的に行われるデータベース トランザクションであり、アプリケーションはこれらのトランザクションを迅速に処理する必要があります。 このため、OLTP アプリケーションでは非常に高い IOPS が必要となります。
OLTP アプリケーションは、数百万の小さなランダム I/O 要求を処理します。 このようなアプリケーションを使用する場合は、IOPS に最適化するようにアプリケーション インフラストラクチャを設計する必要があります。 高 IOPS を得るために考慮すべきすべての要因の詳細については、「アプリケーションのパフォーマンスの最適化」を参照してください。
Premium Storage ディスクを高スケール VM に接続すると、そのディスクの仕様どおりに保証された数の IOPS がプロビジョニングされます。 たとえば、P50 ディスクでは 7,500 IOPS がプロビジョニングされます。 また、高スケール VM の各サイズにも、維持できる IOPS の上限が設けられています。 たとえば、Standard GS5 VM の上限は 80,000 IOPS です。
スループット
スループットまたは帯域幅は、アプリケーションが指定された期間にストレージ ディスクに送信するデータの量です。 アプリケーションが大きな I/O ユニット サイズで入力/出力操作を実行する場合、高スループットが必要となります。 データ ウェアハウス アプリケーションは、一度にデータの大部分にアクセスするスキャン集中型の操作を発行する傾向があり、一般に一括操作を実行します。 つまり、このようなアプリケーションでは、スループットを高める必要があります。 このようなアプリケーションを使用する場合は、スループットに最適化するようにインフラストラクチャを設計する必要があります。 次のセクションで、この最適化を実現するために調整する必要がある要素について説明します。
Premium Storage ディスクを高スケール VM に接続すると、そのディスクの仕様どおりにスループットがプロビジョニングされます。 たとえば、P50 ディスクでは 250 MB/秒のディスク スループットがプロビジョニングされます。 また、高スケール VM の各サイズにも、維持できるスループットの上限が設けられています。 たとえば、Standard GS5 VM の最大スループットは 2,000 MB/秒です。
スループットと IOPS の間には、次の式に示すような関係があります。
アプリケーションが必要とする最適なスループットと IOPS の値を特定することが重要です。 一方を最適化すると、もう一方も影響を受けます。 IOPS とスループットの最適化に関する詳細については、「アプリケーションのパフォーマンスの最適化」を参照してください。
Latency
待機時間は、アプリケーションが 1 つの要求を受信し、その要求をストレージ ディスクに送信して、クライアントに応答を送信するまでの所要時間です。 待機時間は、IOPS とスループットに加え、アプリケーションのパフォーマンスの重要な評価基準となります。 Premium Storage ディスクの待機時間は、ディスクが要求の情報を取得し、それをアプリケーションに伝えるまでの所要時間です。 Premium Storage は、一貫した低待機時間を実現します。 Premium ディスクは、ほとんどの I/O 操作で待ち時間が 10 ミリ秒未満となるように設計されています。 Premium Storage ディスクの ReadOnly ホスト キャッシュを有効にすると、読み取り待機時間をさらに短縮できます。 ディスク キャッシュの詳細については、「ディスク キャッシュ」を参照してください。
IOPS とスループットを向上させるためにアプリケーションを最適化すると、アプリケーションの待機時間に影響します。 アプリケーションのパフォーマンスを調整したら、予期しない待機時間の長い動作を回避するために、アプリケーションの待機時間を必ず評価してください。
マネージド ディスクに対する一部のコントロール プレーン操作は、ディスクをある保存場所から別の場所へ移動させる場合があります。 保存場所間でのディスクの移動は、データのバックグラウンド コピーを使って調整され、完了するまでに数時間かかる場合があります。 この時間は、ディスクのデータ量にもよりますが、通常は 24 時間以内です。 一部の読み取りが元の場所にリダイレクトされ、完了までにより長い時間がかかるため、その間、お使いのアプリケーションでは読み取りの待機時間が通常よりも長くなる可能性があります。
バックグラウンド コピー中は、ほとんどの種類のディスクの書き込み待機時間に影響は出ません。 Premium SSD v2 および Ultra Disks の場合、ディスクのセクター サイズが 4k の場合、読み取り待機時間が長くなります。 ディスクのセクター サイズが 512e の場合、読み取りと書き込みの待機時間が長くなります。
次のコントロール プレーン操作では、保存場所間でディスクが移動され、待機時間が長くなる可能性があります。
- ストレージの種類を更新する
- ある VM からディスクをデタッチし、別の VM にアタッチする
- VHD からマネージド ディスクを作成する
- スナップショットからマネージド ディスクを作成する
- アンマネージド ディスクをマネージド ディスクに変換する
ディスクのパフォーマンス アプリケーション チェックリスト
Premium Storage で実行される高パフォーマンスのアプリケーションを設計するときには、まず、アプリケーションのパフォーマンス要件を把握します。 パフォーマンス要件を収集したら、最適なパフォーマンスを実現するためにアプリケーションを最適化できます。
前のセクションで、一般的なパフォーマンス指標、IOPS、スループット、待機時間について説明しました。 これらのパフォーマンス指標の中で、目的のユーザー エクスペリエンスを実現するためにアプリケーションに不可欠な指標を特定する必要があります。 たとえば、1 秒間に数百万のトランザクションを処理する OLTP アプリケーションでは、高 IOPS が最も重要となります。 1 秒間に大量のデータを処理するデータ ウェアハウス アプリケーションでは、高スループットが重要となります。 ライブ ビデオ ストリーミング Web サイトのようなリアルタイム アプリケーションでは、待機時間がきわめて短いことが重要です。
次に、アプリケーションの有効期間全体にわたる最大パフォーマンス要件を評価します。 開始時には、次のチェックリストのサンプルを使用してください。 通常時、ピーク時、時間外の各ワークロード期間の最大パフォーマンス要件を記録します。 すべてのワークロード レベルの要件を特定することで、アプリケーションの全体的なパフォーマンス要件を決定できます。
たとえば、電子商取引 Web サイトの通常時のワークロードは、ほぼ毎日処理されるトランザクションです。 この Web サイトのピーク時のワークロードは、休暇シーズンや特売イベント中に処理されるトランザクションです。 通常、ピーク時のワークロードが発生するのは限られた期間ですが、アプリケーションで通常の操作を 2 倍以上に拡張することが必要になる可能性があります。 50 パーセンタイル、90 パーセンタイル、99 パーセンタイルの要件を確認します。 この情報により、パフォーマンス要件のすべての外れ値を除外し、適切な値に最適化することに専念できます。
アプリケーションのパフォーマンス要件チェックリスト
| パフォーマンス要件 | 50 パーセンタイル | 90 パーセンタイル | 99 パーセンタイル |
|---|---|---|---|
| 1 秒あたりの最大トランザクション数 | |||
| % 読み取り操作 | |||
| % 書き込み操作 | |||
| % ランダム操作 | |||
| % 順次操作 | |||
| I/O 要求サイズ | |||
| 平均スループット | |||
| 最大スループット | |||
| 最小待機時間 | |||
| 平均待機時間 | |||
| 最大 CPU | |||
| 平均 CPU | |||
| 最大メモリ | |||
| 平均メモリ | |||
| キュー深度 |
Note
アプリケーションの予想される将来の成長に基づいて、これらの数値を調整することを検討してください。 パフォーマンスを向上させるために、後でインフラストラクチャを変更するのは困難である可能性があるため、あらかじめ成長に向けた計画を立てることをお勧めします。
既存のアプリケーションを Premium Storage に移行する場合は、まず、そのアプリケーションについて前述のチェックリストを作成します。 次に、Premium Storage でアプリケーションのプロトタイプを作成し、「アプリケーションのパフォーマンスの最適化」に記載されているガイドラインに基づいてアプリケーションを設計します。 次の記事では、パフォーマンスの測定値の収集に使用できるツールについて説明しています。
アプリケーションのパフォーマンス要件を評価するためのカウンター
アプリケーションのパフォーマンス要件を評価する最良の方法は、サーバーのオペレーティング システムによって提供される PerfMon 監視ツールを使用することです。 Windows 用 PerfMon と Linux 用 iostat が使用可能です。 これらのツールでは、前のセクションで説明した各評価基準に対応するカウンターがキャプチャされます。 アプリケーションが通常時、ピーク時、時間外のワークロードを実行しているときに、これらのカウンターの値をキャプチャする必要があります。
PerfMon カウンターは、サーバーのプロセッサ、メモリ、各論理ディスクと物理ディスクに使用できます。 VM で Premium Storage ディスクを使用している場合、物理ディスク カウンターは各 Premium Storage ディスクを対象としており、論理ディスク カウンターは Premium Storage ディスクに作成された各ボリュームを対象としています。 アプリケーションのワークロードをホストするディスクの値をキャプチャする必要があります。 論理ディスクと物理ディスクの間に一対一のマッピングが存在する場合は、物理ディスク カウンターを参照できます。 それ以外の場合は、論理ディスク カウンターを参照します。
Linux では、iostat コマンドによって、CPU とディスクの使用レポートが生成されます。 ディスク使用レポートには、物理デバイスまたはパーティションごとの統計が示されます。 データベース サーバーがデータとログに個別のディスクを使用している場合は、両方のディスクでこのデータを収集します。 次の表に、ディスク、プロセッサ、メモリのカウンターを示します。
| カウンタ | 説明 | PerfMon | iostat |
|---|---|---|---|
| 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 秒あたりにディスクに対して読み書きされたデータの量 | ディスク読み取りバイト数/秒 ディスク書き込みバイト数/秒 |
kB_read/s kB_wrtn/s |
| Latency | ディスク I/O 要求を完了するまでの合計時間 | Average disk sec/read Average disk sec/write |
await svctm |
| I/O サイズ | ストレージ ディスクに発行される I/O 要求のサイズ | Average Disk Bytes/Read Average Disk Bytes/Write |
avgrq-sz |
| キュー深度 | ストレージ ディスクに対して読み書きされるのを待機している未処理の I/O 要求の数 | Current Disk Queue Length | avgqu-sz |
| 最大メモリ | アプリケーションをスムーズに実行するために必要なメモリ容量 | % Committed Bytes In Use | Use vmstat |
| 最大 CPU | アプリケーションをスムーズに実行するために必要な CPU の量 | % Processor time | % 使用率 |
詳細については、「iostat」と「PerfMon」をご覧ください。
アプリケーションのパフォーマンスの最適化
Premium Storage で実行されるアプリケーションのパフォーマンスに影響を与える主な要素として、I/O 要求の特性、VM サイズ、ディスク サイズ、ディスク数、ディスク キャッシュ、マルチスレッド、キューの深さがあります。 これらの要素の一部は、システムで提供されるノブを使用して制御できます。
ほとんどのアプリケーションでは、I/O サイズとキューの深さを直接変更することはできません。 たとえば、SQL Server を使用している場合、I/O サイズとキューの深さを選択することはできません。 SQL Server では、最大限のパフォーマンスを得るために、最適な I/O サイズとキューの深さの値が選択されます。 パフォーマンスのニーズを満たす適切なリソースをプロビジョニングできるように、この 2 つの要素がアプリケーションのパフォーマンスに及ぼす影響を理解しておくことが重要です。
アプリケーションのパフォーマンスをどの程度最適化する必要があるかを明確にするために、このセクション全体を通じて、作成したアプリケーション要件チェックリストを参照します。 チェックリストに基づき、このセクションの要素の中で、調整する必要がある要素を特定できます。
アプリケーションのパフォーマンスに対する各要素の影響を監視するには、アプリケーションのセットアップでベンチマーク ツールを実行します。 Windows VM と Linux VM で一般的なベンチマーク ツールを実行する手順については、このドキュメントの最後のベンチマークに関する記事を参照してください。
IOPS、スループット、待機時間の最適化の概要
次の表に、パフォーマンス要素と、IOPS、スループット、待機時間の最適化に必要な手順の概要を示します。 この概要の後の各セクションで、それぞれの要素についてさらに詳しく説明します。
VM のサイズと、各種 VM で利用できる IOPS、スループット、待機時間に関する詳細については、「Azure の仮想マシンのサイズ」を参照してください。
| パフォーマンスの要素 | IOPS | スループット | Latency |
|---|---|---|---|
| シナリオ例 | 1 秒あたりに非常に多くのトランザクションを必要とするエンタープライズ OLTP アプリケーション。 | 大量のデータを処理するエンタープライズ データ ウェアハウス アプリケーション。 | オンライン ゲームなど、ユーザー要求にすぐに応答する必要があるほぼリアルタイムのアプリケーション。 |
| パフォーマンスの要素 | |||
| I/O サイズ | I/O サイズが小さいほど、IOPS が向上します。 | I/O サイズが大きいほど、スループットが向上します。 | |
| VM サイズ | アプリケーションの要件よりも高い IOPS を提供する VM サイズを使用します。 | スループットの上限がアプリケーションの要件よりも高い VM サイズを使用します。 | スケールの上限がアプリケーションの要件よりも高い VM サイズを使用します。 |
| ディスク サイズ | アプリケーションの要件よりも高い IOPS を提供するディスク サイズを使用します。 | スループットの上限がアプリケーションの要件よりも高いディスク サイズを使用します。 | スケールの上限がアプリケーションの要件よりも高いディスク サイズを使用します。 |
| VM とディスクのスケールの上限 | 選択した VM サイズの IOPS の上限が、接続されたストレージ ディスクによって引き上げられた総 IOPS を上回る必要があります。 | 選択した VM サイズのスループットの上限が、VM に接続された Premium Storage ディスクによって引き上げられた総スループットを上回る必要があります。 | 選択した VM サイズのスケールの上限が、接続された Premium Storage ディスクのスケールの上限の合計を上回る必要があります。 |
| ディスク キャッシュ | 読み取り IOPS を向上させるには、読み取り負荷の高い操作で、Premium Storage ディスクの ReadOnly キャッシュを有効にします。 | 読み取り待機時間を短縮するには、読み取り負荷の高い操作で、Premium Storage ディスクの ReadOnly キャッシュを有効にします。 | |
| ディスク ストライピング | 複数のディスクを使用し、それらのディスクをストライピングすると、IOPS とスループットが集約され、上限が高くなります。 VM あたりの上限の合計が、接続された Premium ディスクの上限の合計を上回る必要があります。 | ||
| ストライプ サイズ | OLTP アプリケーションで見られる小さなランダム I/O パターンでは、ストライプ サイズを小さくします。 たとえば、SQL Server OLTP アプリケーションには、64 KB のストライプ サイズを使用します。 | データ ウェアハウス アプリケーションで見られる大きな順次 I/O パターンでは、ストライプ サイズを大きくします。 たとえば、SQL Server データ ウェアハウス アプリケーションには、256 KB のストライプ サイズを使用します。 | |
| マルチスレッド | マルチスレッドを使用して、Premium Storage により多くの要求をプッシュすると、IOPS とスループットが向上します。 たとえば、SQL Server で大きい MAXDOP 値を設定して、より多くの CPU を SQL Server に割り当てます。 | ||
| キュー深度 | キューの深さが大きいほど、IOPS が向上します。 | キューの深さが大きいほど、スループットが向上します。 | キューの深さが小さいほど、待機時間が短縮されます。 |
I/O 要求の特性
I/O 要求は、アプリケーションが実行する入力/出力操作の単位です。 I/O 要求の特性 (ランダムまたは順次、読み取りまたは書き込み、サイズの大小) を特定すると、アプリケーションのパフォーマンス要件の決定に役立ちます。 アプリケーション インフラストラクチャの設計時に適切な判断を下すには、I/O 要求の特性を理解することが重要です。 最適なパフォーマンスを実現するには、I/O を均等に分散する必要があります。
I/O サイズは、さらに重要な要素の 1 つです。 I/O サイズは、アプリケーションによって生成される入力/出力操作の要求のサイズです。 I/O サイズは、パフォーマンス、特にアプリケーションが達成可能な IOPS と帯域幅に大きく影響します。 次の式は、IOPS、I/O サイズ、帯域幅/スループットの関係を示しています。
I/O サイズを変更できるアプリケーションもあれば、変更できないアプリケーションもあります。 たとえば、SQL Server では最適な I/O サイズが自動的に決定され、ユーザーがこれを変更することはできません。 一方、Oracle には、データベースの I/O 要求サイズの構成に使用できる DB_BLOCK_SIZE というパラメーターが用意されています。
I/O サイズを変更できないアプリケーションを使用している場合は、この記事のガイドラインを使用して、アプリケーションに最も関係するパフォーマンス KPI を最適化します。 次に例を示します。
- OLTP アプリケーションでは、数百万の小さなランダム I/O 要求が生成されます。 この種の I/O 要求を処理するには、IOPS が向上するようにアプリケーション インフラストラクチャを設計する必要があります。
- データ ウェアハウス アプリケーションでは、大きな順次 I/O 要求が生成されます。 この種の I/O 要求を処理するには、帯域幅またはスループットが向上するようにアプリケーション インフラストラクチャを設計する必要があります。
I/O サイズを変更できるアプリケーションを使用している場合は、他のパフォーマンス ガイドラインに加え、I/O サイズの次の経験則を使用します。
- I/O サイズが小さいほど、IOPS が向上します。 たとえば、OLTP アプリケーションでは 8 KB にします。
- I/O サイズが大きいほど、帯域幅/スループットが向上します。 たとえば、データ ウェアハウス アプリケーションでは 1,024 KB にします。
アプリケーションの IOPS とスループット/帯域幅の計算方法について、例を挙げて説明します。
P30 ディスクを使用するアプリケーションがあるとします。 P30 ディスクが実現できる最大 IOPS と最大スループット/帯域幅は、それぞれ 5,000 IOPS、200 MB/秒です。 アプリケーションに P30 ディスクの最大 IOPS が必要であり、8 KB のような小さい I/O サイズを使用すると、40 MB/秒の帯域幅が得られます。アプリケーションに P30 ディスクの最大スループット/帯域幅が必要であり、1024 KB のような大きい I/O サイズを使用すると、IOPS は 200 IOPS に低下します。
アプリケーションの IOPS とスループット/帯域幅の両方の要件を満たすように I/O サイズを調整します。 次の表に、さまざまな I/O サイズと、P30 ディスクの対応する IOPS およびスループットを示します。
| アプリケーションの要件 | I/O サイズ | IOPS | スループット/帯域幅 |
|---|---|---|---|
| 最大 IOPS | 8 KB | 5,000 | 40 MB/秒 |
| 最大スループット | 1,024 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 サイズを使用する必要があります。
Note
IOPS またはスループットのいずれかを高めることで、もう一方も向上します。 スループットまたは IOPS のいずれかを高めた場合は、ディスクや VM のスループットや IOPS の上限に達していないことを確認してください。
I/O サイズがアプリケーションのパフォーマンスに及ぼす影響を監視するには、VM とディスクでベンチマーク ツールを実行します。 複数のテスト実行を作成し、実行ごとに異なる I/O サイズを使用して影響を確認します。 詳細については、このドキュメントの終わりのベンチマークに関する記事を参照してください。
高スケール VM サイズ
アプリケーションの設計を始めるときに、最初に行うことの 1 つとして、アプリケーションをホストする VM の選択があります。 Premium Storage には、高いコンピューティング能力と高いローカル ディスク I/O パフォーマンスを必要とするアプリケーションを実行できる、高スケール VM サイズが用意されています。 これらの VM は、高速プロセッサ、高いメモリ対コア比、ローカル ディスク用ソリッド ステート ドライブ (SSD) を提供します。 Premium Storage をサポートする高スケール VM の例として、DS シリーズ VM、GS シリーズ VM があります。
高スケール VM は、CPU コア数、メモリ容量、OS、一時ディスク サイズが異なるさまざまなサイズで提供されます。 各 VM サイズには、VM に接続できるデータ ディスクの最大数も設けられています。 選択した VM サイズは、アプリケーションで利用できる処理能力、メモリ容量、ストレージ容量に影響します。 また、計算およびストレージ コストにも影響します。 例として、DS シリーズ、GS シリーズの最大 VM サイズの仕様を次に示します。
| VM サイズ | CPU コア数 | メモリ | VM のディスク サイズ | 最大データ ディスク数 | キャッシュ サイズ | IOPS | 帯域幅キャッシュ I/O の上限 |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | OS = 1,023 GB ローカル SSD = 224 GB |
32 | 576 GB | 50,000 IOPS 512 MB/秒 |
4,000 IOPS および 33 MB/秒 |
| Standard_GS5 | 32 | 448 GB | OS = 1,023 GB ローカル SSD = 896 GB |
64 | 4224 GB | 80,000 IOPS 2,000 MB/秒 |
5,000 IOPS および 50 MB/秒 |
利用可能なすべての Azure VM サイズの完全な一覧については、「Azure の仮想マシンのサイズ」を参照してください。 アプリケーションの目的のパフォーマンス要件を満たし、拡張できる 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 ディストリビューション
Premium Storage を使用すると、Windows を実行する VM と Linux を実行する VM で同レベルのパフォーマンスが得られます。 さまざまな Linux ディストリビューションがサポートされています。 詳細については、「Azure で動作保証済みの Linux ディストリビューション」を参照してください。
ワークロードの種類によって、適しているディストリビューションは異なります。 パフォーマンスのレベルは、ワークロードが実行されるディストリビューションによって異なります。 アプリケーションで Linux ディストリビューションをテストし、最適なディストリビューションを選択します。
Premium Storage で Linux を実行するときは、ハイ パフォーマンスを確保するために、必要なドライバーについて最新の更新プログラムを確認してください。
Premium Storage のディスク サイズ
Premium Storage ではさまざまなサイズが用意されているため、ニーズに最も適したものを選択できます。 ディスク サイズによって、IOPS、帯域幅、ストレージのスケールの上限がそれぞれ異なります。 アプリケーションの要件と高スケール VM のサイズに応じて、Premium Storage の適切なディスク サイズを選択します。 次の表に、ディスク サイズとその機能を示します。 P4、P6、P15、P60、P70、P80 サイズは、現在、マネージド ディスクのみでサポートされています。
| Premium SSD のサイズ | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ディスク サイズ (GiB) | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
| ディスクあたりの基本プロビジョニング済み IOPS | 120 | 120 | 120 | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
| **ディスクあたりの拡張プロビジョニング済み IOPS | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 8,000 | 16,000 | 20,000 | 20,000 | 20,000 | 20,000 |
| ディスクあたりの基本プロビジョニング済みスループット | 25 MB/秒 | 25 MB/秒 | 25 MB/秒 | 25 MB/秒 | 50 MB/秒 | 100 MB/秒 | 125 MB/秒 | 150 MB/秒 | 200 MB/s | 250 MB/秒 | 250 MB/秒 | 500 MB/秒 | 750 MB/秒 | 900 MB/秒 |
| **ディスクあたりの拡張プロビジョニング済みスループット | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 300 MB/秒 | 600 MB/秒 | 900 MB/秒 | 900 MB/秒 | 900 MB/秒 | 900 MB/秒 |
| ディスクあたりの最大バースト IOPS | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* | 30,000* |
| ディスクあたりの最大バースト スループット | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 170 MB/秒 | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* | 1,000 MB/秒* |
| 最大バースト時間 | 30 分 | 30 分 | 30 分 | 30 分 | 30 分 | 30 分 | 30 分 | 30 分 | 無制限* | 無制限* | 無制限* | 無制限* | 無制限* | 無制限* |
| 予約対象 | いいえ | 番号 | 番号 | 番号 | 番号 | 番号 | 番号 | いいえ | はい (最長 1 年) | はい (最長 1 年) | はい (最長 1 年) | はい (最長 1 年) | はい (最長 1 年) | はい (最長 1 年) |
*オンデマンド バーストが有効になっているディスクにのみ適用されます。
** Performance Plus (プレビュー) が有効になっているディスクにのみ適用されます。
選択するディスク数は、選択したディスク サイズによって異なります。 1 つの P50 ディスクまたは複数の P10 ディスクを使用して、アプリケーションの要件を満たすことができます。 選択時には、こちらの考慮事項に注意してください。
スケールの上限 (IOPS とスループット)
IOPS とスループットの上限は、Premium ディスク サイズごとに異なり、VM のスケールの上限から独立しています。 ディスクの総 IOPS と総スループットが、選択した VM サイズのスケールの上限を超えていないことを確認します。
たとえば、アプリケーションの要件が最大 250 MB/秒のスループットであり、DS4 VM と 1 つの P30 ディスクを使用している場合、DS4 VM が提供できる最大スループットは 256 MB/秒です。 ただし、1 つの P30 ディスクのスループットは 200 MB/秒に制限されています。そのため、アプリケーションは 200 MB/秒というディスクの制限による制約を受けます。 この制限を克服するには、VM に複数のデータ ディスクをプロビジョニングするか、ディスクのサイズを P40 または P50 に変更します。
Note
キャッシュで処理される読み取りはディスクの IOPS とスループットに含まれないので、ディスクの制限の対象にはなりません。 キャッシュには、VM あたりの IOPS とスループットの別の上限が設けられています。
たとえば、最初は読み取りと書き込みがそれぞれ 60MB/秒と 40MB/秒であったとします。 時間が経つにつれて、キャッシュがウォームアップされ、処理されるキャッシュからの読み取りが増加します。 これにより、ディスクからの書き込みスループットが向上します。
ディスクの数
アプリケーションの要件を評価して必要なディスク数を決定します。 各 VM サイズにも、VM に接続できるディスク数の上限が設けられています。 通常、この量はコア数の 2 倍です。 選択した VM サイズが必要なディスク数をサポートできることを確認します。
Premium Storage ディスクは、Standard Storage ディスクよりも高いパフォーマンス機能を備えています。 Standard Storage を使用する Azure IaaS VM から Premium Storage にアプリケーションを移行する場合、アプリケーションの同等以上のパフォーマンスを実現するために必要な Premium ディスク数が減る可能性があります。
ディスク キャッシュ
Premium Storage を使用する高スケール VM には、BlobCache と呼ばれる多層キャッシュ テクノロジがあります。 BlobCache では、ホストの RAM とローカル SSD を組み合わせてキャッシュに使用します。 このキャッシュは、Premium Storage の永続ディスクと VM のローカル ディスクで使用できます。 既定では、このキャッシュは、OS ディスクでは ReadWrite に設定され、Premium Storage でホストされるデータ ディスクでは ReadOnly に設定されます。 Premium Storage ディスクでディスク キャッシュを有効にすると、高スケール VM は基になるディスクのパフォーマンスを上回るきわめて高いレベルのパフォーマンスを実現できます。
警告
4 TiB 以上のディスクでは、ディスク キャッシュはサポートされていません。 複数のディスクが VM に接続されている場合、4 TiB 未満の各ディスクでは、キャッシュがサポートされます。
Azure ディスクのキャッシュ設定を変更すると、対象となるディスクをデタッチして再アタッチします。 オペレーティング システム ディスクの場合は、VM が再起動されます。 ディスク キャッシュの設定を変更する前に、この中断の影響を受ける可能性があるすべてのアプリケーションまたはサービスを停止します。 これらの推奨事項に従っていないと、データが破損する可能性があります。
BlobCache の機能の詳細については、Inside の Azure Premium Storage に関するブログ記事をご覧ください。
適切なディスク セットでキャッシュを有効にすることが重要です。 Premium ディスクでディスク キャッシュを有効にするかどうかは、そのディスクで処理されるワークロードのパターンによって決まります。 次の表に、OS ディスクとデータ ディスクの既定のキャッシュ設定を示します。
| ディスクの種類 | 既定のキャッシュ設定 |
|---|---|
| OS ディスク | ReadWrite |
| データ ディスク | ReadOnly |
データ ディスクには、次のディスク キャッシュ設定をお勧めします。
| ディスク キャッシュ設定 | この設定を使用するときの推奨事項 |
|---|---|
| なし | 書き込み専用ディスクと書き込み負荷の高いディスクでは、ホスト キャッシュを None に構成します。 |
| ReadOnly | 読み取り専用ディスクと読み取り/書き込みディスクでは、ホスト キャッシュを ReadOnly に構成します。 |
| ReadWrite | アプリケーションが、必要に応じてキャッシュ データの永続ディスクへの書き込みを適切に処理できる場合にのみ、ホスト キャッシュを ReadWrite に構成します。 |
ReadOnly
Premium Storage データ ディスクの ReadOnly キャッシュを構成することで、次の 2 つの理由により、読み取り待機時間を減らし、アプリケーションの読み取り IOPS と読み取りスループットを大幅に向上させることができます。
- VM のメモリおよびローカル SSD 上のキャッシュから実行される読み取りは、Azure Blob Storage 上のデータ ディスクからの読み取りよりも高速です。
- Premium Storage では、ディスクの IOPS とスループットのために、キャッシュからの読み取りはカウントされません。 このため、アプリケーションは、総 IOPS と総スループットを向上させることができます。
ReadWrite
既定では、OS ディスクは ReadWrite キャッシュが有効になっています。 最近、データ ディスクでも ReadWrite キャッシュのサポートが追加されました。 ReadWrite キャッシュを使用する場合、データをキャッシュから永続ディスクに適切な方法で書き込む必要があります。 たとえば、SQL Server では、永続ストレージ ディスクへのキャッシュ データの書き込みを独自に処理します。 必要なデータの永続化を処理しないアプリケーションで ReadWrite キャッシュを使用すると、VM がクラッシュした場合にデータが失われる可能性があります。
なし
現在、 [None] はデータ ディスクでのみサポートされています。 OS ディスクではサポートされていません。 OS ディスクに [なし] を設定した場合、この設定は内部でオーバーライドされ、[ReadOnly] に設定されます。
たとえば、次の手順を実行することで、Premium Storage で実行されている SQL Server にこれらのガイドラインを適用できます。
- データ ファイルをホストする Premium Storage ディスクに ReadOnly キャッシュを構成します。
- データ ページをデータ ディスクから直接取得するよりも、キャッシュから取得する方が高速であるため、キャッシュからの高速読み取りによって、SQL Server のクエリ時間が短縮されます。
- キャッシュからの読み取りに対応すると、Premium データ ディスクで提供される追加のスループットが得られます。 SQL Server は、さらに多くのデータ ページの取得や、バックアップと復元、バッチ読み込み、インデックスの再構築などの他の操作のために、この追加のスループットを使用できます。
- ログ ファイルをホストする Premium Storage ディスクに None キャッシュを構成します。
- ログ ファイルの操作は、主に書き込み負荷の高い操作であるため、ReadOnly キャッシュによるメリットはありません。
Linux VM のパフォーマンスの最適化
すべての Premium SSD や Ultra Disks では、データが失われる可能性のあるキャッシュがないことがわかっている場合、パフォーマンスを向上させるために、ディスク上のファイル システムのバリアを無効にすることができる場合があります。 Azure ディスク キャッシュが ReadOnly または None に設定されている場合、バリアを無効にすることができます。 ただし、キャッシュが ReadWrite に設定されている場合は、書き込み耐久性を維持するためにバリアを有効にしたままにしておく必要があります。 バリアは通常、デフォルトで有効になっていますが、ファイル システムの種類に応じて、以下のいずれかの方法でバリアを無効にすることができます。
- reiserFS: barrier=none マウント オプションを使用してバリアを無効にします。 バリアを明示的に有効にするには、barrier=flush を使用します。
- ext3/ext4 の場合、barrier=0 マウント オプションを使用してバリアを無効にします。 バリアを明示的に有効にするには、barrier=1 を使用します。
- XFS の場合、nobarrier マウント オプションを使用してバリアを無効にします。 バリアを明示的に有効にするには、barrier を使用します。 メインの Linux カーネルのバージョン 4.10 では、XFS ファイル システムの設計により、常に持続性が保証されます。 バリアを無効にしても効果はなく、"nobarrier" オプションは非推奨とされます。 ただし、一部の Linux ディストリビューションでは、以前のバージョンのカーネルでディストリビューション リリースへの変更が移植されている場合があります。 ディストリビューション ベンダに、自分が実行中のディストリビューションとバージョンの状態を確認してください。
ディスク ストライピング
高スケール VM が Premium Storage の複数の永続ディスクに接続されている場合、ディスクをストライピングすることで、IOPS、帯域幅、ストレージ容量を集約できます。
Windows では、記憶域スペースを使用してディスクをストライピングできます。 プールのディスクごとに 1 つの列を構成する必要があります。 そうしないと、ディスク間でのトラフィックの分散が不均等になるため、ストライプ ボリュームの全体的なパフォーマンスが予想よりも低くなる可能性があります。
サーバー マネージャーの UI を使用して、ストライプ ボリュームの列の総数を最大 8 列に設定できます。 8 個を超えるディスクを接続するときは、PowerShell を使用してボリュームを作成します。 PowerShell を使用すると、列数をディスクと同じ数に設定できます。 たとえば、1 つのストライプ セットに 16 個のディスクがある場合、New-VirtualDisk PowerShell コマンドレットの NumberOfColumns パラメーターで 16 列を指定します。
Linux では、MDADM ユーティリティを使用してディスクをストライピングします。 Linux でのディスク ストライピングの手順については、「Linux でのソフトウェア RAID の構成」を参照してください。
ストライプ サイズ
ディスク ストライピングの重要な構成の 1 つに、ストライプ サイズがあります。 ストライプ サイズ (ブロック サイズ) は、アプリケーションがストライプ ボリュームで対応できるデータの最小チャンクです。 構成するストライプ サイズは、アプリケーションの種類と要求パターンによって異なります。 間違ったストライプ サイズを選択すると、I/O の不均衡が生じ、アプリケーションのパフォーマンスが低下する可能性があります。
たとえば、アプリケーションによって生成された I/O 要求がディスクのストライプ サイズよりも大きい場合、ストレージ システムは、複数のディスクのストライプ ユニット境界にまたがって要求を書き込みます。 該当のデータにアクセスするときが来ると、要求を完了するために複数のストライプ ユニットにわたってシークしなければなりません。 このような動作の累積的影響により、パフォーマンスが大幅に低下する可能性があります。 一方、I/O 要求サイズがストライプ サイズよりも小さい場合や、要求の特性がランダムの場合、I/O 要求が同じディスクに追加されていく可能性があり、これがボトルネックとなって、最終的に I/O パフォーマンスが低下することがあります。
アプリケーションが実行するワークロードの種類に応じて、適切なストライプ サイズを選択します。 小さなランダム I/O 要求には、小さいストライプ サイズを使用します。 大きな順次 I/O 要求には、大きいストライプ サイズを使用します。 Premium Storage で実行するアプリケーションについて、ストライプ サイズの推奨事項を確認します。 SQL Server の場合、OLTP のワークロードには 64 KB、データ ウェアハウスのワークロードのには 256 KB のストライプ サイズを構成します。 詳細については、Azure VM 上の SQL Server パフォーマンスのベスト プラクティスに関するページをご覧ください。
Note
ストライピングできる Premium Storage ディスクの最大数は、DS シリーズ VM では 32 個、GS シリーズ VM では 64 個です。
マルチスレッド
Azure では、超並列のプラットフォームとして Premium Storage が設計されました。 このため、マルチスレッド アプリケーションは、シングルスレッド アプリケーションよりも高いパフォーマンスを実現します。 マルチスレッド アプリケーションでは、タスクを複数のスレッドに分割し、VM とディスクのリソースを最大限に活用することで実行効率を高めます。
たとえば、アプリケーションが 2 つのスレッドを使用して単一コアの VM で実行されている場合、CPU は 2 つのスレッドを切り替えて効率化できます。 一方のスレッドがディスク I/O の完了を待機している間、CPU はもう一方のスレッドに切り替えることができます。 このようにして、2 つのスレッドは単一のスレッドよりも多くの処理を実行できます。 VM に複数のコアがある場合、各コアがタスクを並行して実行できるので、実行時間がさらに短縮されます。
市販のアプリケーションでは、シングルスレッドまたはマルチスレッドの実装方法を変更できないことがあります。 たとえば、SQL Server はマルチ CPU とマルチコアに対応できます。 ただし、クエリを処理するときに、どのような条件下で 1 つまたは複数のスレッドを使用するかは SQL Server が決定します。 SQL Server は、マルチスレッドを使用してクエリを実行し、インデックスを構築できます。 クエリで大規模なテーブルを結合し、データをユーザーに返す前に並べ替える必要がある場合、SQL Server は複数のスレッドを使用すると考えられます。 SQL Server がクエリを実行する際に単一のスレッドと複数のスレッドのどちらを使用するかをユーザーが制御することはできません。
アプリケーションのマルチスレッド (並列処理) に影響を与える変更可能な構成設定があります。 たとえば、SQL Server の場合は max degree of parallelism 構成です。 MAXDOP と呼ばれるこの設定では、SQL Server が並列処理時に使用できるプロセッサの最大数を構成できます。 個々のクエリやインデックス操作の MAXDOP を構成できます。 この機能は、パフォーマンス クリティカルなアプリケーションのためにシステムのリソースのバランスをとる場合に役立ちます。
たとえば、SQL Server を使用するアプリケーションが、大規模なクエリとインデックス操作を同時に実行しているとします。 大規模なクエリよりも、インデックス操作のパフォーマンスを高める必要があると仮定します。 このような場合、インデックス操作の MAXDOP 値を、クエリの MAXDOP 値よりも大きい値に設定します。 これにより、SQL Server は大規模なクエリに割り当てることができるプロセッサよりも多くのプロセッサをインデックス操作に使用できます。 SQL Server が各操作に使用するスレッドの数を制御するわけではないことに注意してください。 制御できるのは、マルチスレッド専用のプロセッサの最大数です。
SQL Server の 並列処理の次数 の詳細をご覧ください。 アプリケーションのマルチスレッドに影響を与えるこのような設定とパフォーマンスを最適化する構成を確認してください。
キュー深度
キューの深さ (キューの長さまたはキューのサイズ) は、システムで保留中の I/O 要求の数です。 キューの深さの値によって、アプリケーションが準備できる I/O 操作の数が決まります。I/O 操作はストレージ ディスクによって処理されます。 これは、この記事で説明したアプリケーションの 3 つのパフォーマンス指標 (IOPS、スループット、待機時間) のすべてに影響します。
キューの深さとマルチスレッドは密接に関係しています。 キューの深さの値は、アプリケーションがどの程度のマルチスレッドを実現できるかを示します。 キューの深さが大きい場合、アプリケーションはより多くの操作を同時に実行できます。つまり、マルチスレッドのスレッド数が多いということです。 キューの深さが小さい場合、アプリケーションは、マルチスレッド化されていても、同時実行できるだけの十分な数の要求を準備できなくなります。
通常、市販のアプリケーションでは、キューの深さを変更することはできません。これは、キューの深さが正しく設定されていないと、メリットよりもデメリットの方が大きくなるからです。 最適なパフォーマンスを得るために、アプリケーションによってキューの深さの適切な値が設定されます。 アプリケーションで発生するパフォーマンスの問題をトラブルシューティングできるように、この概念を理解しておくことが重要です。 また、システムでベンチマーク ツールを実行することによって、キューの深さの影響を確認できます。
一部のアプリケーションには、キューの深さに影響を与える設定が用意されています。 例として、前のセクションで説明した SQL Server の MAXDOP 設定が挙げられます。 MAXDOP は、SQL Server のキューの深さの値を直接変更するわけではありませんが、キューの深さとマルチスレッドに影響を及ぼします。
キューの深さが大きい場合
キューの深さが大きい場合、ディスク上での操作が増えます。 ディスクは、キューにある次の要求を事前に認識します。 そのため、ディスクは操作を事前にスケジュールし、最適な順序で操作を処理できます。 アプリケーションがディスクに送信する要求が増えるので、ディスクはより多くの並列 I/O を処理できます。 最終的に、アプリケーションは IOPS を向上させることができます。 アプリケーションが処理する要求が増えるので、アプリケーションの総スループットも向上します。
通常、アプリケーションは、接続されたディスクごとに 8 ~ 16 個以上の未処理の I/O がある状態のときに最大スループットを実現できます。 キューの深さが 1 の場合、アプリケーションはシステムに十分な数の I/O をプッシュしなくなり、一定期間の処理量が減少します。 つまり、スループットが低下します。
たとえば、SQL Server でクエリの MAXDOP 値を 4 に設定すると、クエリの実行に最大 4 つのコアを使用できることが SQL Server に通知されます。 SQL Server は、クエリの実行に最適なキューの深さの値とコア数を決定します。
キューの深さが最適な場合
キューの深さの値が非常に大きい場合、欠点もあります。 キューの深さの値が大きすぎると、アプリケーションは IOPS を大幅に引き上げようとします。 IOPS が十分にプロビジョニングされた永続ディスクをアプリケーションが使用できる場合を除き、キューの深さの値が大きいとアプリケーションの待機時間に悪影響を及ぼす可能性があります。 次の式は、IOPS、待機時間、キューの深さの関係を示しています。
キューの深さを大きな値に構成するのではなく、待機時間に影響を及ぼさずにアプリケーションに十分な IOPS を提供できる最適な値に構成します。 たとえば、アプリケーションの待機時間を 1 ミリ秒にする必要がある場合、5,000 IOPS を実現するために必要なキューの深さは、QD = 5,000 x 0.001 = 5 になります。
ストライプ ボリュームのキューの深さ
ストライプ ボリュームの場合、すべてのディスクのキューの深さがそれぞれピーク時のキューの深さになるように、十分なキューの深さを維持します。 たとえば、キューの深さ 2 をプッシュするアプリケーションがあり、ストライプに 4 つのディスクがあるとします。 2 つの I/O 要求が 2 つのディスクに送信されると、残りの 2 つのディスクはアイドル状態になります。 そのため、すべてのディスクがビジー状態になるようにキューの深さを構成します。 次の式は、ストライプ ボリュームのキューの深さを決定する方法を示しています。
調整
Premium Storage では、選択された VM サイズとディスク サイズに応じて、指定された数の IOPS とスループットがプロビジョニングされます。 アプリケーションが、VM またはディスクが対応できるこれらの上限を超えて IOPS やスループットを引き上げようとすると、これを抑制するように調整されます。 その結果、アプリケーションのパフォーマンスが低下します。これにより、待機時間が長くなり、スループットや IOPS が低下する可能性があります。
Premium Storage によって調整が行われないと、リソースが対応できる範囲を上回り、アプリケーションが完全に失敗する可能性があります。 調整によるパフォーマンスの問題を回避するために、常にアプリケーションの十分なリソースをプロビジョニングします。 前の VM サイズとディスク サイズのセクションで説明した考慮事項に注意してください。 ベンチマークは、アプリケーションをホストするために必要なリソースを把握するための最適な方法です。
次のステップ
ディスクのベンチマークの実行を検討している場合は、次の記事を参照してください。
- Linux の場合:Azure Disk Storage 上のアプリケーションのベンチマーク
- Windows の場合: ディスクのベンチマークの実行
使用できるディスクの種類については、次のページを参照してください。
- Linux の場合:ディスクの種類の選択
- Windows の場合:ディスクの種類の選択
SQL Server ユーザーは、SQL Server のパフォーマンスのベスト プラクティスに関する次の記事をご覧ください。