Azure Premium Storage: 高パフォーマンス用に設計するAzure premium storage: design for high performance

この記事では、Azure Premium Storage を使用する高パフォーマンスのアプリケーションを構築するためのガイドラインを示します。This article provides guidelines for building high performance applications using Azure Premium Storage. このドキュメントで説明する手順は、アプリケーションで使用されているテクノロジに適用できるパフォーマンスのベスト プラクティスと組み合わせて使用できます。You can use the instructions provided in this document combined with performance best practices applicable to technologies used by your application. ガイドラインを示すために、このドキュメント全体を通じて、Premium Storage で実行されている SQL Server を例として使用しています。To illustrate the guidelines, we have used SQL Server running on Premium Storage as an example throughout this document.

この記事では、ストレージ層のパフォーマンスのシナリオに対処していますが、アプリケーション層を最適化する必要があります。While we address performance scenarios for the Storage layer in this article, you will need to optimize the application layer. たとえば、Azure Premium Storage で SharePoint ファームをホストしている場合は、この記事の SQL Server の例を使用してデータベース サーバーを最適化できます。For example, if you are hosting a SharePoint Farm on Azure Premium Storage, you can use the SQL Server examples from this article to optimize the database server. さらに、最大限のパフォーマンスを得るために、SharePoint ファームの Web サーバーとアプリケーション サーバーを最適化します。Additionally, optimize the SharePoint Farm's Web server and Application server to get the most performance.

この記事は、Azure Premium Storage でのアプリケーションのパフォーマンスの最適化に関する次のような一般的な質問に答えるのに役立ちます。This article will help answer following common questions about optimizing application performance on Azure Premium Storage,

  • アプリケーションのパフォーマンスはどのように測定するのか。How to measure your application performance?
  • 予想される高パフォーマンスが得られないのはなぜか。Why are you not seeing expected high performance?
  • Premium Storage でアプリケーションのパフォーマンスに影響を及ぼすのはどの要素か。Which factors influence your application performance on Premium Storage?
  • 各要素は Premium Storage でアプリケーションのパフォーマンスにどのような影響を及ぼすのか。How do these factors influence performance of your application on Premium Storage?
  • IOPS、帯域幅、待機時間に最適化するにはどうすればよいか。How can you optimize for IOPS, Bandwidth and Latency?

Premium Storage で実行されるワークロードは高パフォーマンスに依存するため、Premium Storage 専用のガイドラインを用意しました。We have provided these guidelines specifically for Premium Storage because workloads running on Premium Storage are highly performance sensitive. 必要に応じて例も示しています。We have provided examples where appropriate. これらのガイドラインの一部は、Standard Storage ディスクを使用する IaaS VM で実行されるアプリケーションにも適用できます。You can also apply some of these guidelines to applications running on IaaS VMs with Standard Storage disks.


ときには、ディスク パフォーマンスの問題のように見えるものが、実際にはネットワークのボトルネックであることもあります。Sometimes, what appears to be a disk performance issue is actually a network bottleneck. このような場合は、ネットワーク パフォーマンスを最適化する必要があります。In these situations, you should optimize your network performance.

ディスクのベンチマークを実行する場合は、ディスクのベンチマークに関する記事を参照してください。If you are looking to benchmark your disk, see our articles on benchmarking a disk:

VM で高速ネットワークがサポートされる場合は、それが有効になっていることを確認する必要があります。If your VM supports accelerated networking, you should make sure it is enabled. 有効になっていない場合は、WindowsLinux の両方で、既にデプロイされている VM 上で有効にすることができます。If it is not enabled, you can enable it on already deployed VMs on both Windows and Linux.

Premium Storage を初めてご使用になる場合は、作業を始める前に、まず IaaS VM 用の Azure ディスクの種類の選択に関する記事と、Premium ページ BLOB ストレージ アカウントのスケーラビリティ ターゲットに関する記事をお読みください。Before you begin, if you are new to Premium Storage, first read the Select an Azure disk type for IaaS VMs and Scalability targets for premium page blob storage accounts.

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

アプリケーションがユーザー要求を処理する速度、アプリケーションが要求ごとに処理するデータの量、アプリケーションが一定時間内に処理する要求の数、要求の送信後、応答が返されるまでのユーザーの待機時間などのパフォーマンス指標を使用して、アプリケーションが問題なく実行されているかどうかを評価します。We assess whether an application is performing well or not using performance indicators like, how fast an application is processing a user request, how much data an application is processing per request, how many requests is an application processing in a specific period of time, how long a user has to wait to get a response after submitting their request. これらのパフォーマンス指標は、IOPS、スループットまたは帯域幅、待機時間という専門用語で表されます。The technical terms for these performance indicators are, IOPS, Throughput or Bandwidth, and Latency.

このセクションでは、Premium Storage のコンテキストでの一般的なパフォーマンス指標について説明します。In this section, we will discuss the common performance indicators in the context of Premium Storage. 次の「アプリケーションのパフォーマンス要件の収集」では、アプリケーションのこれらのパフォーマンス指標を測定する方法について説明します。In the following section, Gathering Application Requirements, you will learn how to measure these performance indicators for your application. 「アプリケーションのパフォーマンスの最適化」の後半で、これらのパフォーマンス指標に影響する要素と、それらを最適化するための推奨事項について説明します。Later in Optimizing Application Performance, you will learn about the factors affecting these performance indicators and recommendations to optimize them.


IOPS (Input/output Operations Per Second) は、アプリケーションが 1 秒間にストレージ ディスクに送信する要求の数です。IOPS, or Input/output Operations Per Second, is the number of requests that your application is sending to the storage disks in one second. 入力/出力操作は読み取りまたは書き込みであり、順次の場合とランダムの場合があります。An input/output operation could be read or write, sequential, or random. オンライン小売 Web サイトのようなオンライン トランザクション処理 (OLTP) アプリケーションでは、多数の同時ユーザー要求を即座に処理する必要があります。Online Transaction Processing (OLTP) applications like an online retail website need to process many concurrent user requests immediately. これらのユーザー要求は、挿入と更新が集中的に行われるデータベース トランザクションであり、アプリケーションはこれらのトランザクションを迅速に処理する必要があります。The user requests are insert and update intensive database transactions, which the application must process quickly. そのため、OLTP アプリケーションでは非常に高い IOPS が必要となります。Therefore, OLTP applications require very high IOPS. このようなアプリケーションは、数百万の小さなランダム IO 要求を処理します。Such applications handle millions of small and random IO requests. このようなアプリケーションを使用する場合は、IOPS に最適化するようにアプリケーション インフラストラクチャを設計する必要があります。If you have such an application, you must design the application infrastructure to optimize for IOPS. 後述の「 アプリケーションのパフォーマンスの最適化」で、高 IOPS を実現するために考慮する必要があるすべての要素について詳しく説明します。In the later section, Optimizing Application Performance, we discuss in detail all the factors that you must consider to get high IOPS.

Premium Storage ディスクを高スケール VM に接続すると、そのディスクの仕様どおりに、保証された数の IOPS がプロビジョニングされます。When you attach a premium storage disk to your high scale VM, Azure provisions for you a guaranteed number of IOPS as per the disk specification. たとえば、P50 ディスクでは 7,500 IOPS がプロビジョニングされます。For example, a P50 disk provisions 7500 IOPS. また、高スケール VM の各サイズにも、維持できる IOPS の上限が設けられています。Each high scale VM size also has a specific IOPS limit that it can sustain. たとえば、Standard GS5 VM の IOPS の上限は 80,000 です。For example, a Standard GS5 VM has 80,000 IOPS limit.


スループットまたは帯域幅は、アプリケーションが指定された期間にストレージ ディスクに送信するデータの量です。Throughput, or bandwidth is the amount of data that your application is sending to the storage disks in a specified interval. アプリケーションが大きな IO ユニット サイズで入力/出力操作を実行する場合、高スループットが必要となります。If your application is performing input/output operations with large IO unit sizes, it requires high throughput. データ ウェアハウス アプリケーションは、一度にデータの大部分にアクセスするスキャン集中型の操作を発行する傾向があり、一般に一括操作を実行します。Data warehouse applications tend to issue scan intensive operations that access large portions of data at a time and commonly perform bulk operations. つまり、このようなアプリケーションでは、スループットを高める必要があります。In other words, such applications require higher throughput. このようなアプリケーションを使用する場合は、スループットに最適化するようにインフラストラクチャを設計する必要があります。If you have such an application, you must design its infrastructure to optimize for throughput. 次のセクションで、これを実現するために調整する必要がある要素について詳しく説明します。In the next section, we discuss in detail the factors you must tune to achieve this.

Premium Storage ディスクを高スケール VM に接続すると、そのディスクの仕様どおりにスループットがプロビジョニングされます。When you attach a premium storage disk to a high scale VM, Azure provisions throughput as per that disk specification. たとえば、P50 ディスクでは 250 MB/秒のディスク スループットがプロビジョニングされます。For example, a P50 disk provisions 250 MB per second disk throughput. また、高スケール VM の各サイズにも、維持できるスループットの上限が設けられています。Each high scale VM size also has as specific throughput limit that it can sustain. たとえば、Standard GS5 VM の最大スループットは 2,000 MB/秒です。For example, Standard GS5 VM has a maximum throughput of 2,000 MB per second.

スループットと IOPS の間には、次の式に示すような関係があります。There is a relation between throughput and IOPS as shown in the formula below.

IOPS とスループットの関係

そのため、アプリケーションが必要とする最適なスループットと IOPS の値を特定することが重要です。Therefore, it is important to determine the optimal throughput and IOPS values that your application requires. 一方を最適化すると、もう一方も影響を受けます。As you try to optimize one, the other also gets affected. 後述の「 アプリケーションのパフォーマンスの最適化」で、IOPS とスループットの最適化について詳しく説明します。In a later section, Optimizing Application Performance, we will discuss in more details about optimizing IOPS and Throughput.


