EBS ボリュームのベンチマーク

I/O ワークロードをシミュレートすることで、Amazon EBS ボリュームのパフォーマンスをテストできます。手順は次のとおりです。

1. EBS 最適化インスタンスを作成する。

2. 新しい EBS ボリュームを作成します。

3. EBS 最適化インスタンスにボリュームをアタッチする。

4. ブロックデバイスを設定およびマウントします。

5. ツールをインストールし、I/O パフォーマンスを評価する。

6. ボリュームの I/O パフォーマンスを評価する。

7. ボリュームを削除し、料金が発生しないようにインスタンスを終了する。

重要

手順の一部を実行すると、ベンチマークを実行する EBS ボリューム上の既存のデータが破壊されます。ベンチマーク手順は、本番ボリュームではなく、テスト目的で特別に作成されたボリュームで使用するために用意されています。

インスタンスのセットアップ

EBS ボリュームで最適なパフォーマンスを実現するには、EBS 最適化インスタンスを使用することをお勧めします。EBS 最適化インスタンスは、Amazon EC2 および Amazon EBS 間の専用スループットとインスタンスを提供します。EBS 最適化インスタンスは、Amazon EC2 と Amazon EBS の間で所定の帯域幅を実現するものであり、インスタンスタイプに応じて仕様で選択できます。

EBS 最適化インスタンスを作成するには、Amazon EC2 コンソールを使用してインスタンスを起動するときに [EBS 最適化インスタンスとして起動する] を選択するか、コマンドラインを使用するときに --ebs-optimized を指定します。このオプションをサポートするインスタンスタイプを必ず選択してください。

Provisioned IOPS SSD または 汎用 SSD ボリュームの設定

Amazon EC2 コンソールを使用して、プロビジョンド IOPS SSD (io1 および io2) または汎用 SSD (gp2 および gp3) ボリュームを作成するには、[ボリュームタイプ] で、[プロビジョンド IOPS SSD (io1)]、[プロビジョンド IOPS SSD (io2)]、[汎用 SSD (gp2)]、または [汎用 SSD (gp3)] を選択します。コマンドラインの --volume-type パラメータには、io1、io2、gp2、または gp3 を指定します。io1、io2、および gp3 ボリュームの場合は、--iops パラメータに、1 秒あたりの I/O オペレーション数 (IOPS) を指定します。詳細については、Amazon EBS ボリュームの種類およびAmazon EBS ボリュームの作成を参照してください。

(Linux インスタンスのみ) テストの例には、6 ボリュームを備えた RAID 0 アレイを作成することをお勧めします。これは高いレベルのパフォーマンスを実現します。料金は、ボリューム数ではなく、プロビジョニングされたギガバイト (および io1、io2、gp3 ボリュームに対してプロビジョニングされた IOPS 数) に対して発生します。したがって、ストライプセットを作成するために、複数の小さなボリュームを作成しても追加コストは発生しません。Oracle Orion を使用してボリュームを評価する場合は、Oracle ASM と同じ方法でストライピングをシミュレートできます。したがって、Orion でストライピングを行えるようにすることをお勧めします。別のベンチマークツールを使用する場合は、ボリュームのストライピングを自身で行う必要があります。

RAID 0 アレイの作り方の詳細については、「RAID 0 アレイの作成」を参照してください。

スループット最適化 HDD (st1) または Cold HDD (sc1) ボリュームをセットアップする

st1 ボリュームを作成するには、Amazon EC2 コンソールを使用してボリュームを作成するときに [スループット最適化 HDD] を選択するか、コマンドラインを使用して --type st1 を指定します。sc1 ボリュームを作成するには、Amazon EC2 コンソールを使用してボリュームを作成するときに [Cold HDD] を選択するか、コマンドラインを使用して --type sc1 を指定します。EBS ボリュームの作成の詳細については、Amazon EBS ボリュームの作成を参照してください。インスタンスへのこれらのボリュームのアタッチについては、インスタンスへの Amazon EBS ボリュームのアタッチを参照してください。

