インタビュー私たちは、ストレージ アレイのパフォーマンスに関する主張について、Nimble Storage のグローバル テクノロジーおよび戦略アーキテクトである Dimitris Krekoukias 氏にインタビューしました。Krekoukias 氏は、特に Pure Storage のパフォーマンスに対するアプローチについて強い意見を持っています。
PureはKrekoukias氏の指摘に対し、インタビュー後に追加された回答を提供しました。どちらの見解も、単一のIOサイズではあらゆるパフォーマンス特性評価のニーズに対応できないことを強調しています。
El Reg :ストレージ アレイのパフォーマンスに関する主張について教えてください。
ディミトリス・クレコウキアス：ストレージ性能（あるいはあらゆる性能）は、マーケティング効果を最大化するためにしばしば誇張される要素の一つです。時には、現実歪曲の計算と相まって、信憑性を高めるために、かなり誇張されることもあります。
一例を挙げると、Pure Storage は、平均的なストレージ I/O ブロック サイズが 32 KB であるだけでなく、そのアレイは 32 KB の I/O サイズでも高いパフォーマンスを提供するという二重の主張をしています。
エル・レグ：どういう意味ですか？
ディミトリス・クレコウキアス：パフォーマンスに関して平均値が非常に誤解を招く可能性があることを示す、最も分かりやすい例え話の一つを挙げましょう。スーパーカー（お好きな車種をお選びください）の平均速度は時速60マイル（約97km/h）です。ほとんどのスーパーカーの平均走行速度（市街地／高速道路／サーキット）を考えると、これは確かに真実かもしれません。しかし、実際の様々な条件下での車の実際のパフォーマンスを説明していないため、あまり役に立ちません。
もう一つ、車の例えを挙げてみましょう。Pure社は、ファミリーカーは身長120cm、体重45kgの人を想定して設計されるべきだと主張しています。これは、大人2人と子供2.3人の家族の平均体重だからです。そんな車は使い物になりません。身長175cm、体重75kgの大人と、身長120cm、体重20kgの子供が快適に運転できる車が必要です。
El Reg :では、Nimble はストレージ IO 特性についてより詳しいのでしょうか?
ディミトリス・クレコウキアス： Nimble StorageはInfoSightによる非常に包括的な分析機能を備えており、他のどのストレージアレイよりもはるかに多くの情報を収集することで、アレイの実際の使用状況を極めて正確に把握できます。数千台ものアレイにまたがる数千億ものデータポイントが、巨大なビッグデータバックエンドによって毎日処理されています。
これらのデータ ポイントには、問題を予測して防止するだけでなく、さまざまなアプリケーションが実際にどのように I/O を実行するかなど、他の多くのことを指摘するのに十分な情報が含まれています。
Nimbleの主席データサイエンティストであるDavid Adamson氏が、このテーマに関する優れたブログ記事（こちら）を公開しました。さらに、アプリケーションごとに詳細に分析した詳細な調査結果（こちら、PDF）も公開しています。要約すると、以下のようになります。
- 多数の操作は小さなI/Oサイズを使用します。レイテンシが重要なワークロードでは、小さなI/Oサイズの方が効率的です。アプリケーションは主に16KB未満、特に4KBから8KB程度の小さなブロックI/Oを実行します。この種のI/Oは通常、レイテンシの影響を受けやすく、非常にランダムであることが多いです。すべての顧客とすべてのアプリケーションにおいて、すべての操作の大部分（すべての読み取りの52%、すべての書き込みの74%）は、小さなI/O領域に該当します。
- 大量のデータは、大きなI/Oサイズ（64KB以上）で転送される傾向があります。大きなI/Oサイズは、高スループットのデータ転送においてより効率的です。実際、データの大部分（全読み取りデータの84%、書き込みデータの72%）は、64KBを超えるI/Oサイズを使用しています。このようなI/Oはランダムというよりシーケンシャルであり、レイテンシはそれほど重要ではありません。
- 良い例としてSQL Serverが挙げられます。I/O密度は大きく二極化しており、ほとんどのI/Oは8K前後または64K超で発生しますが、トランザクションが多くレイテンシの影響を受けやすいOLTP環境ではより小さなI/Oサイズへの移行が顕著で、OLAP環境ではより大きなI/Oサイズへの集中が顕著です。
- データ分布は（同一アプリケーション内であっても）二峰性があり、両端に極端な値が存在するため、単一の平均値でI/Oサイズを定義することはあまり有用ではありません。実際のI/Oは、その平均値を中心には分布しないからです。
El Reg :これはアレイのベンチマークにどのような影響を与えますか?
ディミトリス・クレコウキアス：より有用な統計データが得られ、様々なアプリケーションやスペクトルにおけるI/Oの数、種類、サイズを把握できるようになったため、ストレージのベンチマークをより正確に行うことができます。ベンチマークは、実際のアプリケーションのバイモーダルな側面を考慮する必要があることは明らかです。
- 書き込み率の高い、小ブロックのランダム書き込み。優れたアレイであれば、非常に低く安定したレイテンシで、こうした書き込みを大量に実行できるはずです。
- より大きなブロックをシーケンシャルに処理します（書き込みよりも読み取りが少し多くなります）。優れたアレイには高いスループットが必要です。
El Reg :このアプローチを実際の POC で使用しましたか?
Dimitris Krekoukias:はい。Pureは、//m70アレイの性能ポテンシャルを300,000 32K IOPSと公表しています。最近、あるお客様がNimble AF7000（Nimbleの最速モデルではありません）とPure //m70（2016年8月時点でのPureの最速モデル）のパフォーマンス比較を行いました。
実施したテストの一つでは、書き込みと読み取りを50%ずつとし、ブロックサイズを4KBと小さく設定してI/Oを実行しました。Pureアレイのパフォーマンスは、Pureが謳うIOPSの約半分でした。NimbleアレイはPureを上回りましたが、それは本題ではありません。
ここでの重要な点は、Pure が、オールフラッシュアレイが実現するとされるトランザクション型のパフォーマンスにおいて、現実的なI/Oサイズで実現したにもかかわらず、自社の謳い文句を完全に達成できなかったことです。つまり、謳い文句の32KBという高いIOPS値（すべて読み取りであると考えられます）は、実際の環境では役に立ちません。
エル・レグ：そしてこの物語の教訓は…
Dimitris Krekoukias:フラッシュメモリを搭載しているからといって、必ずしも必要な速度で動作するとは限りません。少なくとも、小さなブロックのランダムI/Oと大きなブロックのシーケンシャルI/Oの両方について、大量の書き込み時も含めたパフォーマンス数値をベンダーに確認しましょう。また、小さなブロックのパフォーマンスにおけるレイテンシ数値も忘れずに確認しましょう。
Pure Storageと32K IOの問題
Pure の広報担当者は、クレコウキアス氏の指摘に対して長々と反論し、Pure は「ストレージ業界が、特定のブロック サイズでのヒーロー ベンチマークを使用して、マーケティング目的でストレージのパフォーマンスを誇張してきたという点に 100% 同意します」と述べた。
これらの固定ブロックサイズは、アレイ上で実行されるワークロードの真の姿を反映したものではありません。そのため、Pure Storageは2年以上前に業界をリードする立場から4K IOPSの公表をやめ、32K IOPSの数値に移行しました。これは、32K IOPSの方が実際のワークロードをより正確に反映していると判断したためです（詳細は後述）。また、ストレージシステムを評価する際には、お客様に実際のワークロードのコピーを使用してテストすることを常にお勧めしているのも、このためです。
「Nimbleは、Pureは世界全体が32K IOサイズ、もしくはその平均であると考えていると主張しているようだ」と広報担当者は付け加えた。
弊社のブログをご覧いただければお分かりいただけると思いますが、単純なIOサイズを見ているのか、実際のデータ転送量（サイズ重み付けIO）を見ているのかによって、状況は大きく異なります。ブログでは、なぜ4Kや8Kではなく32Kについて話すことにしたのかを非常に明確に説明していますが、これはお客様とのサイズ設定に関する会話の始まりに過ぎません。
FlashArrayでは、32KのIOサイズを想定したり最適化したりすることはありません。固定ブロックメタデータアーキテクチャ（4K、8K、16K、32Kなど）を使用して特定のクラスのワークロードを最適化することを好む多くのベンダーとは異なり、当社はPurityを最初から可変ブロックサイズを中心に設計しました。これは、すべてのアレイ（特に混合/仮想化ワークロード）のIOサイズが可変であることを踏まえたためです。
Pure Storage FlashArrayの強みは、チューニングや面倒な作業なしに、さまざまなIOサイズをスムーズに処理し、安定したパフォーマンスと最大限のデータ削減を実現できることです。当社のアーキテクチャには、基本的なブロックサイズは存在しません。つまり、従来のストレージシステムにありがちな、中程度のIOサイズでもデータの分割や無駄が生じるという問題がないのです。
Pure社の広報担当者は次のように続けました。「当社のアーキテクチャは特定のIOサイズを想定して設計も最適化もされていないにもかかわらず、なぜ仕様書に32K IOPSと記載しているのでしょうか？ 初期の市場は、ストレージデバイスのベンチマークを固定ブロックサイズで行っていました。実際、標準化されたベンチマークテストのほとんどは固定ブロックサイズを要求していました。私たちは1つのサイズしか選べなかったため、アレイに統合されるワークロードをより代表するブロックサイズを選択しました。」
当然、これはアレイ内のIOのサイズ加重平均であり、32Kに近くなります。当社のデータサイエンスチームが最近公開したブログで示したように、多数のワークロードを統合すると、アレイのサイズ加重平均IOは約32Kになります。
マクロレベルでは、当社のストレージシステム全体のワークロードを考慮すると、IOPSでは16K以下のブロックサイズが優勢ですが、スループットでは64Kを超えるブロックサイズが優勢です。そして、当社のブログに掲載されている2つのカートからもわかるように、データ分布はまさにバイモーダルです。
他のベンダーも同様のデータ主導型調査を開始したことに敬意を表します。私たちはこれらの調査結果に基づき、さらに深く掘り下げた質問をすることで、あらゆるデータサービスにおける可変ブロック設計に影響を与えました。私たちは長年にわたり、市場に対しブロックサイズを総合的に検討するよう、オープンに議論し、奨励してきました。
Pureのスタッフが様々なワークロードにおけるブロックサイズについて深く掘り下げたブログ記事をこちらでご覧いただけます。これらの記事に共通するのは、アプリケーションIOは単一のブロックサイズで繰り返されるトランザクション以上のものであるため、4Kと8Kベースのベンチマークを比較しても意味がないということです。®