待機時間は、アプリケーションが 1 つの要求を受信し、その要求をストレージ ディスクに送信して、クライアントに応答を送信するまでの所要時間です。Latency is the time it takes an application to receive a single request, send it to the storage disks and send the response to the client. これは、IOPS とスループットに加え、アプリケーションのパフォーマンスの重要な評価基準となります。This is a critical measure of an application's performance in addition to IOPS and Throughput. Premium Storage ディスクの待機時間は、ディスクが要求の情報を取得し、それをアプリケーションに伝えるまでの所要時間です。The Latency of a premium storage disk is the time it takes to retrieve the information for a request and communicate it back to your application. Premium Storage は、一貫した低待機時間を実現します。Premium Storage provides consistent low latencies. Premium ディスクは、ほとんどの IO 操作で待ち時間が 10 ミリ秒未満となるように設計されています。Premium Disks are designed to provide single-digit millisecond latencies for most IO operations. Premium Storage ディスクの ReadOnly ホスト キャッシュを有効にすると、読み取り待機時間をさらに短縮できます。If you enable ReadOnly host caching on premium storage disks, you can get much lower read latency. ディスク キャッシュについては、後述の「 アプリケーションのパフォーマンスの最適化」で詳しく説明します。We will discuss Disk Caching in more detail in later section on Optimizing Application Performance.

IOPS とスループットを向上させるためにアプリケーションを最適化すると、アプリケーションの待機時間に影響します。When you are optimizing your application to get higher IOPS and Throughput, it will affect the latency of your application. アプリケーションのパフォーマンスを調整したら、予期しない待機時間の長い動作を回避するために、アプリケーションの待機時間を必ず評価してください。After tuning the application performance, always evaluate the latency of the application to avoid unexpected high latency behavior.

マネージド ディスクに対する次のコントロール プレーン操作は、ある Storage の場所から別の場所へのディスクの移動を伴う場合があります。The following control plane operations on Managed Disks may involve movement of the Disk from one Storage location to another. これはデータのバックグラウンド コピーによって調整されますが、完了までに数時間かかることがあります (ディスク内のデータの量にもよりますが、通常は 24 時間弱です)。This is orchestrated via background copy of data that can take several hours to complete, typically less than 24 hours depending on the amount of data in the disks. その間、お使いのアプリケーションでは読み取りの待機時間が通常よりも長くなる可能性があります。一部の読み取りが元の場所にリダイレクトされ、完了までにより長い時間がかかる場合があるためです。During that time your application can experience higher than usual read latency as some reads can get redirected to the original location and can take longer to complete. この期間中、書き込みの待ち時間への影響はありません。There is no impact on write latency during this period.

  • ストレージの種類を更新するUpdate the storage type.
  • ある VM からディスクをデタッチし、別の VM にアタッチするDetach and attach a disk from one VM to another.
  • VHD からマネージド ディスクを作成するCreate a managed disk from a VHD.
  • スナップショットからマネージド ディスクを作成するCreate a managed disk from a snapshot.
  • アンマネージド ディスクをマネージド ディスクに変換するConvert unmanaged disks to managed disks.

ディスクのパフォーマンス アプリケーション チェックリストPerformance Application Checklist for disks

Azure Premium Storage で実行される高パフォーマンスのアプリケーションを設計するときには、まず、アプリケーションのパフォーマンス要件を把握します。The first step in designing high-performance applications running on Azure Premium Storage is understanding the performance requirements of your application. パフォーマンス要件を収集したら、最適なパフォーマンスを実現するためにアプリケーションを最適化できます。After you have gathered performance requirements, you can optimize your application to achieve the most optimal performance.

前のセクションで、一般的なパフォーマンス指標、IOPS、スループット、待機時間について説明しました。In the previous section, we explained the common performance indicators, IOPS, Throughput, and Latency. これらのパフォーマンス指標の中で、目的のユーザー エクスペリエンスを実現するためにアプリケーションに不可欠な指標を特定する必要があります。You must identify which of these performance indicators are critical to your application to deliver the desired user experience. たとえば、1 秒間に数百万のトランザクションを処理する OLTP アプリケーションでは、高 IOPS が最も重要となります。For example, high IOPS matters most to OLTP applications processing millions of transactions in a second. 一方、1 秒間に大量のデータを処理するデータ ウェアハウス アプリケーションでは、高スループットが重要となります。Whereas, high Throughput is critical for Data Warehouse applications processing large amounts of data in a second. ライブ ビデオ ストリーミング Web サイトのようなリアルタイム アプリケーションでは、待機時間がきわめて短いことが重要です。Extremely low Latency is crucial for real-time applications like live video streaming websites.

次に、アプリケーションの有効期間全体にわたる最大パフォーマンス要件を評価します。Next, measure the maximum performance requirements of your application throughout its lifetime. 次のサンプル チェックリストを出発点として使用します。Use the sample checklist below as a start. 通常時、ピーク時、時間外の各ワークロード期間の最大パフォーマンス要件を記録します。Record the maximum performance requirements during normal, peak, and off-hours workload periods. すべてのワークロード レベルの要件を特定することで、アプリケーションの全体的なパフォーマンス要件を決定できるようになります。By identifying requirements for all workloads levels, you will be able to determine the overall performance requirement of your application. たとえば、電子商取引 Web サイトの通常時のワークロードは、ほぼ毎日処理されるトランザクションです。For example, the normal workload of an e-commerce website will be the transactions it serves during most days in a year. この Web サイトのピーク時のワークロードは、休暇シーズンや特売イベント中に処理されるトランザクションです。The peak workload of the website will be the transactions it serves during holiday season or special sale events. 通常、ピーク時のワークロードが発生するのは限られた期間ですが、アプリケーションで通常の操作を 2 倍以上に拡張することが必要になる可能性があります。The peak workload is typically experienced for a limited period, but can require your application to scale two or more times its normal operation. 50 パーセンタイル、90 パーセンタイル、99 パーセンタイルの要件を確認します。Find out the 50 percentile, 90 percentile, and 99 percentile requirements. これにより、パフォーマンス要件のすべての外れ値を除外し、適切な値に最適化することに専念できます。This helps filter out any outliers in the performance requirements and you can focus your efforts on optimizing for the right values.

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

パフォーマンス要件Performance requirements 50 パーセンタイル50 Percentile 90 パーセンタイル90 Percentile 99 パーセンタイル99 Percentile
最大Max. 1 秒あたりのトランザクション数Transactions per second
% 読み取り操作% Read operations
% 書き込み操作% Write operations
% ランダム操作% Random operations
% 順次操作% Sequential operations
IO 要求サイズIO request size
平均スループットAverage Throughput
最大Max. スループットThroughput
最小Min. LatencyLatency
平均待機時間Average Latency
平均 CPUAverage CPU
最大Max. メモリMemory
平均メモリ使用量Average Memory
キューの深さQueue Depth


アプリケーションの予想される将来の成長に基づいて、これらの数値を調整することを検討する必要があります。You should consider scaling these numbers based on expected future growth of your application. パフォーマンスを向上させるために、後でインフラストラクチャを変更するのは困難である可能性があるため、あらかじめ成長に向けた計画を立てることをお勧めします。It is a good idea to plan for growth ahead of time, because it could be harder to change the infrastructure for improving performance later.

既存のアプリケーションを Premium Storage に移行する場合は、まず、そのアプリケーションについて上記のチェックリストを作成します。If you have an existing application and want to move to Premium Storage, first build the checklist above for the existing application. 次に、Premium Storage でアプリケーションのプロトタイプを作成し、このドキュメントで後述する「 アプリケーションのパフォーマンスの最適化 」に記載されているガイドラインに基づいてアプリケーションを設計します。Then, build a prototype of your application on Premium Storage and design the application based on guidelines described in Optimizing Application Performance in a later section of this document. 次の記事では、パフォーマンスの測定値の収集に使用できるツールについて説明しています。The next article describes the tools you can use to gather the performance measurements.

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

アプリケーションのパフォーマンス要件を評価する最良の方法は、サーバーのオペレーティング システムによって提供されるパフォーマンス監視ツールを使用することです。The best way to measure performance requirements of your application, is to use performance-monitoring tools provided by the operating system of the server. Windows では PerfMon、Linux では iostat を使用できます。You can use PerfMon for Windows and iostat for Linux. これらのツールでは、前のセクションで説明した各評価基準に対応するカウンターがキャプチャされます。These tools capture counters corresponding to each measure explained in the above section. アプリケーションが通常時、ピーク時、時間外のワークロードを実行しているときに、これらのカウンターの値をキャプチャする必要があります。You must capture the values of these counters when your application is running its normal, peak, and off-hours workloads.

PerfMon カウンターは、サーバーのプロセッサ、メモリ、各論理ディスクと物理ディスクに使用できます。The PerfMon counters are available for processor, memory and, each logical disk and physical disk of your server. VM で Premium Storage ディスクを使用している場合、物理ディスク カウンターは各 Premium Storage ディスクを対象としており、論理ディスク カウンターは Premium Storage ディスクに作成された各ボリュームを対象としています。When you use premium storage disks with a VM, the physical disk counters are for each premium storage disk, and logical disk counters are for each volume created on the premium storage disks. アプリケーションのワークロードをホストするディスクの値をキャプチャする必要があります。You must capture the values for the disks that host your application workload. 論理ディスクと物理ディスクの間に一対一のマッピングが存在する場合は、物理ディスク カウンターを参照できます。それ以外の場合は、論理ディスク カウンターを参照します。If there is a one to one mapping between logical and physical disks, you can refer to physical disk counters; otherwise refer to the logical disk counters. Linux では、iostat コマンドによって、CPU とディスクの使用レポートが生成されます。On Linux, the iostat command generates a CPU and disk utilization report. ディスク使用レポートには、物理デバイスまたはパーティションごとの統計が示されます。The disk utilization report provides statistics per physical device or partition. データベース サーバーがデータとログに個別のディスクを使用している場合は、両方のディスクでこのデータを収集します。If you have a database server with its data and logs on separate disks, collect this data for both disks. 次の表に、ディスク、プロセッサ、メモリのカウンターを示します。Below table describes counters for disks, processors, and memory:

