本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はAre your storage performance test methods able to test acceleration platforms accurately?で閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
高速化プラットフォームを検証する際には、データフローを理解しておく必要があります。従来のストレージアーキテクチャのI/Oのパスと新しい世代の高速化プラットフォームアーキテクチャを比較すると、従来のパフォーマンス検証は必ずしも実際のアプリケーションのパフォーマンスを想定するのに適していないことがわかります。
I/Oのパスを比較する
データがストレージアレイへ向かう、もしくはデータがストレージアレイから向かってくるI/Oのパスは非常に直接的です。データは一箇所にしかなく、I/Oコマンドはアーキテクチャ全体にわたって予想可能なパスを通ります。パフォーマンスも非常にわかりやすいです。一定のパスを通るので、何度も同じ結果が出ます。高速化プラットフォームを利用している場合、仮想マシンとストレージアレイの間に追加された新しいレイヤはよく読み込まれるデータや高速化する書き込みのデータを常にコピーし続けて、読み取りと書き込みを高速化しています。
様々な検証の方法
ストレージのパフォーマンスの検証にはたくさんの方法があります。よくある2つのアプローチは実際のアプリケーションを利用するか、負荷生成装置をつかうものです。高速化プラットフォームを利用している場合にアプリケーションのパフォーマンスを検証するもっともよい方法は仮想インフラストラクチャ上でそのアプリケーションを展開し、実際に使ってみることです。
もしも、実際の負荷を利用することが出来ない場合、負荷生成装置を使うということも可能です。この場合には実際の負荷のパターンをその特徴を残したままに再現することです。特徴というのはI/Oのタイプ(読み取りもしくは書き込み)、I/Oのサイズやその他の依存関係です。データが処理され、最低何度かはアクセスされるという、実際のアプリケーションの振る舞いを偽装しなくてはなりません。
依存関係
よく聞く依存関係は、データの依存関係と内部処理の依存関係です。これらは特定のアプリに固有のものではなく、複雑なマルチ-ティアのシステムにも、単独のアプリケーションにも同じように存在します。データの依存関係は以前リクエストしたデータの出力を次のリクエストの入力に利用するような場合に発生します。内部処理の依存関係は殆どの場合データの依存関係とどの順で処理が実行されていくかの順番によって顕在化します。負荷発生装置を利用したワークロードでの検証はこの依存関係を無視したものであるという点が実際のアプリケーションを利用したテストでの根本的な相違点です。実際のアプリケーションではワークロードのスパイクが発生したりしますが、一般的には24時間365日バーストが発生し続けることはありません。プロセスが仕事を終えるのに必要な時間というものがあるのです。
他にアプリケーションのパフォーマンスをシミュレーションする方法として、記録と再生という方法が一般的です。記録と再生では、仮想環境内の実際のワークロードを再現アプリケーションによって「再生」することが可能です。vSphere環境おいてよく使われている再現ツールはvSCSIstatsです。vSCSIstatsはESXiのコマンドラインツールとして提供されています。VMware.comから入手可能なVMware I/O analyzerでvSCSIstatsの記録ファイルを再生することが出来ます。しかしながら、vSCSIstatsは重たい操作であり、内部処理、内部トラフィックの依存関係は必ずしも個々のディスク上で動作するvSCSIStatsの記録ファイルとして記録しなくてはならないということでは無いということは注意しておくべきです。
事前に生成したワークロードパターンを使わない
本番の環境を再現する環境を構築することや、本番の環境で正確なワークロードを記録することは非常に時間がかかりますし、難しいことです。ストレージソリューションのパフォーマンスを計測するために、IOrateやFIOやIometerのような負荷生成装置を利用するのは簡単でスピード感があります。ほとんどの負荷生成器はI/Oを生成します。しかしリクエストされるデータがどのような形状で、どのようなパターンなのかを模写することは出来ません。根本的には事前に生成したワークロードのパターンはキューや帯域を食いつぶし、最大のIOPS、レイテンシ、スループットを計測するだけなのです。どのぐらいで仕事が終わるのか(トランザクション、Webのリクエスト)などの、エンドユーザーにとって大切なものを計測するのではなく、「帯域の太さ」を図る検証なので何ら意味を持ちません。
推奨
アプリケーションがどのように振舞っているのかを調べ、どのブロックサイズでアプリケーションが動作しているのかを確認し、どのぐらいのI/O(ReadとWrite)の割合をアプリケーションが利用しているかを明らかにするために時間を使いましょう。ストレージ高速化プラットホームを正しく検証するためには、標準の検証で利用しているパターンを変更し、幾らかのデータを何度もアプリケーションが読み込むように変更しなくてはなりません。これによってデータの依存関係が存在し、書き込む前に読み取りが発生する手順(Read After Write=RAW)ような実際に起こりうるシナリオに近づけていくことが可能です。加えて言うならば、データセットのサイズを適切にし、ストレージコントローラーのキャッシュからではなく、データがディスクから呼び出されるようにしてください。もしも、実際のアプリケーションのパフォーマンスをシミュレーションしたいのであれば、アプリケーションの利用するすべてのデータがストレージコントローラーのキャッシュから読み込まれることを期待することは出来ないからです。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