(Linux インスタンスのみ) AWS は、AWS CloudFormation に使用する JSON テンプレートを提供し、このセットアップ手順を簡単にします。これには、テンプレートにアクセスして JSON ファイルとして保存します。AWS CloudFormation では、独自の SSH キーを設定して、st1 ボリュームを評価するためのパフォーマンステスト環境を簡単にセットアップすることができます。テンプレートを使用すると、現行世代のインスタンスと 2 TiB の st1 ボリュームが作成され、このボリュームが /dev/xvdf のインスタンスにアタッチされます。

(Linux インスタンスのみ) テンプレートを使用して HDD ボリュームを作成する方法

1. https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソール を開きます。

2. [Create Stack] を選択します。

3. [Upload a Template to Amazon S3] を選択し、さきほど入手した JSON テンプレートを選択します。

4. スタックに、「ebs-perf-testing「 のような名前を付け、インスタンスタイプ (デフォルトは r3.8xlarge) および SSH キーを選択します。

5. [Next] を 2 回選択し、[Create Stack] を選択します。

6. 新しいスタックのステータスが [CREATE_IN_PROGRESS] から [COMPLETE] に移行したら、[Outputs] (出力) を選択して新しいインスタンスのパブリック DNS エントリを取得します。このインスタンスには、2 TiB の st1 ボリュームがアタッチされます。

7. ユーザー ec2-user として、前のステップで DNS エントリから取得したホスト名を使用し、新しいスタックに SSH を使用して接続します。

8. ベンチマークツールのインストール に進みます。

ベンチマークツールのインストール

次の表に、EBS ボリュームのパフォーマンスをベンチマークするために使用できるツールのいくつかを示します。

Linux インスタンス

ツール	説明
fio	I/O パフォーマンスを評価します (fio は libaio-devel に依存することに注意してください。) fio を Amazon Linux にインストールするには、次のコマンドを実行します。 [ec2-user ~]$ sudo yum install -y fio Ubuntu に fio インストールするには、次のコマンドを実行します。 sudo apt-get install -y fio
Oracle Orion Calibration ツール	Oracle データベースで使用するストレージシステムの I/O パフォーマンスを調整します。

Windows インスタンス

ツール	説明
DiskSpd	DiskSpd は、Microsoft の Windows、Windows Server、クラウドサーバーインフラストラクチャエンジニアリングチームのストレージパフォーマンスツールです。これは、次からダウンロードできます。https://github.com/Microsoft/diskspd/releases diskspd.exe 実行可能ファイルをダウンロードした後、管理者権限でコマンドプロンプトを開き (「管理者として実行を選択」)、diskspd.exe ファイルをコピーしたディレクトリに移動します。 適切な実行可能フォルダ (amd64fre、armfre または x86fre)) から目的の diskspd.exe 実行可能ファイルを C:\DiskSpd などの短い、単純なパスにコピーします。ほとんどの場合、amd64fre フォルダから 64 ビットバージョンの DiskSpd を使用します。 DiskSpd のソースコードは、https://github.com/Microsoft/diskspd の GitHub でホストされています。
CrystalDiskMark	CrystalDiskMark は、シンプルなディスクベンチマークソフトウェアです。https://crystalmark.info/en/software/crystaldiskmark/ でダウンロードできます。

これらのベンチマークツールは、さまざまなテストパラメータをサポートしています。使用するのは、ボリュームがサポートするワークロードを見積もるためのコマンドです。評価に必要な基本的なコマンドの例を以下に示します。

ボリュームキュー長の選択

ワークロードとボリュームタイプに基づいて最適なボリュームキュー長を選択します。

SSD-Backed ボリュームのキュー長

SSD-Backed ボリュームでワークロードに最適なキュー長を決定するには、使用可能な 1000 IOPS ごとにキュー長 1 を指定するようにお勧めします (汎用 SSD ボリュームのベースライン、Provisioned IOPS SSD ボリュームにプロビジョニングする値)。その後、アプリケーションのパフォーマンスを監視して、アプリケーション要件に応じて値を調整することができます。

プロビジョニングした IOPS、スループット、または最適なシステムキュー長 (現在は 32 に設定) に達するまでは、キュー長を大きくする方が有益です。例えば、IOPS として 3,000 がプロビジョニングされたボリュームでは、キュー長 3 を設定します。アプリケーションに最適な値を確認するには、これらの値を増減して調整してください。