カウンターCounter 説明Description PerfMonPerfMon iostatIostat
1 秒あたりの IOPS またはトランザクション数IOPS or Transactions per second 1 秒あたりにストレージ ディスクに発行された I/O 要求の数。Number of I/O requests issued to the storage disk per second. Disk Reads/secDisk Reads/sec
Disk Writes/secDisk Writes/sec
ディスク読み取り回数/書き込み回数Disk Reads and Writes ディスク上で実行された読み取り操作と書き込み操作の割合。% of Reads and Write operations performed on the disk. % Disk Read Time% Disk Read Time
% Disk Write Time% Disk Write Time
スループットThroughput 1 秒あたりにディスクに対して読み書きされたデータの量。Amount of data read from or written to the disk per second. Disk Read Bytes/secDisk Read Bytes/sec
Disk Write Bytes/secDisk Write Bytes/sec
待機時間Latency ディスク IO 要求を完了するまでの合計時間。Total time to complete a disk IO request. Average Disk sec/ReadAverage Disk sec/Read
Average disk sec/WriteAverage disk sec/Write
IO サイズIO size ストレージ ディスクに発行される I/O 要求のサイズ。The size of I/O requests issues to the storage disks. Average Disk Bytes/ReadAverage Disk Bytes/Read
Average Disk Bytes/WriteAverage Disk Bytes/Write
キューの深さQueue Depth ストレージ ディスクに対して読み書きされるのを待機している未処理の I/O 要求の数。Number of outstanding I/O requests waiting to be read from or written to the storage disk. Current Disk Queue LengthCurrent Disk Queue Length avgqu-szavgqu-sz
最大メモリMax. Memory アプリケーションをスムーズに実行するために必要なメモリ容量。Amount of memory required to run application smoothly % Committed Bytes in Use% Committed Bytes in Use Use vmstatUse vmstat
最大CPUMax. CPU アプリケーションをスムーズに実行するために必要な CPU 量。Amount CPU required to run application smoothly % Processor time% Processor time % 使用率%util

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

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

Premium Storage で実行されるアプリケーションのパフォーマンスに影響を与える主な要素として、IO 要求の特性、VM サイズ、ディスク サイズ、ディスク数、ディスク キャッシュ、マルチスレッド、キューの深さがあります。The main factors that influence performance of an application running on Premium Storage are Nature of IO requests, VM size, Disk size, Number of disks, disk caching, multithreading, and queue depth. これらの要素の一部は、システムで提供されるノブを使用して制御できます。You can control some of these factors with knobs provided by the system. ほとんどのアプリケーションでは、IO サイズとキューの深さを直接変更することはできません。Most applications may not give you an option to alter the IO size and Queue Depth directly. たとえば、SQL Server を使用している場合、IO サイズとキューの深さを選択することはできません。For example, if you are using SQL Server, you cannot choose the IO size and queue depth. SQL Server では、最大限のパフォーマンスを得るために、最適な IO サイズとキューの深さの値が選択されます。SQL Server chooses the optimal IO size and queue depth values to get the most performance. パフォーマンスのニーズを満たす適切なリソースをプロビジョニングできるように、この 2 つの要素がアプリケーションのパフォーマンスに及ぼす影響を理解しておくことが重要です。It is important to understand the effects of both types of factors on your application performance, so that you can provision appropriate resources to meet performance needs.

アプリケーションのパフォーマンスをどの程度最適化する必要があるかを明確にするために、このセクション全体を通じて、作成したアプリケーション要件チェックリストを参照します。Throughout this section, refer to the application requirements checklist that you created, to identify how much you need to optimize your application performance. これを基に、このセクションの要素の中で、調整する必要がある要素を特定できるようになります。Based on that, you will be able to determine which factors from this section you will need to tune. アプリケーションのパフォーマンスに対する各要素の影響を監視するには、アプリケーションのセットアップでベンチマーク ツールを実行します。To witness the effects of each factor on your application performance, run benchmarking tools on your application setup. Windows VM と Linux VM で一般的なベンチマーク ツールを実行する手順については、ベンチマークに関する記事をご覧ください。この記事の最後にリンクが貼ってあります。Refer to the Benchmarking article, linked at the end, for steps to run common benchmarking tools on Windows and Linux VMs.

IOPS、スループット、待機時間の最適化の概要Optimize IOPS, throughput, and latency at a glance

次の表に、パフォーマンス要素と、IOPS、スループット、待機時間の最適化に必要な手順の概要を示します。The table below summarizes performance factors and the steps necessary to optimize IOPS, throughput, and latency. この概要の後の各セクションで、それぞれの要素についてさらに詳しく説明します。The sections following this summary will describe each factor is much more depth.

VM のサイズと、各種 VM で利用できる IOPS、スループット、待機時間に関する詳細については、「Azure の仮想マシンのサイズ」を参照してください。For more information on VM sizes and on the IOPS, throughput, and latency available for each type of VM, see Sizes for virtual machines in Azure.

IOPSIOPS スループットThroughput 待機時間Latency
サンプル シナリオExample Scenario 1 秒あたりに非常に多くのトランザクションを必要とするエンタープライズ OLTP アプリケーション。Enterprise OLTP application requiring very high transactions per second rate. 大量のデータを処理するエンタープライズ データ ウェアハウス アプリケーション。Enterprise Data warehousing application processing large amounts of data. オンライン ゲームなど、ユーザー要求にすぐに応答する必要があるほぼリアルタイムのアプリケーション。Near real-time applications requiring instant responses to user requests, like online gaming.
パフォーマンスの要素Performance factors      
IO サイズIO size IO サイズが小さいほど、IOPS が向上します。Smaller IO size yields higher IOPS. IO サイズが大きいほど、スループットが向上します。Larger IO size to yields higher Throughput.  
VM サイズVM size アプリケーションの要件よりも高い IOPS を提供する VM サイズを使用します。Use a VM size that offers IOPS greater than your application requirement. スループットの上限がアプリケーションの要件よりも高い VM サイズを使用します。Use a VM size with throughput limit greater than your application requirement. スケールの上限がアプリケーションの要件よりも高い VM サイズを使用します。Use a VM size that offers scale limits greater than your application requirement.
ディスク サイズDisk size アプリケーションの要件よりも高い IOPS を提供するディスク サイズを使用します。Use a disk size that offers IOPS greater than your application requirement. スループットの上限がアプリケーションの要件よりも高いディスク サイズを使用します。Use a disk size with Throughput limit greater than your application requirement. スケールの上限がアプリケーションの要件よりも高いディスク サイズを使用します。Use a disk size that offers scale limits greater than your application requirement.
VM とディスクのスケールの上限VM and Disk Scale Limits 選択した VM サイズの IOPS の上限が、接続されたストレージ ディスクによって引き上げられた総 IOPS を上回る必要があります。IOPS limit of the VM size chosen should be greater than total IOPS driven by storage disks attached to it. 選択した VM サイズのスループットの上限が、VM に接続された Premium Storage ディスクによって引き上げられた総スループットを上回る必要があります。Throughput limit of the VM size chosen should be greater than total Throughput driven by premium storage disks attached to it. 選択した VM サイズのスケールの上限が、接続された Premium Storage ディスクのスケールの上限の合計を上回る必要があります。Scale limits of the VM size chosen must be greater than total scale limits of attached premium storage disks.
ディスク キャッシュDisk Caching 読み取り IOPS を向上させるには、読み取り負荷の高い操作で、Premium Storage ディスクの ReadOnly キャッシュを有効にします。Enable ReadOnly Cache on premium storage disks with Read heavy operations to get higher Read IOPS.   読み取り待機時間を短縮するには、読み取り負荷の高い操作で、Premium Storage ディスクの ReadOnly キャッシュを有効にします。Enable ReadOnly Cache on premium storage disks with Ready heavy operations to get very low Read latencies.
ディスク ストライピングDisk Striping 複数のディスクを使用し、それらのディスクをストライピングすると、IOPS とスループットが集約され、上限が高くなります。Use multiple disks and stripe them together to get a combined higher IOPS and Throughput limit. VM あたりの上限の合計が、接続された Premium ディスクの上限の合計を上回る必要があります。The combined limit per VM should be higher than the combined limits of attached premium disks.    
ストライプ サイズStripe Size OLTP アプリケーションで見られる小さなランダム IO パターンでは、ストライプ サイズを小さくします。Smaller stripe size for random small IO pattern seen in OLTP applications. たとえば、SQL Server OLTP アプリケーションには、64 KB のストライプ サイズを使用します。For example, use stripe size of 64 KB for SQL Server OLTP application. データ ウェアハウス アプリケーションで見られる大きな順次 IO パターンでは、ストライプ サイズを大きくします。Larger stripe size for sequential large IO pattern seen in Data Warehouse applications. たとえば、SQL Server データ ウェアハウス アプリケーションには、256 KB のストライプ サイズを使用します。For example, use 256 KB stripe size for SQL Server Data warehouse application.  
マルチスレッドMultithreading マルチスレッドを使用して、Premium Storage により多くの要求をプッシュすると、IOPS とスループットが向上します。Use multithreading to push higher number of requests to Premium Storage that will lead to higher IOPS and Throughput. たとえば、SQL Server で大きい MAXDOP 値を設定して、より多くの CPU を SQL Server に割り当てます。For example, on SQL Server set a high MAXDOP value to allocate more CPUs to SQL Server.    
キューの深さQueue Depth キューの深さが大きいほど、IOPS が向上します。Larger Queue Depth yields higher IOPS. キューの深さが大きいほど、スループットが向上します。Larger Queue Depth yields higher Throughput. キューの深さが小さいほど、待機時間が短縮されます。Smaller Queue Depth yields lower latencies.

IO 要求の特性Nature of IO requests

IO 要求は、アプリケーションが実行する入力/出力操作の単位です。An IO request is a unit of input/output operation that your application will be performing. IO 要求の特性 (ランダムまたは順次、読み取りまたは書き込み、サイズの大小) を特定すると、アプリケーションのパフォーマンス要件の決定に役立ちます。Identifying the nature of IO requests, random or sequential, read or write, small or large, will help you determine the performance requirements of your application. アプリケーション インフラストラクチャの設計時に適切な判断を下すには、IO 要求の特性を理解することが重要です。It is important to understand the nature of IO requests, to make the right decisions when designing your application infrastructure. 最適なパフォーマンスを実現するには、IO を均等に分散する必要があります。IOs must be distributed evenly to achieve the best performance possible.

