アナリストは各社が公開している数値とベンチマークテストの結果が異なることについて驚いていないという。

　「パフォーマンスに関するベンダーの主張はうのみにしてはならない。適切なメトリクスを適用して、然るべきコンテキストを用意する必要がある」と米Server and StorageIO Groupの創設者でアナリストを務めるグレッグ・シュルツ氏は語る。

　ベンチマークテスト自体についても同じことがいえる。

　「同じ条件で比較する必要がある。また、比較する具体的な中身についても明確にしなければならない。これはベンチマークテストと仕様をよく見せるためのデータ操作に関する鉄則だ」（シュルツ氏）

AWSとGoogleのSSDパフォーマンスの結果

　「Google Compute Engine」（GCE）の「Persistent Disk SSD」のパフォーマンスはボリュームサイズの影響を受ける。そう語るのは、CloudHarmonyの創設者であるジェイソン・リード氏だ。そのため、テストには複数のボリュームサイズを使用した。

　小さなボリュームサイズでは、GCEのSSDのIOPSは公開通りの結果になった。CloudHarmonyのテスト結果によると、10GバイトのSSD Persistent Diskでは読み取りと書き込みの両方で約300 IOPS、50Gバイトでは1500 IOPS、100Gバイトでは3000 IOPSという結果になった。

　だが、CloudHarmonyが200Gバイト以上のボリュームで実施したIOPSのテスト結果は、Googleの製品ページに掲載されている数値よりも低かった。Googleの製品ページには、200Gバイトのボリュームのパフォーマンスが6000 IOPSと掲載されている。だが、ベンチマークテストの結果では3800～4500 IOPSという結果になった。ただし、1つ例外がある。それは最大インスタンス（n1-standard-16）でベンチマークテストを実施した場合だ。このインスタンスではIOPSは6000強という結果になった。

　333GバイトボリュームのIOPSは1万と公開されているが、ベンチマークテストでは3000～4500 IOPSという結果になった。この場合も、n1-standard-16インスタンスは例外で、333Gバイトボリュームでは9000 IOPSという公開値に近い結果となった。同様に500GバイトボリュームのIOPSは、読み取りが1万、書き込みが1万5000と公開されている。だが、ベンチマークテストでは読み取りと書き込みのIOPSはどちらも約9000という結果になった。

　また、1Tバイト（1000Gバイト）ボリュームのIOPSは、読み取りが1万、書き込みが1万5000と公開されているが、2014年9月に実施したベンチマークテストでは、読み取りが8500、書き込みが7400という結果になった。

　この相違は、公開されているパフォーマンスを実現できるスレッドカウントと待ち行列の長さのパラメーターが制限されていることによるものだとリード氏は指摘する。つまり、Googleが主張しているパフォーマンスは実現可能なものである。ただし、このパフォーマンスを実現するには厳密に定められた条件を満たしていることが必要となる。その条件の1つは、CPUの数が多いインスタンスで運用されている大きなボリュームサイズだ。I/Oまたはキューベースのスケジューラーのどちらが使用されているかも結果に影響するとリード氏は補足する。

　この点について、「Amazon Web Service」（AWS）のブロックストレージ「Amazon Elastic Block Store」（Amazon EBS）は、GCEより寛大だ。ユーザーは、幅広いI/Oワークロード特性で公開されているIOPSを実現できるとリード氏は話す。

ネットワークのスループットを検証した結果のTop10《クリックで拡大》

AWSとGCEで検証したネットワークのスループットTop20《クリックで拡大》

各種パフォーマンスオプションを提供するAWSのSSD

　AWSのパフォーマンステストの結果もWebサイトに掲載されている数値とは異なった。だが、ボリュームやインスタンスのサイズによっては、掲載されている数値より高い結果が出ている。