HDD-Backed ボリュームのキュー長

HDD-Backed ボリュームのワークロードに対する最適なキュー長を決定するには、1 MiB のシーケンシャル I/O の実行時に 4 以上のキュー長を設定しておくようお勧めします。その後、アプリケーションのパフォーマンスを監視して、アプリケーション要件に応じて値を調整することができます。例えば、2 TiB の st1 ボリュームで、バーストスループットが 500 MiB/秒、IOPS が 500 の場合は、1,024 KiB、512 KiB、または 256 KiB のシーケンシャル I/O を実行する際に、キュー長をそれぞれ 4、8、または 16 に設定します。アプリケーションに最適な値を確認するには、これらの値を増減して調整してください。

C ステートの無効化

ベンチマークを実行する前に、プロセッサの C ステートを無効にする必要があります。サポートされている CPU の一時的にアイドリング状態のコアは、電力を節約するために C ステートに入ることができます。コアが処理を再開するために呼び出されると、コアが再び完全に動作するまで一定の時間が経過します。このレイテンシーは、プロセッサのベンチマークルーチンを妨げる可能性があります。C ステートとその EC2 インスタンスタイプでサポートされるインスタンスの詳細については、EC2 インスタンスタイプのプロセッサのステート制御を参照してください。

Linux インスタンス

Amazon Linux、RHEL、および CentOS で C ステートを無効にするには、次のようにします。

1. C ステートの数を取得します。

   $ C:\> cpupower idle-info | grep "Number of idle states:"

2. C ステート c1 から cN にして無効にします。理想的には、コアは c0 ステートにある必要があります。

   $ C:\> for i in `seq 1 $((N-1))`; do cpupower idle-set -d $i; done

Windows インスタンス

次のようにして、Windows システムで C ステートを無効にできます。

1. PowerShell で、現在のアクティブな電力スキームを取得します。

   $current_scheme = powercfg /getactivescheme

2. 電力スキームの GUID を取得します。

   (Get-WmiObject -class Win32_PowerPlan -Namespace "root\cimv2\power" -Filter "ElementName='High performance'").InstanceID          

3. 電力設定 GUID を取得します。

   (Get-WmiObject -class Win32_PowerSetting -Namespace "root\cimv2\power" -Filter "ElementName='Processor idle disable'").InstanceID                  

4. 電力設定サブグループの GUID を取得します。

   (Get-WmiObject -class Win32_PowerSettingSubgroup -Namespace "root\cimv2\power" -Filter "ElementName='Processor power management'").InstanceID

5. インデックスの値を 1 に設定して、C ステートを無効にします。値 0 は、C ステートが無効であることを示します。

   powercfg /setacvalueindex <power_scheme_guid> <power_setting_subgroup_guid> <power_setting_guid> 1

6. アクティブなスキームを設定して、設定が保存されるようにします。

   powercfg /setactive <power_scheme_guid>

ベンチマークテストを実行する

次の手順では、さまざまな EBS ボリュームタイプに対するベンチマークコマンドについて説明します。

EBS ボリュームがアタッチされている EBS 最適化インスタンスで、次のコマンドを実行します。EBS ボリュームをスナップショットから作成した場合は、ベンチマークテストを実行する前に、必ず初期化してください。詳細については、「Amazon EBS ボリュームの初期化」を参照してください。

ボリュームのテストが完了したら、クリーンアップに関する次のトピックの Amazon EBS ボリュームの削除 および「インスタンスの終了」を参照してください。

Provisioned IOPS SSD ボリュームと 汎用 SSD ボリュームをベンチマークする

Linux インスタンス

作成した RAID 0 アレイで fio を実行します。

次のコマンドは、16 KB のランダム書き込みオペレーションを実行します。

[ec2-user ~]$ sudo fio --directory=/mnt/p_iops_vol0 --ioengine=psync --name fio_test_file --direct=1 --rw=randwrite --bs=16k --size=1G --numjobs=16 --time_based --runtime=180 --group_reporting --norandommap

次のコマンドは、16 KB のランダム読み取りオペレーションを実行します。