IO サイズは、さらに重要な要素の 1 つです。IO size is one of the more important factors. IO サイズは、アプリケーションによって生成される入力/出力操作の要求のサイズです。The IO size is the size of the input/output operation request generated by your application. IO サイズはパフォーマンスに影響を及ぼし、特にアプリケーションが実現できる IOPS と帯域幅に大きな影響を及ぼします。The IO size has a significant impact on performance especially on the IOPS and Bandwidth that the application is able to achieve. 次の式は、IOPS、IO サイズ、帯域幅/スループットの関係を示しています。The following formula shows the relationship between IOPS, IO size, and Bandwidth/Throughput.
IOPS と IO サイズを乗算した結果がスループットになるという等式を示す図。

IO サイズを変更できるアプリケーションもあれば、変更できないアプリケーションもあります。Some applications allow you to alter their IO size, while some applications do not. たとえば、SQL Server では最適な IO サイズが自動的に決定され、ユーザーがこれを変更することはできません。For example, SQL Server determines the optimal IO size itself, and does not provide users with any knobs to change it. 一方、Oracle には、データベースの IO 要求サイズの構成に使用できる DB_BLOCK_SIZE というパラメーターが用意されています。On the other hand, Oracle provides a parameter called DB_BLOCK_SIZE using which you can configure the I/O request size of the database.

IO サイズを変更できないアプリケーションを使用している場合は、この記事のガイドラインを使用して、アプリケーションに最も関係するパフォーマンス KPI を最適化します。If you are using an application, which does not allow you to change the IO size, use the guidelines in this article to optimize the performance KPI that is most relevant to your application. たとえば、次のように入力します。For example,

  • OLTP アプリケーションでは、数百万の小さなランダム IO 要求が生成されます。An OLTP application generates millions of small and random IO requests. この種の IO 要求を処理するには、IOPS が向上するようにアプリケーション インフラストラクチャを設計する必要があります。To handle these types of IO requests, you must design your application infrastructure to get higher IOPS.
  • データ ウェアハウス アプリケーションでは、大きな順次 IO 要求が生成されます。A data warehousing application generates large and sequential IO requests. この種の IO 要求を処理するには、帯域幅またはスループットが向上するようにアプリケーション インフラストラクチャを設計する必要があります。To handle these types of IO requests, you must design your application infrastructure to get higher Bandwidth or Throughput.

IO サイズを変更できるアプリケーションを使用している場合は、他のパフォーマンス ガイドラインに加え、IO サイズの次の経験則を使用します。If you are using an application, which allows you to change the IO size, use this rule of thumb for the IO size in addition to other performance guidelines,

  • IO サイズが小さいほど、IOPS が向上します。Smaller IO size to get higher IOPS. たとえば、OLTP アプリケーションでは 8 KB にします。For example, 8 KB for an OLTP application.
  • IO サイズが大きいほど、帯域幅/スループットが向上します。Larger IO size to get higher Bandwidth/Throughput. たとえば、データ ウェアハウス アプリケーションでは 1024 KB にします。For example, 1024 KB for a data warehouse application.

アプリケーションの IOPS とスループット/帯域幅の計算方法について、例を挙げて説明します。Here is an example on how you can calculate the IOPS and Throughput/Bandwidth for your application. P30 ディスクを使用するアプリケーションがあるとします。Consider an application using a P30 disk. P30 ディスクが実現できる最大 IOPS と最大スループット/帯域幅は、それぞれ 5,000 IOPS、200 MB/秒です。The maximum IOPS and Throughput/Bandwidth a P30 disk can achieve is 5000 IOPS and 200 MB per second respectively. アプリケーションに P30 ディスクの最大 IOPS が必要であり、8 KB のような小さい IO サイズを使用すると、40 MB/秒の帯域幅が得られます。Now, if your application requires the maximum IOPS from the P30 disk and you use a smaller IO size like 8 KB, the resulting Bandwidth you will be able to get is 40 MB per second. しかし、アプリケーションに P30 ディスクの最大スループット/帯域幅が必要であり、1024 KB のような大きい IO サイズを使用すると、IOPS は 200 IOPS に低下します。However, if your application requires the maximum Throughput/Bandwidth from P30 disk, and you use a larger IO size like 1024 KB, the resulting IOPS will be less, 200 IOPS. そのため、アプリケーションの IOPS とスループット/帯域幅の両方の要件を満たすように IO サイズを調整します。Therefore, tune the IO size such that it meets both your application's IOPS and Throughput/Bandwidth requirement. 次の表に、さまざまな IO サイズと、P30 ディスクの対応する IOPS およびスループットを示します。The following table summarizes the different IO sizes and their corresponding IOPS and Throughput for a P30 disk.

アプリケーションの要件Application Requirement I/O サイズI/O size IOPSIOPS スループット/帯域幅Throughput/Bandwidth
最大 IOPSMax IOPS 8 KB8 KB 5,0005,000 40 MB/秒40 MB per second
最大スループットMax Throughput 1024 KB1024 KB 200200 200 MB/秒200 MB per second
最大スループット + 高 IOPSMax Throughput + high IOPS 64 KB64 KB 3,2003,200 200 MB/秒200 MB per second
最大 IOPS + 高スループットMax IOPS + high Throughput 32 KB32 KB 5,0005,000 160 MB/秒160 MB per second

1 つの Premium Storage ディスクの最大値を超える IOPS と帯域幅を得るには、ストライピングされた複数の Premium ディスクを使用します。To get IOPS and Bandwidth higher than the maximum value of a single premium storage disk, use multiple premium disks striped together. たとえば、2 つの P30 ディスクをストライピングすると、10,000 IOPS の合計 IOPS または 400 MB/秒の合計スループットが得られます。For example, stripe two P30 disks to get a combined IOPS of 10,000 IOPS or a combined Throughput of 400 MB per second. 次のセクションで説明するように、ディスクの合計 IOPS と合計スループットをサポートする VM サイズを使用する必要があります。As explained in the next section, you must use a VM size that supports the combined disk IOPS and Throughput.


IOPS とスループットのいずれかを増やすと、もう一方も増加するので、どちらか一方を増やしたときには、ディスクまたは VM のスループットまたは IOPS の上限に達していないことを確認してください。As you increase either IOPS or Throughput the other also increases, make sure you do not hit throughput or IOPS limits of the disk or VM when increasing either one.

IO サイズがアプリケーションのパフォーマンスに及ぼす影響を監視するには、VM とディスクでベンチマーク ツールを実行します。To witness the effects of IO size on application performance, you can run benchmarking tools on your VM and disks. 複数のテスト実行を作成し、実行ごとに異なる IO サイズを使用して影響を確認します。Create multiple test runs and use different IO size for each run to see the impact. 詳細については、ベンチマークに関する記事をご覧ください。この記事の最後にリンクが貼ってあります。Refer to the Benchmarking article, linked at the end, for more details.

高スケール VM サイズHigh scale VM sizes

アプリケーションの設計を始めるときに、最初に行うことの 1 つとして、アプリケーションをホストする VM の選択があります。When you start designing an application, one of the first things to do is, choose a VM to host your application. Premium Storage には、高いコンピューティング能力と高いローカル ディスク I/O パフォーマンスを必要とするアプリケーションを実行できる、高スケール VM サイズが用意されています。Premium Storage comes with High Scale VM sizes that can run applications requiring higher compute power and a high local disk I/O performance. これらの VM は、高速プロセッサ、高いメモリ対コア比、ローカル ディスク用ソリッド ステート ドライブ (SSD) を提供します。These VMs provide faster processors, a higher memory-to-core ratio, and a Solid-State Drive (SSD) for the local disk. Premium Storage をサポートする高スケール VM の例として、DS シリーズ VM、GS シリーズ VM があります。Examples of High Scale VMs supporting Premium Storage are the DS and GS series VMs.

高スケール VM は、CPU コア数、メモリ容量、OS、一時ディスク サイズが異なるさまざまなサイズで提供されます。High Scale VMs are available in different sizes with a different number of CPU cores, memory, OS, and temporary disk size. 各 VM サイズには、VM に接続できるデータ ディスクの最大数も設けられています。Each VM size also has maximum number of data disks that you can attach to the VM. そのため、選択した VM サイズは、アプリケーションで利用できる処理能力、メモリ容量、ストレージ容量に影響します。Therefore, the chosen VM size will affect how much processing, memory, and storage capacity is available for your application. また、計算およびストレージ コストにも影響します。It also affects the Compute and Storage cost. 例として、DS シリーズ、GS シリーズの最大 VM サイズの仕様を次に示します。For example, below are the specifications of the largest VM size in a DS series and a GS series:

VM サイズVM size CPU コア数CPU cores メモリMemory VM のディスク サイズVM disk sizes 最大Max. データ ディスクdata disks キャッシュ サイズCache size IOPSIOPS 帯域幅キャッシュ IO の上限Bandwidth Cache IO limits
Standard_DS14Standard_DS14 1616 112 GB112 GB OS = 1023 GBOS = 1023 GB
ローカル SSD = 224 GBLocal SSD = 224 GB
3232 576 GB576 GB 50,000 IOPS50,000 IOPS
512 MB/秒512 MB per second
4,000 IOPS、33 MB/秒4,000 IOPS and 33 MB per second
Standard_GS5Standard_GS5 3232 448 GB448 GB OS = 1023 GBOS = 1023 GB
ローカル SSD = 896 GBLocal SSD = 896 GB
6464 4224 GB4224 GB 80,000 IOPS80,000 IOPS
2,000 MB/秒2,000 MB per second
5,000 IOPS、50 MB/秒5,000 IOPS and 50 MB per second

利用可能なすべての Azure VM サイズの一覧については、「Azure の仮想マシンのサイズ」を参照してください。To view a complete list of all available Azure VM sizes, refer to Sizes for virtual machines in Azure or . アプリケーションの目的のパフォーマンス要件を満たし、拡張できる VM サイズを選択します。Choose a VM size that can meet and scale to your desired application performance requirements. これに加え、VM サイズを選択するときは、次の重要な考慮事項に注意してください。In addition to this, take into account following important considerations when choosing VM sizes.