　Amazon EBSの汎用ボリュームでは、小さなインスタンスとボリュームサイズのIOPSは、大きなインスタンスやボリュームサイズよりも低くなっている。例えば、256Gバイトボリュームのt2.mediumインスタンスのIOPSは、読み取りが790.6、書き込みが768.4という結果になった。一方、16個の1Tバイトボリュームに8基のCPUがアタッチされたm3.2xlargeインスタンスのIOPSは、読み取りが2万6913、書き込みが3万347という結果になった。

　2014年11月に実施したAmazon EBSのプロビジョンドIOPSのテストでも、インスタンスのサイズに比例する結果が出ている。また、各ボリュームでは読み取りと書き込みの両方で公開値を4000上回る結果になった。ユーザーは1台の仮想マシンでIOPSの総容量を増やすことができる。その方法は、最大16個のボリュームをより大きな「Amazon Elastic Compute Cloud」（Amazon EC2）インスタンスにアタッチして、公開されている最大のIOPS、4万8000を読み取りと書き込みで実現することだ。

　CloudHarmonyのベンチマークテストでは、プロビジョンドIOPSボリュームでは、AWSのWebサイトに掲載されているIOPS（4万8000）よりも高いIOPSを実現できることが判明した。最大16個のボリュームをストライプできる大きなインスタンス（c3.8xlargeなど）では、プロビジョンドIOPSのベンチマークテストの平均値は読み取りで6万6000、書き込みで5万6000という結果になった。

　高負荷のワークロードに関して用意されているオプションの数はAWSの方が多い。だが、1つのボリュームを拡張してIOPSをスケールアップするというアプローチはGCEと似ているとリード氏はいう。CloudHarmonyのテストでは、バーストが考慮されていない。そのため、汎用ボリュームでも最大30分はさらに高いパフォーマンスを維持することが可能だ。

　ストレージのパフォーマンスでは待ち時間も重要な測定単位になる。2014年11月に実施したテストでは、AWSのインスタンスの待ち時間はGCEのインスタンスより短かった。だが、GCEよりもインスタンス間で待ち時間に大きなばらつきが見られた。GCEの待ち時間は、100Gバイトのボリュームにアタッチされたn1-standard-1インスタンスの0.67ミリ秒が最短で、10Gバイトのボリュームにアタッチされたg1-smallインスタンスの3.31ミリ秒が最長だった。一方、AWSの待ち時間は512Gバイトのボリュームにアタッチされたm3.largeインスタンスの0.32ミリ秒から64Gバイトのボリュームにアタッチされた同じ種類のインスタンス（m3.large）の5.13秒と幅がある結果となった。

Amazon EBSプロビジョンドIOPS検証結果《クリックで拡大》

GCEインスタンスの待ち時間《クリックで拡大》

Amazon EBS汎用ボリュームの待ち時間《クリックで拡大》

Amazon EBSプロビジョンドIOPSの待ち時間《クリックで拡大》

　AWSとGCEのSSDの違いは価格にも見られる。GCEのSSDの容量が1Gバイト当たり0.17ドルであるのに対して、AWSの汎用ボリュームは1Gバイト当たり0.10ドルとなっている。プロビジョンドIOPSの価格はEBSの汎用SSDよりも若干高く、1Gバイト当たり月額0.125ドル、プロビジョンドIOPSごとに0.065ドル掛かる。

　「GCEのSSDはAmazon EBSよりも約75％割高だ。また、プロビジョンドIOPSはプレミアムサービスという位置付けになる」（リード氏）

　Amazon EBSはパフォーマンスを向上するために、バーストとバーストクレジットを提供している。リード氏は次のようにいう。「当社が実施したブロックストレージテストの時間と厳しさにより、Amazon EBSのバーストの特性はデータに反映されていない。「負荷が低いまたは爆発的なI/Oワークロードがあるユーザーは、Amazon EBSの方が高いIOPSを実現できるだろう」本稿に関してAmazonとGoogleからのコメントは得られなかった。

　ストレージパフォーマンステストの詳細な結果については、「CloudScores」（CloudHarmonyのWebサイト）で公開中だ。