[ec2-user ~]$ sudo fio --directory=/mnt/p_iops_vol0 --name fio_test_file --direct=1 --rw=randread --bs=16k --size=1G --numjobs=16 --time_based --runtime=180 --group_reporting --norandommap 

結果の読み方については、チュートリアルfio のディスク IO パフォーマンスの確認を参照してください。

Windows インスタンス

作成したボリュームで DiskSpd を実行します。

次のコマンドは、C: ドライブ上にある 20 GB のテストファイルを使用して、30 秒のランダム I/O テストを実行します。書き込み率 25%、読み取り率 75%、ブロックサイズは 8 K です。これは、それぞれ 4 つの未処理の I/O を持ち、1 GB の書き込みエントロピー値シードを持つ 8 つのワーカースレッドを使用します。テストの結果は、DiskSpeedResults.txt というテキストファイルに保存されます。これらのパラメータは、SQL Server OLTP ワークロードをシミュレートします。

diskspd -b8K -d30 -o4 -t8 -h -r -w25 -L -Z1G -c20G C:\iotest.dat > DiskSpeedResults.txt

結果の読み方については、チュートリアルDiskSPd のディスク IO パフォーマンスの確認を参照してください。

st1 および sc1 ボリュームのベンチマーク (Linux インスタンス）

st1 ボリュームまたは sc1 ボリュームで fio を実行します。

注記

これらのテストを実行する前に、st1 および sc1 (Linux インスタンスインスタンスのみ) で高いスループットの読み取りが多いワークロードに先読みを増やすの説明に従って、バッファ付き I/O をインスタンスに設定してください。

次のコマンドでは、アタッチされた st1 ブロックデバイス (例: /dev/xvdf) に対して、1 MiB のシーケンシャル読み取り操作を実行します。

[ec2-user ~]$ sudo fio --filename=/dev/<device> --direct=1 --rw=read --randrepeat=0 --ioengine=libaio --bs=1024k --iodepth=8 --time_based=1 --runtime=180 --name=fio_direct_read_test

次のコマンドでは、アタッチされた st1 ブロックデバイスに対して、1 MiB のシーケンシャル書き込み操作を実行します。

[ec2-user ~]$ sudo fio --filename=/dev/<device> --direct=1 --rw=write --randrepeat=0 --ioengine=libaio --bs=1024k --iodepth=8 --time_based=1 --runtime=180 --name=fio_direct_write_test 

ワークロードによっては、ブロックデバイスの異なる部分に対してシーケンシャル読み取りとシーケンシャル書き込みの組み合わせを実行するケースがあります。このようなワークロードを評価する場合は、読み取りと書き込みに対して別々の fio ジョブを同時に実行し、fio offset_increment オプションを使用して、ブロックデバイスの別々の場所を各ジョブに割り当てることをお勧めします。

このワークロードの実行は、シーケンシャル書き込みまたはシーケンシャル読み取りのワークロードの場合より、少し複雑になります。テキストエディターを使用して、次の内容を含む fio ジョブファイル (この例では fio_rw_mix.cfg) を作成します。

[global] 
clocksource=clock_gettime
randrepeat=0
runtime=180
 
[sequential-write]
bs=1M
ioengine=libaio
direct=1
iodepth=8
filename=/dev/<device>
do_verify=0
rw=write
rwmixread=0
rwmixwrite=100 

[sequential-read] 
bs=1M
ioengine=libaio
direct=1
iodepth=8
filename=/dev/<device>
do_verify=0
rw=read
rwmixread=100
rwmixwrite=0
offset=100g

次に、以下のコマンドを実行します。

[ec2-user ~]$ sudo fio fio_rw_mix.cfg

結果の読み方については、チュートリアルfio のディスク I/O パフォーマンスの確認を参照してください。

シーケンシャルの読み取りまたは書き込みの操作を使用しても、ダイレクト I/O の fio ジョブを複数実行した場合は、st1 および sc1 ボリュームで予測を下回るスループットになります。単一のダイレクト I/O ジョブを使用し、iodepth パラメータを指定して、I/O 操作の同時実行数を制御することをお勧めします。