スケールの上限Scale Limits
IOPS の上限は、VM あたりとディスクあたりで異なり、互いに独立しています。The maximum IOPS limits per VM and per disk are different and independent of each other. アプリケーションが、VM と VM に接続された Premium ディスクの制限の範囲内で IOPS を引き上げていることを確認します。Make sure that the application is driving IOPS within the limits of the VM as well as the premium disks attached to it. 制限を超えると、アプリケーションのパフォーマンスが調整されます。Otherwise, application performance will experience throttling.

たとえば、アプリケーションの要件が最大 4,000 IOPS であるとします。As an example, suppose an application requirement is a maximum of 4,000 IOPS. これを実現するために、DS1 VM に P30 ディスクをプロビジョニングします。To achieve this, you provision a P30 disk on a DS1 VM. P30 ディスクは、最大 5,000 IOPS を実現できます。The P30 disk can deliver up to 5,000 IOPS. ただし、DS1 VM は 3,200 IOPS に制限されています。However, the DS1 VM is limited to 3,200 IOPS. そのため、アプリケーションのパフォーマンスは、3,200 IOPS という VM の制限による制約を受けることになり、パフォーマンスが低下します。Consequently, the application performance will be constrained by the VM limit at 3,200 IOPS and there will be degraded performance. このような状況を防ぐには、アプリケーションの要件を満たす VM サイズとディスク サイズを選択します。To prevent this situation, choose a VM and disk size that will both meet application requirements.

運用コストCost of Operation
多くの場合、Standard Storage を使用するよりも、Premium Storage を使用する方が全体的な運用コストが削減される可能性があります。In many cases, it is possible that your overall cost of operation using Premium Storage is lower than using Standard Storage.

たとえば、16,000 IOPS を必要とするアプリケーションがあるとします。For example, consider an application requiring 16,000 IOPS. このパフォーマンスを実現するには、Standard_D14 Azure IaaS VM が必要です。Standard_D14 Azure IaaS VM では、32 個の 1 TB Standard Storage ディスクを使用することで、最大 IOPS が 16,000 になります。To achieve this performance, you will need a Standard_D14 Azure IaaS VM, which can give a maximum IOPS of 16,000 using 32 standard storage 1 TB disks. 各 1 TB Standard Storage ディスクは、最大 500 IOPS を実現します。Each 1-TB standard storage disk can achieve a maximum of 500 IOPS. この VM の推定月額料金は 1,570 ドルです。The estimated cost of this VM per month will be $1,570. 32 個の Standard Storage ディスクの月額料金は 1,638 ドルです。The monthly cost of 32 standard storage disks will be $1,638. 推定合計月額料金は 3,208 ドルになります。The estimated total monthly cost will be $3,208.

しかし、Premium Storage で同じアプリケーションをホストした場合、必要な VM サイズが小さくなり、必要な Premium Storage ディスク数も減るので、全体的なコストが削減されます。However, if you hosted the same application on Premium Storage, you will need a smaller VM size and fewer premium storage disks, thus reducing the overall cost. Standard_DS13 VM なら、4 つの P30 ディスクを使用して 16,000 IOPS の要件を満たすことができます。A Standard_DS13 VM can meet the 16,000 IOPS requirement using four P30 disks. DS13 VM の最大 IOPS は 25,600 であり、各 P30 ディスクの最大 IOPS は 5,000 です。The DS13 VM has a maximum IOPS of 25,600 and each P30 disk has a maximum IOPS of 5,000. 全体として、この構成では 5,000 x 4 = 20,000 IOPS を実現できます。Overall, this configuration can achieve 5,000 x 4 = 20,000 IOPS. この VM の推定月額料金は 1,003 ドルです。The estimated cost of this VM per month will be $1,003. 4 つの P30 Premium Storage ディスクの月額料金は 544.34 ドルです。The monthly cost of four P30 premium storage disks will be $544.34. 推定合計月額料金は 1,544 ドルになります。The estimated total monthly cost will be $1,544.

次の表に、このシナリオの Standard Storage と Premium Storage のコストの内訳を示します。Table below summarizes the cost breakdown of this scenario for Standard and Premium Storage.

  StandardStandard PremiumPremium
VM の月額料金Cost of VM per month 1,570.58 ドル (Standard_D14)$1,570.58 (Standard_D14) 1,003.66 ドル (Standard_DS13)$1,003.66 (Standard_DS13)
ディスクの月額料金Cost of Disks per month 1,638.40 ドル (32 x 1 TB ディスク)$1,638.40 (32 x 1-TB disks) 544.34 ドル (4 x P30 ディスク)$544.34 (4 x P30 disks)
合計月額料金Overall Cost per month 3,208.98 ドル$3,208.98 1,544.34 ドル$1,544.34

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

Azure Premium Storage を使用すると、Windows を実行する VM と Linux を実行する VM で同レベルのパフォーマンスが得られます。With Azure Premium Storage, you get the same level of Performance for VMs running Windows and Linux. さまざまな Linux ディストリビューションがサポートされています。リストについては、こちらをご覧ください。We support many flavors of Linux distros, and you can see the complete list here. ワークロードの種類によって、適しているディストリビューションが異なることに注意してください。It is important to note that different distros are better suited for different types of workloads. パフォーマンスのレベルは、ワークロードが実行されるディストリビューションによって異なります。You will see different levels of performance depending on the distro your workload is running on. アプリケーションで Linux ディストリビューションをテストし、最適なディストリビューションを選択します。Test the Linux distros with your application and choose the one that works best.

Premium Storage で Linux を実行するときは、高パフォーマンスを確保するために、必要なドライバーについて最新の更新プログラムを確認してください。When running Linux with Premium Storage, check the latest updates about required drivers to ensure high performance.

Premium Storage のディスク サイズPremium storage disk sizes

Azure Premium Storage ではさまざまなサイズが用意されているため、ニーズに最も適したものを選択できます。Azure Premium Storage offers a variety of sizes so you can choose one that best suits your needs. ディスク サイズによって、IOPS、帯域幅、ストレージのスケールの上限がそれぞれ異なります。Each disk size has a different scale limit for IOPS, bandwidth, and storage. アプリケーションの要件と高スケール VM のサイズに応じて、Premium Storage の適切なディスク サイズを選択します。Choose the right Premium Storage Disk size depending on the application requirements and the high scale VM size. 次の表に、ディスク サイズとその機能を示します。The table below shows the disks sizes and their capabilities. P4、P6、P15、P60、P70、P80 サイズは、現在、Managed Disks のみでサポートされています。P4, P6, P15, P60, P70, and P80 sizes are currently only supported for Managed Disks.

Premium SSD のサイズPremium SSD sizes  P1P1 P2P2 P3P3 P4P4 P6P6 P10P10 P15P15 P20P20 P30P30 P40P40 P50P50 P60P60 P70P70 P80P80
ディスク サイズ (GiB)Disk size in GiB 44 88 1616 3232 6464 128128 256256 512512 1,0241,024 2,0482,048 4,0964,096 8,1928,192 16,38416,384 32,76732,767
ディスクあたりのプロビジョニング済み IOPSProvisioned IOPS per disk 120120 120120 120120 120120 240240 500500 1,1001,100 2,3002,300 5,0005,000 7,5007,500 7,5007,500 16,00016,000 18,00018,000 20,00020,000
ディスクあたりのプロビジョニング済みスループットProvisioned Throughput per disk 25 MB/秒25 MB/sec 25 MB/秒25 MB/sec 25 MB/秒25 MB/sec 25 MB/秒25 MB/sec 50 MB/秒50 MB/sec 100 MB/秒100 MB/sec 125 MB/秒125 MB/sec 150 MB/秒150 MB/sec 200 MB/秒200 MB/sec 250 MB/秒250 MB/sec 250 MB/秒250 MB/sec 500 MB/秒500 MB/sec 750 MB/秒750 MB/sec 900 MB/秒900 MB/sec
ディスクあたりの最大バースト IOPSMax burst IOPS per disk 3,5003,500 3,5003,500 3,5003,500 3,5003,500 3,5003,500 3,5003,500 3,5003,500 3,5003,500
ディスクあたりの最大バースト スループットMax burst throughput per disk 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec 170 MB/秒170 MB/sec
最大バースト時間Max burst duration 30 分30 min 30 分30 min 30 分30 min 30 分30 min 30 分30 min 30 分30 min 30 分30 min 30 分30 min
予約対象Eligible for reservation いいえNo いいえNo いいえNo いいえNo いいえNo いいえNo いいえNo いいえNo はい (最長 1 年)Yes, up to one year はい (最長 1 年)Yes, up to one year はい (最長 1 年)Yes, up to one year はい (最長 1 年)Yes, up to one year はい (最長 1 年)Yes, up to one year はい (最長 1 年)Yes, up to one year

選択するディスク数は、選択したディスク サイズによって異なります。How many disks you choose depends on the disk size chosen. 1 つの P50 ディスクまたは複数の P10 ディスクを使用して、アプリケーションの要件を満たすことができます。You could use a single P50 disk or multiple P10 disks to meet your application requirement. 選択時には以下の考慮事項に注意してください。Take into account considerations listed below when making the choice.

スケールの上限 (IOPS とスループット)Scale Limits (IOPS and Throughput)
IOPS とスループットの上限は、Premium ディスク サイズごとに異なり、VM のスケールの上限から独立しています。The IOPS and Throughput limits of each Premium disk size is different and independent from the VM scale limits. ディスクの総 IOPS と総スループットが、選択した VM サイズのスケールの上限を超えていないことを確認します。Make sure that the total IOPS and Throughput from the disks are within scale limits of the chosen VM size.

たとえば、アプリケーションの要件が最大 250 MB/秒のスループットであり、DS4 VM と 1 つの P30 ディスクを使用しているとします。For example, if an application requirement is a maximum of 250 MB/sec Throughput and you are using a DS4 VM with a single P30 disk. DS4 VM が提供できる最大スループットは 256 MB/秒です。The DS4 VM can give up to 256 MB/sec Throughput. ただし、1 つの P30 ディスクのスループットは 200 MB/秒に制限されています。そのため、アプリケーションは 200 MB/秒というディスクの制限による制約を受けることになります。However, a single P30 disk has Throughput limit of 200 MB/sec. Consequently, the application will be constrained at 200 MB/sec due to the disk limit. この制限を克服するには、VM に複数のデータ ディスクをプロビジョニングするか、ディスクのサイズを P40 または P50 に変更します。To overcome this limit, provision more than one data disks to the VM or resize your disks to P40 or P50.


