Persistent Disk は、ディスクタイプの表で示したパフォーマンスを実現できますが、VM の使用量が十分でないとパフォーマンスの上限を達成することはできません。パフォーマンスのニーズに合わせて Persistent Disk ボリューム サイズを調整した後、ワークロードとオペレーティングシステムのチューニングが必要になることがあります。
以下のセクションでは、ディスクのパフォーマンスに影響する VM とワークロードの特性について説明し、パフォーマンス向上のためにチューニングできるいくつかの重要な要素について説明します。いくつかの提案を行い、それらを特定のタイプのワークロードに適用する方法についても説明します。
ディスク パフォーマンスに影響する要因
以降のセクションでは、VM のディスク パフォーマンスに影響を与える要因について説明します。
書き込みスループットの下り（外向き）ネットワークの上限
VM には、VM のマシンタイプに応じて下り（外向き）ネットワークの上限があります。
Compute Engine は、複数の並列書き込みで Persistent Disk にデータを保存し、冗長性を確保します。また、各書き込みリクエストには、追加の書き込み帯域幅を使用するオーバーヘッドが多少あります。
VM インスタンスが送信できる書き込みトラフィックの最大量は、レプリケーションとオーバーヘッドから成る帯域幅乗数で下り（外向き）ネットワークの上限を割った値です。
下り（外向き）ネットワークの上限は、汎用、コンピューティング最適化、ストレージ最適化、メモリ最適化、アクセラレータ最適化などのマシン ファミリーのマシンタイプ テーブルで、最大下り（外向き）帯域幅（Gbps）列に一覧表示されています。
帯域幅乗数はネットワーク全体の使用率で約 1.16 倍になるため、書き込まれたバイト数の 16% がオーバーヘッドになります。リージョン Persistent Disk の場合、帯域幅乗数は、追加のレプリケーション オーバーヘッドを考慮すると約 2.32 倍です。
Persistent Disk の読み取り / 書き込みオペレーションが下り（外向き）ネットワーク帯域幅と競合する状況では、マシンタイプで定義された下り（外向き）ネットワークの最大帯域幅の 60% が Persistent Disk の書き込みに割り当てられます。残りの 40% が、他のすべての下り（外向き）トラフィックに利用されます。他の下り（外向き）ネットワーク トラフィックの詳細については、下り（外向き）帯域幅をご覧ください。
次の例は、N1 VM インスタンス上の Persistent Disk の最大書き込み帯域幅を計算する方法を示しています。帯域幅の割り当ては、Persistent Disk に割り当てられる下り（外向き）ネットワークの部分です。最大書き込み帯域幅は、オーバーヘッドを考慮して調整された Persistent Disk の最大書き込み帯域幅です。
| VM の vCPU 数 | 下り（外向き）ネットワークの上限（MB/秒） | 帯域幅の割り当て（MB/秒） | 最大書き込み帯域幅（MB/秒） | 完全なネットワーク使用率での最大書き込み帯域幅（MB/秒） |
|---|---|---|---|---|
| 1 | 250 | 150 | 216 | 129 |
| 2-7 | 1,250 | 750 | 1,078 | 647 |
| 8～15 | 2,000 | 1,200 | 1,724 | 1,034 |
| 16+ | 4,000 | 2,400 | 3,448 | 2,069 |
Persistent Disk の最大帯域幅は、次の式で計算できます。
1 個の vCPU を備えた N1 VM
下り（外向き）ネットワークの上限は次のとおりです。
2 Gbps / 8 ビット = 0.25 GB/秒 = 250 MB/秒
完全なネットワーク使用率での Persistent Disk の帯域幅の割り当ては次のとおりです。
250 MB/秒 × 0.6 = 150 MB/秒。
ネットワーク競合のない Persistent Disk の最大書き込み帯域幅は次のとおりです。
- ゾーンディスク: 250 MB/秒 / 1.16～= 216 MB/秒
- リージョン ディスク: 250 MB/秒 / 2.32～= 108 MB/秒
完全なネットワーク使用率での Persistent Disk の最大書き込み帯域幅は次のとおりです。
- ゾーンディスク: 150 MB/秒 / 1.16～= 129 MB/秒
- リージョン ディスク: 150 MB/秒 / 2.32～= 65 MB/秒
下り（外向き）ネットワークの上限は、パフォーマンスの上限となります。他の要因によってパフォーマンスが制限され、このレベルを下回ることがあります。その他のパフォーマンスの制約については、次のセクションをご覧ください。
同時読み書き
標準 Persistent Disk の場合、同時に行われる読み書き込みは同じリソースを共有します。VM で読み取りスループットまたは IOPS が大きくなると、実行できる書き込み量が少なくなります。反対に、インスタンスで書き込みスループットまたは IOPS が大きくなると、実行できる読み取り量が少なくなります。
Persistent Disk の読み取りと書き込みの両方で最大スループットと IOPS の上限に達することはありません。
スループットは IOPS * I/O size で計算されます。SSD Persistent Disk 上の同時読み書きで最大スループット上限を利用するには、読み取り IOPS と書き込み IOPS を合わせた値が IOPS 上限を超えないような I/O サイズを使用します。
次の表に、同時読み書きでの VM あたりの IOPS の上限を示します。
| 標準 Persistent Disk | SSD 永続ディスク（8 vCPU） | SSD 永続ディスク（32 vCPU 以上） | SSD 永続ディスク（64 vCPU 以上） | ||||
|---|---|---|---|---|---|---|---|
| 読み取り | 書き込み | 読み取り | 書き込み | 読み取り | 書き込み | 読み取り | 書き込み |
| 7,500 | 0 | 15,000 | 0 | 60,000 | 0 | 100,000 | 0 |
| 5,625 | 3,750 | 11,250 | 3,750 | 45,000 | 15,000 | 75,000 | 25,000 |
| 3,750 | 7,500 | 7,500 | 7,500 | 30,000 | 30,000 | 50,000 | 50,000 |
| 1875 | 11,250 | 3,750 | 11,250 | 15,000 | 45,000 | 25,000 | 75,000 |
| 0 | 15,000 | 0 | 15,000 | 0 | 60,000 | 0 | 100,000 |
この表の IOPS 値は、8 KB の I/O サイズに基づいています。16 KB など他の I/O サイズでは IOPS 値も異なりますが、読み取りと書き取りの配分は同じです。
次の表に、同時読み書きでの VM あたりのスループットの上限（MB/秒）を示します。
| 標準 Persistent Disk | SSD 永続ディスク（6～14 vCPU） | SSD 永続ディスク（16 vCPU 以上） | |||
|---|---|---|---|---|---|
| 読み取り | 書き込み | 読み取り | 書き込み | 読み取り | 書き込み |
| 1200 | 0 | 800* | 800* | 1,200* | 1,200* |
| 900 | 100 | ||||
| 600 | 200 | ||||
| 300 | 300 | ||||
| 0 | 400 | ||||
論理ボリューム サイズ
Persistent Disk のサイズの上限は 64 TiB で、VM 内の論理ボリューム管理機能を使用して、最大 257 TiB の単一論理ボリュームを作成できます。ボリューム サイズが大きくなると、次のようにパフォーマンスに影響を及ぼします。
- すべてのローカル ファイル システムに、このスケールが適しているわけではありません。マウントやファイル システムのチェックなどの一般的な操作には、時間がかかる場合があります。
- Persistent Disk の最大パフォーマンスは、小さいサイズの方が高くなります。1 つの VM でこの大きさのストレージをすべて読み取りや書き込みするには、ディスクでの処理に時間がかかります。アプリケーションが対応している場合は、複数の VM を使用して、システム全体のスループットを向上させることを検討してください。
- 多数の Persistent Disk のスナップショットを取ると、完了まで予想以上に時間がかかる場合があり、アプリケーションとの密な連携が行われず、論理ボリュームのビューに矛盾が生じる可能性があります。
1 つの VM インスタンスに複数のディスクをアタッチ
VM に複数のディスクをアタッチしている場合のディスクのパフォーマンス上限は、ディスクの種類が同じかどうかによって異なります。
同じタイプの複数のディスク
同じタイプの複数のディスクを同じモードの VM インスタンス（読み取り/書き込みなど）にアタッチしている場合、パフォーマンスの上限はそれらのディスクの合計サイズである単一ディスクの上限と同じになります。すべてのディスクを 100% 使用する場合、相対的なディスクサイズに関係なく、全体的なパフォーマンスの上限はディスク間で均等に分割されます。
たとえば、200 GB の pd-standard ディスクと 1,000 GB の pd-standard ディスクがあるとします。1,000 GB のディスクを使用しない場合、200 GB のディスクは 1,200 GB の標準ディスクのパフォーマンス上限に達する可能性があります。両方のディスクを 100% 使用する場合、それぞれの pd-standard ディスクのパフォーマンス上限は 600 GB になります（1,200 GB ÷ 2 つのディスク = 1 ディスクあたり 600 GB）。
異なるタイプの複数のディスク
さまざまな種類のディスクを VM にアタッチする場合、可能な最大のパフォーマンスは、VM でサポートされる最速のディスクのパフォーマンス上限です。アタッチされたディスクの累積パフォーマンスは、VM でサポートされている最速ディスクのパフォーマンス上限を超えません。
IOPS またはスループット指向のワークロードに合わせてディスクを最適化する
パフォーマンスの推奨事項は、IOPS とスループットのどちらを最大化するかによって異なります。
IOPS 指向のワークロード
SQL か NoSQL かを問わず、データベースはデータへランダムにアクセスする傾向があります。IOPS 指向のワークロードに対する Google の推奨値は次のとおりです。
I/O キューの深さの値は 400～800 IOPS あたり 1 にし、大きなボリュームでは上限を 64 にします
空き CPU の数を、ランダム読み取り 2,000 IOPS ごとに 1 基、ランダム書き込み 2,500 IOPS ごとに 1 基にします。
VM マシンタイプに使用できる場合は、Google Cloud Hyperdisk Extreme ディスクを使用します。これにより、プロビジョニングされた IOPS を変更できます。
MongoDB、Apache Cassandra、その他のデータベース アプリケーションのベスト プラクティスに関するドキュメントでは、通常、先読み量を少なくするよう推奨されています。
スループット指向のワークロード
Hadoop ジョブのようなストリーミング オペレーションのパフォーマンスは、高速な順次読み取りによって向上します。I/O サイズが大きいほど、ストリーミングのパフォーマンスは向上します。
I/O サイズを 256 KB 以上にします。
VM マシンタイプに使用できる場合は、Hyperdisk Throughput ディスクを使用します。これにより、プロビジョニングされたスループットを変更できます。
標準 Persistent Disk の場合、可能であれば 8 以上の並列順次 I/O ストリームを使用します。標準 Persistent Disk は、物理 HDD ハードドライブと同じようにディスクのシーケンシャル アクセスの I/O パフォーマンスを最適化するように設計されています。
大容量ディスク上で合理的な時間的データ局所性を実現するようにアプリケーションが最適化されていることを確認します
短い期間にアプリケーションからディスクの各所に分散するデータにアクセスしている状態では（vCPU あたり数百 GB）、最適な IOPS を達成できません。最高のパフォーマンスを得るには、データの時間的局所性、ディスク断片化などの重み付け要因、アクセスしているディスク部分のランダム性を調べて最適化を図る必要があります。
SSD Persistent Disk の場合、オペレーティング システムの I/O スケジューラが特定のニーズを満たすように構成されていることを確認します。
Linux ベースのシステムで、I/O スケジューラが
noneに設定されているかどうかを確認します。この I/O スケジューラはリクエストの順序を変更しないため、高速なランダム I/O デバイスに最適です。コマンドラインで、Linux マシンで使用されている I/O スケジュールを確認します。
cat /sys/block/sda/queue/scheduler
出力は次のようになります。
[mq-deadline] none
現在アクティブな I/O スケジューラは、角かっこ（
[]）付きで表示されます。I/O スケジューラが
noneに設定されていない場合は、次のいずれかを行います。- デフォルトの I/O スケジューラを
noneに変更するには、GRUB 構成ファイルのGRUB_CMDLINE_LINUXエントリでelevator=noneを設定します。通常、このファイルは/etc/default/grubにありますが、以前のディストリビューションでは、別のディレクトリに存在することもあります。
GRUB_CMDLINE_LINUX="elevator=none vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16
GRUB 構成ファイルを更新したら、システム上でブートローダーを構成して、Compute Engine 上で起動できるようにします。
- また、ランタイムに I/O スケジューラを変更することもできます。
echo 'none' > sudo /sys/block/sda/queue/scheduler
この方法を使用した場合、再起動時にシステムがデフォルトの I/O スケジューラに戻ります。
catコマンドを再度実行して、I/O スケジューラを確認します。- デフォルトの I/O スケジューラを
ディスクのパフォーマンスを改善できるワークロードの変更
ワークロードの動作によっては、アタッチされたディスクの I/O オペレーションのパフォーマンスが向上する場合があります。
深い I/O キューを使用する
Persistent Disk はネットワークにアタッチされたデバイスです。このため、ローカル SSD ディスクなどのローカル接続のディスクと比べると、レイテンシが大きくなります。Persistent Disk は、非常に高い IOPS とスループットが得られますが、十分な I/O リクエストを並行して実行する必要があります。並列で実行される I/O リクエストの数は I/O キューの深さと呼ばれます。
以下の表に、特定のパフォーマンス レベルを実現するために推奨される I/O キューの深さを示します。この表では、安全な推奨値を提示するため、標準的なレイテンシを若干多めに設定しています。この例は、16 KB の I/O サイズを使用していることを前提としています。
I/O サイズを大きくして十分な I/O を生成する
大きい I/O サイズを使用する
IOPS の上限とレイテンシによってアプリケーションのパフォーマンスが妨げられないようにするには、最低でも 256 KB 以上の I/O サイズを使用します。
分散ファイル システムのアプリケーションには、大きなストライプ サイズを使用します。大きなストライプ サイズ（4 MB 以上）を使用するランダム I/O ワークロードは、ワークロードが複数のシーケンシャル ストリーム ディスク アクセスに類似しているほど、標準 Persistent Disk で優れたパフォーマンスを発揮します。
アプリケーションが十分な I/O を生成していることを確認する
アプリケーションで、ディスクの IOPS とスループットの上限を活用できる十分な I/O を生成していることを確認してください。ワークロードの I/O パターンをより深く理解するには、Cloud Monitoring で永続ディスクの使用率とパフォーマンス指標を確認してください。
I/O を生成しているインスタンスに十分な CPU を割り当てる
VM インスタンスの CPU が不足していると、前述の IOPS をアプリケーションで管理することはできません。予想されるトラフィックの 2,000～2,500 IOPS ごとに使用可能な CPU を 1 つ用意することをおすすめします。
高い I/O 負荷を最大スパンに制限する
スパンとは、単一ディスク上の論理ブロック アドレスの連続した範囲のことです。I/O の負荷が高い場合は、次の表に示すように、ディスクがアタッチされている VM のマシンタイプに応じた特定の最大スパンに制限すると、パフォーマンスが最大になります。
| マシンタイプ | 推奨最大スパン |
|---|---|
|
25 TB |
| その他のすべてのマシンタイプ | 50 TB |
複数の Persistent Disk から 50 TB 以下のスパンを構成した場合、単一の 50 TB スパンと同等のパフォーマンスが得られます。
ディスクのパフォーマンスを向上させるためのオペレーティング システムの変更
場合によっては、オペレーティング システムレベルで機能を有効または無効にできます。また、ディスクのパフォーマンスを改善するために、特定の方法でアタッチされたディスクを構成できます。
Linux での ext3 ファイル システムを使用しない
Linux VM で ext3 ファイル システムを使用すると、書き込み負荷が高い状況でパフォーマンスが大幅に低下する可能性があります。可能であれば ext4 を使用してください。ext4 ファイル システム ドライバには ext3/ext2 との下位互換性があり、ext3 ファイル システムのマウントがサポートされています。ほとんどの Linux オペレーティング システムでは、ext4 ファイル システムがデフォルトになっています。
ext4 に移行できない場合は、回避策として、data=journal マウント オプションを使用して ext3 ファイル システムをマウントできます。これにより、書き込み IOPS は向上しますが、書き込みスループットは低下します。ext4 に移行することで、一部のベンチマークで最大 7 倍の改善が見込まれます。
遅延初期化を無効にし、DISCARD コマンドを有効にする
Persistent Disk は、廃棄オペレーションまたは TRIM コマンドをサポートしています。これにより、オペレーティング システムはブロックが不要になったことをディスクに通知できます。廃棄オペレーションのサポートにより、オペレーティング システムは不要なディスク ブロックをマークすることで、ブロックをゼロアウトするコストをかけずに済みます。
ほとんどの Linux オペレーティング システムでは、VM に Persistent Disk をマウントするときに破棄オペレーションを有効にします。Windows Server 2012 R2 VM では、Persistent Disk をマウントすると、デフォルトで破棄オペレーションが有効になります。
廃棄オペレーションを有効にすると、一般的なランタイム パフォーマンスが向上し、最初にマウントされるときのディスクのパフォーマンスも向上します。ディスク ボリューム全体のフォーマットには時間がかかる可能性があるため、「ゼロ初期化までしない（Lazy）フォーマット」が一般的な方法ですが、このフォーマットの欠点は、ボリュームの初回マウント時に時間がかかることが多い点です。遅延初期化を無効にして、破棄オペレーションを有効にすると、フォーマットとマウントのオペレーション時間を短縮できます。
次のパラメータを mkfs.ext4 に渡して、遅延初期化を無効にし、ディスクをフォーマットするときに破棄オペレーションを有効にします。
-E lazy_itable_init=0,lazy_journal_init=0,discardlazy_journal_init=0パラメータは、CentOS 6 と RHEL 6 のどちらのイメージのインスタンスでも機能しません。これらのオペレーティング システムを使用する VM の場合、このパラメータなしで Persistent Disk をフォーマットします。-E lazy_itable_init=0,discard次のフラグを
mountコマンドに渡すことで、ディスクのマウント時に破棄オペレーションを有効にします。-o discard
Persistent Disk は、破棄オペレーションを有効にすると適切に機能します。ただし、破棄オペレーションの使用に加えて、またはその代わりに、オプションとして定期的に fstrim を実行することもできます。破棄オペレーションを使用しない場合は、ブートディスクのスナップショットを作成する前に fstrim を実行します。ファイル システムをトリミングすることで、より小さなスナップショット イメージを作成でき、スナップショットの保存コストを削減できます。
先読み量を調整する
I/O パフォーマンスを向上させるため、オペレーティング システムは先読みなどの技法を導入しています。先読みでは、要求されたものより多くのファイルが、後続の読み取りでそのデータが必要になるという想定の下で、メモリに読み込まれます。先読み量を多くするほどスループットは向上しますが、メモリと IOPS は犠牲になります。先読み量を少なくすると、IOPS は向上しますが、スループットは低下します。
Linux システムでは、blockdev コマンドを使用して先読み量の値を取得や設定できます。
$ sudo blockdev --getra /dev/DEVICE_ID
$ sudo blockdev --setra VALUE /dev/DEVICE_ID
先読み量の値は <desired_readahead_bytes> / 512（バイト）です。
たとえば、先読み量が 8 MB の場合、8 MB は 8,388,608 バイト（8×1,024×1,024）です。
8388608 bytes / 512 bytes = 16384
blockdev を 16384 に設定します。
$ sudo blockdev --setra 16384 /dev/DEVICE_ID
VM の変更または新しい VM の作成
各 VM マシンタイプには上限があり、アタッチされたディスクから利用できるパフォーマンスに影響する可能性があります。次の上限があります。
- Persistent Disk のパフォーマンスは、使用可能な vCPU の数が増えるにつれて向上します。
- Hyperdisk は、すべてのマシンタイプでサポートされているわけではありません。
- 使用可能な vCPU の数が増えると、下り（外向き）ネットワークの料金が増加します。
自由度の高い CPU を使用していることを確認する
Persistent Disk の読み取りと書き込みには、VM の CPU サイクルが必要です。非常に高い安定した IOPS レベルを実現するには、I/O の処理に自由に使用できる CPU が必要です。
VM で使用できる vCPU の数を増やすには、新しい VM を作成するか、VM インスタンスのマシンタイプを編集します。
新しい機能を利用するために新しい VM を作成する
新しいディスクタイプは、すべてのマシンシリーズまたはマシンタイプでサポートされるわけではありません。Hyperdisk は、ワークロードの IOPS やスループット率を高くしますが、現在は少数のマシンシリーズでのみ使用可能で、64 個以上の vCPU が必要です。
新しい VM マシンシリーズは通常、新しい CPU で実行されるため、以前の CPU よりもパフォーマンスが向上しています。また、新しい CPU は Advanced Matrix Extensions（AMX）や Intel Advanced Vector Extensions（AVX-512）などのワークロードのパフォーマンスを改善する追加機能もサポートしています。
次のステップ
- Linux VM にアタッチされている Persistent Disk ボリュームのベンチマークを行う。
- Persistent Disk の料金体系を確認する。
- Persistent Disk のパフォーマンス指標を確認して、ディスク パフォーマンスをモニタリングする方法を学習する。