キャッシュで処理される読み取りはディスクの IOPS とスループットに含まれないので、ディスクの制限の対象にはなりません。Reads served by the cache are not included in the disk IOPS and Throughput, hence not subject to disk limits. キャッシュには、VM あたりの IOPS とスループットの別の上限が設けられています。Cache has its separate IOPS and Throughput limit per VM.

たとえば、最初は読み取りと書き込みがそれぞれ 60MB/秒と 40MB/秒であったとします。For example, initially your reads and writes are 60MB/sec and 40MB/sec respectively. 時間が経つにつれて、キャッシュがウォームアップされ、処理されるキャッシュからの読み取りが増加します。Over time, the cache warms up and serves more and more of the reads from the cache. これにより、ディスクからの書き込みスループットが向上します。Then, you can get higher write Throughput from the disk.

ディスク数Number of Disks
アプリケーションの要件を評価して必要なディスク数を決定します。Determine the number of disks you will need by assessing application requirements. 各 VM サイズにも、VM に接続できるディスク数の上限が設けられています。Each VM size also has a limit on the number of disks that you can attach to the VM. 通常、これはコア数の 2 倍です。Typically, this is twice the number of cores. 選択した VM サイズが必要なディスク数をサポートできることを確認します。Ensure that the VM size you choose can support the number of disks needed.

Premium Storage ディスクは、Standard Storage ディスクよりも高いパフォーマンス機能を備えています。Remember, the Premium Storage disks have higher performance capabilities compared to Standard Storage disks. そのため、Standard Storage を使用する Azure IaaS VM から Premium Storage にアプリケーションを移行する場合、アプリケーションの同等以上のパフォーマンスを実現するために必要な Premium ディスク数が減る可能性があります。Therefore, if you are migrating your application from Azure IaaS VM using Standard Storage to Premium Storage, you will likely need fewer premium disks to achieve the same or higher performance for your application.

ディスク キャッシュDisk caching

Azure Premium Storage を利用する高スケール VM には、BlobCache と呼ばれる多層キャッシュ テクノロジがあります。High Scale VMs that leverage Azure Premium Storage have a multi-tier caching technology called BlobCache. BlobCache では、ホストの RAM とローカル SSD を組み合わせてキャッシュに使用します。BlobCache uses a combination of the host RAM and local SSD for caching. このキャッシュは、Premium Storage の永続ディスクと VM のローカル ディスクで使用できます。This cache is available for the Premium Storage persistent disks and the VM local disks. 既定では、このキャッシュは、OS ディスクでは Read/Write に設定され、Premium Storage でホストされるデータ ディスクでは ReadOnly に設定されます。By default, this cache setting is set to Read/Write for OS disks and ReadOnly for data disks hosted on Premium Storage. Premium Storage ディスクでディスク キャッシュを有効にすると、高スケール VM は基になるディスクのパフォーマンスを上回るきわめて高いレベルのパフォーマンスを実現できます。With disk caching enabled on the Premium Storage disks, the high scale VMs can achieve extremely high levels of performance that exceed the underlying disk performance.


4 TiB 以上のディスクでは、ディスク キャッシュはサポートされていません。Disk Caching is not supported for disks 4 TiB and larger. 複数のディスクが VM に接続されている場合、4 TiB 未満の各ディスクでは、キャッシュがサポートされます。If multiple disks are attached to your VM, each disk that is smaller than 4 TiB will support caching.

Azure ディスクのキャッシュ設定を変更すると、対象となるディスクをデタッチして再アタッチします。Changing the cache setting of an Azure disk detaches and re-attaches the target disk. オペレーティング システム ディスクの場合は、VM が再起動されます。If it is the operating system disk, the VM is restarted. ディスク キャッシュの設定を変更する前に、この中断の影響を受ける可能性があるすべてのアプリケーションまたはサービスを停止します。Stop all applications/services that might be affected by this disruption before changing the disk cache setting. これらの推奨事項に従っていないと、データが破損する可能性があります。Not following those recommendations could lead to data corruption.

BlobCache の機能の詳細については、Inside の Azure Premium Storage に関するブログ記事をご覧ください。To learn more about how BlobCache works, refer to the Inside Azure Premium Storage blog post.

適切なディスク セットでキャッシュを有効にすることが重要です。It is important to enable cache on the right set of disks. Premium ディスクでディスク キャッシュを有効にするかどうかは、そのディスクで処理されるワークロードのパターンによって決まります。Whether you should enable disk caching on a premium disk or not will depend on the workload pattern that disk will be handling. 次の表に、OS ディスクとデータ ディスクの既定のキャッシュ設定を示します。Table below shows the default cache settings for OS and Data disks.

ディスクの種類Disk type 既定のキャッシュ設定Default cache setting
OS ディスクOS disk ReadWriteReadWrite
データ ディスクData disk ReadOnlyReadOnly

データ ディスクの推奨されるディスク キャッシュ設定を次に示します。Following are the recommended disk cache settings for data disks,

ディスク キャッシュ設定Disk caching setting この設定を使用するときの推奨事項recommendation on when to use this setting
なしNone 書き込み専用ディスクと書き込み負荷の高いディスクでは、ホスト キャッシュを None に構成します。Configure host-cache as None for write-only and write-heavy disks.
ReadOnlyReadOnly 読み取り専用ディスクと読み取り/書き込みディスクでは、ホスト キャッシュを ReadOnly に構成します。Configure host-cache as ReadOnly for read-only and read-write disks.
ReadWriteReadWrite アプリケーションが、必要に応じてキャッシュ データの永続ディスクへの書き込みを適切に処理できる場合にのみ、ホスト キャッシュを ReadWrite に構成します。Configure host-cache as ReadWrite only if your application properly handles writing cached data to persistent disks when needed.

Premium Storage データ ディスクの ReadOnly キャッシュを構成することで、読み取り待機時間を減らし、アプリケーションの読み取り IOPS と読み取りスループットを大幅に向上させることができます。By configuring ReadOnly caching on Premium Storage data disks, you can achieve low Read latency and get very high Read IOPS and Throughput for your application. これは、次の 2 つの理由によります。This is due two reasons,

  1. VM のメモリおよびローカル SSD 上のキャッシュから実行される読み取りは、Azure BLOB ストレージ上のデータ ディスクからの読み取りよりもはるかに高速です。Reads performed from cache, which is on the VM memory and local SSD, are much faster than reads from the data disk, which is on the Azure blob storage.
  2. Premium Storage では、ディスクの IOPS とスループットのために、キャッシュからの読み取りはカウントされません。Premium Storage does not count the Reads served from cache, towards the disk IOPS and Throughput. そのため、アプリケーションは、総 IOPS と総スループットを向上させることができます。Therefore, your application is able to achieve higher total IOPS and Throughput.

既定では、OS ディスクは ReadWrite キャッシュが有効になっています。By default, the OS disks have ReadWrite caching enabled. 最近、データ ディスクでも ReadWrite キャッシュのサポートが追加されました。We have recently added support for ReadWrite caching on data disks as well. ReadWrite キャッシュを使用する場合、データをキャッシュから永続ディスクに適切な方法で書き込む必要があります。If you are using ReadWrite caching, you must have a proper way to write the data from cache to persistent disks. たとえば、SQL Server では、永続ストレージ ディスクへのキャッシュ データの書き込みを独自に処理します。For example, SQL Server handles writing cached data to the persistent storage disks on its own. 必要なデータの永続化を処理しないアプリケーションで ReadWrite キャッシュを使用すると、VM がクラッシュした場合にデータが失われる可能性があります。Using ReadWrite cache with an application that does not handle persisting the required data can lead to data loss, if the VM crashes.

現在、 [なし] はデータ ディスクでのみサポートされています。Currently, None is only supported on data disks. OS ディスクではサポートされていません。It is not supported on OS disks. OS ディスクに [なし] を設定した場合、これは内部でオーバーライドされ、 [ReadOnly] に設定されます。If you set None on an OS disk it will override this internally and set it to ReadOnly.

たとえば、次の手順を実行することで、Premium Storage で実行されている SQL Server にこれらのガイドラインを適用できます。As an example, you can apply these guidelines to SQL Server running on Premium Storage by doing the following,

  1. データ ファイルをホストする Premium Storage ディスクに "ReadOnly" キャッシュを構成します。Configure "ReadOnly" cache on premium storage disks hosting data files.
    a.a. データ ページをデータ ディスクから直接取得するよりも、キャッシュから取得する方がはるかに高速であるため、キャッシュからの高速読み取りによって、SQL Server のクエリ時間が短縮されます。The fast reads from cache lower the SQL Server query time since data pages are retrieved much faster from the cache compared to directly from the data disks.
    b.b. キャッシュからの読み取りに対応すると、Premium データ ディスクで提供される追加のスループットが得られます。Serving reads from cache, means there is additional Throughput available from premium data disks. SQL Server は、さらに多くのデータ ページの取得や、バックアップと復元、バッチ読み込み、インデックスの再構築などの他の操作のために、この追加のスループットを使用できます。SQL Server can use this additional Throughput towards retrieving more data pages and other operations like backup/restore, batch loads, and index rebuilds.
  2. ログ ファイルをホストする Premium Storage ディスクに "None" キャッシュを構成します。Configure "None" cache on premium storage disks hosting the log files.
    a.a. ログ ファイルの操作は、主に書き込み負荷の高い操作です。Log files have primarily write-heavy operations. そのため、ReadOnly キャッシュによるメリットはありません。Therefore, they do not benefit from the ReadOnly cache.

Linux VM のパフォーマンスの最適化Optimize performance on Linux VMs

すべての Premium SSD や Ultra Disks では、データが失われる可能性のあるキャッシュがないことがわかっている場合、パフォーマンスを向上させるために、ディスク上のファイル システムの "バリア" を無効にすることができる場合があります。For all premium SSDs or ultra disks, you may be able to disable “barriers” for file systems on the disk in order to improve performance when it is known that there are no caches that could lose data. Azure ディスク キャッシュが ReadOnly または None に設定されている場合、バリアを無効にすることができます。If Azure disk caching is set to ReadOnly or None, you can disable barriers. ただし、キャッシュが ReadWrite に設定されている場合は、書き込み耐久性を維持するためにバリアを有効にしたままにしておく必要があります。But if caching is set to ReadWrite, barriers should remain enabled to ensure write durability. バリアは通常、デフォルトで有効になっていますが、ファイル システムの種類に応じて、以下のいずれかの方法でバリアを無効にすることができます。Barriers are typically enabled by default, but you can disable barriers using one of the following methods depending on the file system type:

  • reiserFS の場合、barrier=none マウント オプションを使用してバリアを無効にします。For reiserFS, use the barrier=none mount option to disable barriers. バリアを明示的に有効にするには、barrier=flush を使用します。To explicitly enable barriers, use barrier=flush.
  • ext3/ext4 の場合、barrier=0 マウント オプションを使用してバリアを無効にします。For ext3/ext4, use the barrier=0 mount option to disable barriers. バリアを明示的に有効にするには、barrier=1 を使用します。To explicitly enable barriers, use barrier=1.
  • XFS の場合、nobarrier マウント オプションを使用してバリアを無効にします。For XFS, use the nobarrier mount option to disable barriers. バリアを明示的に有効にするには、barrier を使用します。To explicitly enable barriers, use barrier. 新しいバージョンの Linux カーネルでは、XFS ファイル システムの設計によって耐久性が常に確保されているため、バリアを無効にしても効果がないことに注意してください。Note that in later Linux kernel versions, the design of XFS file system always ensures durability, and disabling barriers has no effect.

ディスク ストライピングDisk striping

高スケール VM が Premium Storage の複数の永続ディスクに接続されている場合、ディスクをストライピングすることで、IOPS、帯域幅、ストレージ容量を集約できます。When a high scale VM is attached with several premium storage persistent disks, the disks can be striped together to aggregate their IOPs, bandwidth, and storage capacity.

Windows では、記憶域スペースを使用してディスクをストライピングできます。On Windows, you can use Storage Spaces to stripe disks together. プールのディスクごとに 1 つの列を構成する必要があります。You must configure one column for each disk in a pool. そうしないと、ディスク間でのトラフィックの分散が不均等になるため、ストライプ ボリュームの全体的なパフォーマンスが予想よりも低くなる可能性があります。Otherwise, the overall performance of striped volume can be lower than expected, due to uneven distribution of traffic across the disks.

重要:サーバー マネージャーの UI を使用して、ストライプ ボリュームの列の総数を最大 8 列に設定できます。Important: Using Server Manager UI, you can set the total number of columns up to 8 for a striped volume. 8 個を超えるディスクを接続するときは、PowerShell を使用してボリュームを作成します。When attaching more than eight disks, use PowerShell to create the volume. PowerShell を使用すると、列数をディスクと同じ数に設定できます。Using PowerShell, you can set the number of columns equal to the number of disks. たとえば、1 つのストライプ セットに 16 個のディスクがある場合、New-VirtualDisk PowerShell コマンドレットの NumberOfColumns パラメーターで 16 列を指定します。For example, if there are 16 disks in a single stripe set; specify 16 columns in the NumberOfColumns parameter of the New-VirtualDisk PowerShell cmdlet.

Linux では、MDADM ユーティリティを使用してディスクをストライピングします。On Linux, use the MDADM utility to stripe disks together. Linux でのディスク ストライピングの詳しい手順については、「 Linux でのソフトウェア RAID の構成」をご覧ください。For detailed steps on striping disks on Linux refer to Configure Software RAID on Linux.

ストライプ サイズStripe Size
ディスク ストライピングの重要な構成の 1 つに、ストライプ サイズがあります。An important configuration in disk striping is the stripe size. ストライプ サイズ (ブロック サイズ) は、アプリケーションがストライプ ボリュームで対応できるデータの最小チャンクです。The stripe size or block size is the smallest chunk of data that application can address on a striped volume. 構成するストライプ サイズは、アプリケーションの種類と要求パターンによって異なります。The stripe size you configure depends on the type of application and its request pattern. 間違ったストライプ サイズを選択すると、IO の不均衡が生じ、アプリケーションのパフォーマンスが低下する可能性があります。If you choose the wrong stripe size, it could lead to IO misalignment, which leads to degraded performance of your application.

たとえば、アプリケーションによって生成された IO 要求がディスクのストライプ サイズよりも大きい場合、ストレージ システムは、複数のディスクのストライプ ユニット境界にまたがって要求を書き込みます。For example, if an IO request generated by your application is bigger than the disk stripe size, the storage system writes it across stripe unit boundaries on more than one disk. 該当のデータにアクセスするときが来ると、要求を完了するために複数のストライプ ユニットにわたってシークしなければなりません。When it is time to access that data, it will have to seek across more than one stripe units to complete the request. このような動作の累積的影響により、パフォーマンスが大幅に低下する可能性があります。The cumulative effect of such behavior can lead to substantial performance degradation. 一方、IO 要求サイズがストライプ サイズよりも小さい場合や、要求の特性がランダムの場合、IO 要求が同じディスクに追加されていく可能性があり、これがボトルネックとなって、最終的に IO パフォーマンスが低下することがあります。On the other hand, if the IO request size is smaller than stripe size, and if it is random in nature, the IO requests may add up on the same disk causing a bottleneck and ultimately degrading the IO performance.

アプリケーションが実行するワークロードの種類に応じて、適切なストライプ サイズを選択します。Depending on the type of workload your application is running, choose an appropriate stripe size. 小さなランダム IO 要求には、小さいストライプ サイズを使用します。For random small IO requests, use a smaller stripe size. 一方、大きな順次 IO 要求には、大きいストライプ サイズを使用します。Whereas for large sequential IO requests use a larger stripe size. Premium Storage で実行するアプリケーションについて、ストライプ サイズの推奨事項を確認します。Find out the stripe size recommendations for the application you will be running on Premium Storage. SQL Server の場合、OLTP ワークロードには 64 KB、データ ウェアハウス ワークロードには 256 KB のストライプ サイズを構成します。For SQL Server, configure stripe size of 64 KB for OLTP workloads and 256 KB for data warehousing workloads. 詳細については、「 Azure Virtual Machines における SQL Server のパフォーマンスに関するベスト プラクティス 」をご覧ください。See Performance best practices for SQL Server on Azure VMs to learn more.


ストライピングできる Premium Storage ディスクの最大数は、DS シリーズ VM では 32 個、GS シリーズ VM では 64 個です。You can stripe together a maximum of 32 premium storage disks on a DS series VM and 64 premium storage disks on a GS series VM.


Azure では、超並列のプラットフォームとして Premium Storage が設計されました。Azure has designed Premium Storage platform to be massively parallel. そのため、マルチスレッド アプリケーションは、シングルスレッド アプリケーションよりもはるかに高いパフォーマンスを実現します。Therefore, a multi-threaded application achieves much higher performance than a single-threaded application. マルチスレッド アプリケーションでは、タスクを複数のスレッドに分割し、VM とディスクのリソースを最大限に活用することで実行効率を高めます。A multi-threaded application splits up its tasks across multiple threads and increases efficiency of its execution by utilizing the VM and disk resources to the maximum.

たとえば、アプリケーションが 2 つのスレッドを使用して単一コアの VM で実行されている場合、CPU は 2 つのスレッドを切り替えて効率化できます。For example, if your application is running on a single core VM using two threads, the CPU can switch between the two threads to achieve efficiency. 一方のスレッドがディスク IO の完了を待機している間、CPU はもう一方のスレッドに切り替えることができます。While one thread is waiting on a disk IO to complete, the CPU can switch to the other thread. このようにして、2 つのスレッドは単一のスレッドよりも多くの処理を実行できます。In this way, two threads can accomplish more than a single thread would. VM に複数のコアがある場合、各コアがタスクを並行して実行できるので、実行時間がさらに短縮されます。If the VM has more than one core, it further decreases running time since each core can execute tasks in parallel.

市販のアプリケーションでは、シングルスレッドまたはマルチスレッドの実装方法を変更できないことがあります。You may not be able to change the way an off-the-shelf application implements single threading or multi-threading. たとえば、SQL Server はマルチ CPU とマルチコアに対応できます。For example, SQL Server is capable of handling multi-CPU and multi-core. ただし、クエリを処理するときに、どのような条件下で 1 つまたは複数のスレッドを利用するかは SQL Server が決定します。However, SQL Server decides under what conditions it will leverage one or more threads to process a query. SQL Server は、マルチスレッドを使用してクエリを実行し、インデックスを構築できます。It can run queries and build indexes using multi-threading. クエリで大規模なテーブルを結合し、データをユーザーに返す前に並べ替える必要がある場合、SQL Server は複数のスレッドを使用すると考えられます。For a query that involves joining large tables and sorting data before returning to the user, SQL Server will likely use multiple threads. ただし、SQL Server がクエリを実行する際に単一のスレッドと複数のスレッドのどちらを使用するかをユーザーが制御することはできません。However, a user cannot control whether SQL Server executes a query using a single thread or multiple threads.

アプリケーションのこのマルチスレッド (並列処理) に影響を与える変更可能な構成設定があります。There are configuration settings that you can alter to influence this multi-threading or parallel processing of an application. たとえば、SQL Server の場合、"並列処理の最大限度" 構成がこれに該当します。For example, in case of SQL Server it is the maximum Degree of Parallelism configuration. MAXDOP と呼ばれるこの設定では、SQL Server が並列処理時に使用できるプロセッサの最大数を構成できます。This setting called MAXDOP, allows you to configure the maximum number of processors SQL Server can use when parallel processing. 個々のクエリやインデックス操作の MAXDOP を構成できます。You can configure MAXDOP for individual queries or index operations. これは、パフォーマンス クリティカルなアプリケーションのためにシステムのリソースのバランスをとる場合に役立ちます。This is beneficial when you want to balance resources of your system for a performance critical application.

たとえば、SQL Server を使用するアプリケーションが、大規模なクエリとインデックス操作を同時に実行しているとします。For example, say your application using SQL Server is executing a large query and an index operation at the same time. 大規模なクエリよりも、インデックス操作のパフォーマンスを高める必要があると仮定します。Let us assume that you wanted the index operation to be more performant compared to the large query. このような場合、インデックス操作の MAXDOP 値を、クエリの MAXDOP 値よりも大きい値に設定します。In such a case, you can set MAXDOP value of the index operation to be higher than the MAXDOP value for the query. これにより、SQL Server は大規模なクエリに割り当てることができるプロセッサよりも多くのプロセッサをインデックス操作に利用できます。This way, SQL Server has more number of processors that it can leverage for the index operation compared to the number of processors it can dedicate to the large query. SQL Server が各操作に使用するスレッドの数を制御するわけではないことに注意してください。Remember, you do not control the number of threads SQL Server will use for each operation. 制御できるのは、マルチスレッド専用のプロセッサの最大数です。You can control the maximum number of processors being dedicated for multi-threading.

SQL Server の 並列処理の次数 の詳細をご覧ください。Learn more about Degrees of Parallelism in SQL Server. アプリケーションのマルチスレッドに影響を与えるこのような設定とパフォーマンスを最適化する構成を確認してください。Find out such settings that influence multi-threading in your application and their configurations to optimize performance.

キューの深さQueue depth

キューの深さ (キューの長さまたはキューのサイズ) は、システムで保留中の IO 要求の数です。The queue depth or queue length or queue size is the number of pending IO requests in the system. キューの深さの値によって、アプリケーションが準備できる IO 操作の数が決まります。IO 操作はストレージ ディスクによって処理されます。The value of queue depth determines how many IO operations your application can line up, which the storage disks will be processing. これは、この記事で説明したアプリケーションの 3 つのパフォーマンス指標 (IOPS、スループット、待機時間) のすべてに影響します。It affects all the three application performance indicators that we discussed in this article viz., IOPS, throughput, and latency.

キューの深さとマルチスレッドは密接に関係しています。Queue Depth and multi-threading are closely related. キューの深さの値は、アプリケーションがどの程度のマルチスレッドを実現できるかを示します。The Queue Depth value indicates how much multi-threading can be achieved by the application. キューの深さが大きい場合、アプリケーションはより多くの操作を同時に実行できます。つまり、マルチスレッドのスレッド数が多いということです。If the Queue Depth is large, application can execute more operations concurrently, in other words, more multi-threading. キューの深さが小さい場合、アプリケーションは、マルチスレッド化されていても、同時実行できるだけの十分な数の要求を準備できなくなります。If the Queue Depth is small, even though application is multi-threaded, it will not have enough requests lined up for concurrent execution.

通常、市販のアプリケーションでは、キューの深さを変更することはできません。これは、キューの深さが正しく設定されていないと、メリットよりもデメリットの方が大きくなるからです。Typically, off the shelf applications do not allow you to change the queue depth, because if set incorrectly it will do more harm than good. 最適なパフォーマンスを得るために、アプリケーションによってキューの深さの適切な値が設定されます。Applications will set the right value of queue depth to get the optimal performance. ただし、アプリケーションで発生するパフォーマンスの問題をトラブルシューティングできるように、この概念を理解しておくことが重要です。However, it is important to understand this concept so that you can troubleshoot performance issues with your application. また、システムでベンチマーク ツールを実行することによって、キューの深さの影響を確認できます。You can also observe the effects of queue depth by running benchmarking tools on your system.

一部のアプリケーションには、キューの深さに影響を与える設定が用意されています。Some applications provide settings to influence the Queue Depth. 例として、前のセクションで説明した SQL Server の MAXDOP (並列処理の最大限度) 設定が挙げられます。For example, the MAXDOP (maximum degree of parallelism) setting in SQL Server explained in previous section. MAXDOP は、SQL Server のキューの深さの値を直接変更するわけではありませんが、キューの深さとマルチスレッドに影響を及ぼします。MAXDOP is a way to influence Queue Depth and multi-threading, although it does not directly change the Queue Depth value of SQL Server.

大きなキューの深さHigh queue depth
キューの深さが大きい場合、ディスク上での操作が増えます。A high queue depth lines up more operations on the disk. ディスクは、キューにある次の要求を事前に認識します。The disk knows the next request in its queue ahead of time. そのため、ディスクは操作を事前にスケジュールし、最適な順序で操作を処理できます。Consequently, the disk can schedule operations ahead of time and process them in an optimal sequence. アプリケーションがディスクに送信する要求が増えるので、ディスクはより多くの並列 IO を処理できます。Since the application is sending more requests to the disk, the disk can process more parallel IOs. 最終的に、アプリケーションは IOPS を向上させることができます。Ultimately, the application will be able to achieve higher IOPS. アプリケーションが処理する要求が増えるので、アプリケーションの総スループットも向上します。Since application is processing more requests, the total Throughput of the application also increases.

通常、アプリケーションは、接続されたディスクごとに 8 ~ 16 個以上の未処理の IO がある状態のときに最大スループットを実現できます。Typically, an application can achieve maximum Throughput with 8-16+ outstanding IOs per attached disk. キューの深さが 1 の場合、アプリケーションはシステムに十分な数の IO をプッシュしなくなり、一定期間の処理量が減少します。If a queue depth is one, application is not pushing enough IOs to the system, and it will process less amount of in a given period. つまり、スループットが低下します。In other words, less Throughput.

たとえば、SQL Server でクエリの MAXDOP 値を "4" に設定すると、クエリの実行に最大 4 つのコアを使用できることが SQL Server に通知されます。For example, in SQL Server, setting the MAXDOP value for a query to "4" informs SQL Server that it can use up to four cores to execute the query. SQL Server は、クエリの実行に最適なキューの深さの値とコア数を決定します。SQL Server will determine what is best queue depth value and the number of cores for the query execution.

最適なキューの深さOptimal queue depth
キューの深さの値が非常に大きい場合、欠点もあります。Very high queue depth value also has its drawbacks. キューの深さの値が大きすぎると、アプリケーションは IOPS を大幅に引き上げようとします。If queue depth value is too high, the application will try to drive very high IOPS. IOPS が十分にプロビジョニングされた永続ディスクをアプリケーションが使用できる場合を除き、これはアプリケーションの待機時間に悪影響を及ぼす可能性があります。Unless application has persistent disks with sufficient provisioned IOPS, this can negatively affect application latencies. 次の式は、IOPS、待機時間、キューの深さの関係を示しています。Following formula shows the relationship between IOPS, latency, and queue depth.
IOPS と待機時間を乗算した結果がキューの深さになるという等式を示す図。A diagram showing the equation I O P S times latency equals Queue Depth.

キューの深さを大きな値に構成するのではなく、待機時間に影響を及ぼさずにアプリケーションに十分な IOPS を提供できる最適な値に構成します。You should not configure Queue Depth to any high value, but to an optimal value, which can deliver enough IOPS for the application without affecting latencies. たとえば、アプリケーションの待機時間を 1 ミリ秒にする必要がある場合、5,000 IOPS を実現するために必要なキューの深さは、QD = 5000 x 0.001 = 5 になります。For example, if the application latency needs to be 1 millisecond, the Queue Depth required to achieve 5,000 IOPS is, QD = 5000 x 0.001 = 5.

ストライプ ボリュームのキューの深さQueue Depth for Striped Volume
ストライプ ボリュームの場合、すべてのディスクのキューの深さがそれぞれピーク時のキューの深さになるように、十分なキューの深さを維持します。For a striped volume, maintain a high enough queue depth such that, every disk has a peak queue depth individually. たとえば、キューの深さ 2 をプッシュするアプリケーションがあり、ストライプに 4 つのディスクがあるとします。For example, consider an application that pushes a queue depth of 2 and there are four disks in the stripe. 2 つの IO 要求が 2 つのディスクに送信されると、残りの 2 つのディスクはアイドル状態になります。The two IO requests will go to two disks and remaining two disks will be idle. そのため、すべてのディスクがビジー状態になるようにキューの深さを構成します。Therefore, configure the queue depth such that all the disks can be busy. 次の式は、ストライプ ボリュームのキューの深さを決定する方法を示しています。Formula below shows how to determine the queue depth of striped volumes.
ディスクあたりの QD とボリュームあたりの列数を乗算した結果がストライプ ボリュームの QD になるという等式を示す図A diagram showing the equation Q D per Disk times number of columns per volume equals Q D of Striped Volume.


Azure Premium Storage では、選択された VM サイズとディスク サイズに応じて、指定された数の IOPS とスループットがプロビジョニングされます。Azure Premium Storage provisions specified number of IOPS and Throughput depending on the VM sizes and disk sizes you choose. アプリケーションが、VM またはディスクが対応できるこれらの上限を超えて IOPS やスループットを引き上げようとすると、これを抑制するように調整されます。Anytime your application tries to drive IOPS or Throughput above these limits of what the VM or disk can handle, Premium Storage will throttle it. これは、アプリケーションのパフォーマンスの低下という形で現れます。This manifests in the form of degraded performance in your application. これにより、待機時間が長くなり、スループットや IOPS が低下する可能性があります。This can mean higher latency, lower Throughput, or lower IOPS. Premium Storage によって調整が行われないと、リソースが対応できる範囲を上回り、アプリケーションが完全に失敗する可能性があります。If Premium Storage does not throttle, your application could completely fail by exceeding what its resources are capable of achieving. そのため、調整によるパフォーマンスの問題を回避するために、常にアプリケーションの十分なリソースをプロビジョニングします。So, to avoid performance issues due to throttling, always provision sufficient resources for your application. 前の VM サイズとディスク サイズのセクションで説明した考慮事項に注意してください。Take into consideration what we discussed in the VM sizes and Disk sizes sections above. ベンチマークは、アプリケーションをホストするために必要なリソースを把握するための最適な方法です。Benchmarking is the best way to figure out what resources you will need to host your application.

次のステップNext steps

ディスクのベンチマークを実行する場合は、ディスクのベンチマークに関する記事を参照してください。If you are looking to benchmark your disk, see our articles on benchmarking a disk:

使用できるディスクの種類については、次のページを参照してください。Learn more about the available disk types:

SQL Server ユーザーは、SQL Server のパフォーマンスのベスト プラクティスに関する次の記事をご覧ください。For SQL Server users, read articles on Performance Best Practices for SQL Server: