本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はNot all performance tests are created equalで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
本記事は「高速化プラットフォームの評価」についてのシリーズの2つ目の記事となります。一つ前の記事では高速化プラットフォームでの検証と従来の永続的なストレージレイヤ上での検証とを比較しながらアプリケーションパフォーマンスの検証の差異について述べてきました。この記事では期待値の管理についての説明を行います。コンシューマーに向けたコンピューターオンラインマガジンやブログでの検証結果は仮想インフラストラクチャでの検証の結果と異なる値が記載されることが有ります。ワークロードシミュレーターで計測した検証結果は実際のアプリケーションのワークロードに対してのあなたの期待を裏切ってしまうケースもあります。
全てのSSDディスクは平等ではない
PernixDataでは(おそらく、VMware社もvFRCやvSANについては同じことを思うはずです) フラッシュが一定したパフォーマンスを提供できることと、信頼がおけること、耐久性が高いことを推奨します。私はどのSSDディスクがPernixData FVPのために適しているか、推薦して欲しいという問い合わせを受け取ります。世の中には数多くのSSDディスクがありますが、我々はIntel DC S3700シリーズが大好きです。
(訳註: @PernixDataの評価のために買うべきSSDをだれか教えてください！ <--- だったらIntel DC S3700だね！)
他のSSDの方がいいシート上はスペックが高いと言われることも少なくありません。カタログスペックが高いということはもちろん重要ですが、そのスペックを導き出すためには現実的な検証が行われていないということも理解しておくべきです。例えば 512バイトのI/Oサイズを利用すればIOPSは非常に高く出ます。あなたの好きなテクニカルブログやオンラインマガジンの検証について確認したほうが良いのではないでしょうか？もしその結果がベンダーのスペックシートよりも良い値を示していたとしても、あなたの仮想インフラ環境で同じことが起きると期待しないほうが良いです。期待する前に以下のようなことを考えてみましょう。
- 高速化プラットフォームと永続ストレージでの検証の違い
- vSphereストレージスタック 対 ベアメタル上のWindows/Linux OS
- アプリケーションは単一のI/Oサイズのみを利用しない
vSphereストレージスタック 対 ベアメタル上のWindows/Linux OS
注意していただきたいことの1つとしてスペックシートやコンシューマーへ向けたテクニカルブログに記載されているIOPSの値と同じ値をあなたのvSphere環境に期待しては行けないということです。これらのブロクの主な読者はコンシューマーです、つまり、検証はWindows 7や8のような(彼らにとって)一般的なOSで実施されており、ESXiのストレージスタックとは完全に異なっているということです。
ストレージのスケジューラースタックは様々な異なるI/Oのストリームが異なるソースから、これまた異なる目的地へ向かうことを想定する必要があります。ESXは先進的なキューマネージメントやパス選択アルゴリズムによってこの要求に対応しています。ハードウェアの観点からは、特にESXホストに搭載されたRAIDコントローラーは平均的なコンシューマー向けPCのための検証用に搭載されたものとは異なるものが搭載されています。さらに仮想アプライアンスを利用してI/Oを高速化している場合にはこれがもっと複雑です。ストレージスタックで処理されるべきI/Oが別のレイヤ経由で処理されてしまうからです。新しいレイヤにI/Oが移動した際に、同じコントロールの元で管理ができるのか、新しいコントロールの管理下に置かれてしまうかも重要です。新しいコントロールへ処理が移った際にはコンテキストスイッチが起こります。一般的に良く言われるのがパフォーマンスの観点からはこのコンテキストスイッチが発生するのは好ましくないと言われています。ストレージスタックとCPUのスケジューラー両方の観点からオーバーヘッドが生まれるからです。
根本的に、コンシューマー向けのパフォーマンスを検証を見て、vSphere環境で同様のパフォーマンスを期待することはりんごとオレンジを比較するようなものです。デバイスドライバも違います、ディスクとCPUのスケジューラーのアルゴリズムも違います、コマンドをキューに追加、非同期でのコマンドの実行のモデルについてもWindowsとESXiとで異なっています。
Anandtechが時々「典型的な」サーバワークロードをシミュレートした32のIOワークロードの結果を公表していると、付け加えなければなりません。しかしながら、オンラインで公開されている検証結果を確認する際に、キュー深度(Queue Depth)が1なのか、キュー深度が32なのか確認する必要があります。もう一つ気をつけていただきたい点は、これらの記事はIOPSの数について、強くアピールしようとしています。IOPSが重要でないとは言いません。ですが、重要なのはI/Oのサイズも気にしなくてはいけないということです。
I/O サイズ
残念ながら、これらのサーバーベースの検証パターンはあなたが実際の組織や実際の環境で利用しているアプリケーションの状況に合致しません。機材やソフトウェアのヴァージョンが異なるということを差し置いても、負荷生成ツールは単一のI/Oサイズしか生成しないことが多いからです。負荷生成ツールが複数のI/Oサイズや異なる読み取り、書き込みのパターンを生成することが出来たとしても、あなたの実際の環境での負荷の状況を正確に再現するのはほとんど不可能です。正直にいって、これまでにあなたのアプリケーションの負荷の平均を気にしてみたことがありますか？さらにはその負荷のパターンがハードウェア条の制限なのか、実際のワークロードからの要求なのか確認してみたことはありますか？もしあなたがvFRCを利用しているのであれば、I/Oサイズの大きさを理解することは非常に重要です。vFRCを利用する場合、VMのキャッシュのブロックサイズを指定しなくてはなりません。これはアプリケーションの最も標準的なブロックサイズを指定することで最高のパフォーマンスを保証するためです。vFRCについて更に詳しい情報はDuncan氏が書いたVFRC FAQ(リンク先は英文)を参照してください。
テスト結果を簡単に比較できるようにするため、負荷生成ツールは一般的で平均的な単一のブロックサイズを利用します。IOPSを確認するためにはこれで充分です。殆どの人がIOPSやレイテンシについての議論ばかりしているのになぜI/Oサイズにフォーカスをするのか？私はレイテンシは高速化プラットフォームを評価する際にもっとも有用な評価軸だと思います。これまでに私が関わった設計ではビジネスレポートを生成するまでの時間を減らす、ログインのための時間や必要な情報を得るまでの時間を減らす、6桁にも及ぶメールボックス環境のレスポンスタイムを減らすことが全てでした。
しかし、理論的な部分に立ち戻るとIOPSとスループット、I/Oサイズ、レイテンシがお互いに密接に関わりあっています。更に数学的は スループット = IOPS ✕ I/Oサイズ であり、レイテンシはアプリケーションから見ると一つのI/Oが完了するまでの時間を示します。面白いことにアプリケーションはその処理に異なるI/Oサイズを用います。殆どの場合4KBから64KBの間ですが、メタデータ更新等の場合、とても小さい(512バイト)こともあります。さらに1つのスレッドや複数のスレッドによるランダムやシーケンシャルといった複数ブロックへのアクセスパターンのコンビネーションも重要な要素です。ここまで、私はただ1つのアプリケーションについてのみ述べてきましたが、VMkernelは公正さや発生場所によって複数のI/Oストリームを混合してしまうことを考えてみてください。(詳しくはDisk.SchedNumReqOutstandingの参考記事をご参照ください。) あなたの環境で実際に動作している一般的なワークロードを使って検証することで、高速化プラットフォームがあなたの組織にとってどのようなメリットをもたらすか理解いただけると思います。
証明がほしい？ PernixData カスタマーの実際のワークロードの様子
Pete Koehlerが勤めている会社はPernixDataの最初の製品出荷後のカスタマーです。PeteはPernixData FVPを利用するための素晴らしい記事をいくつも公開してくれています。最新の記事である「実稼働環境におけるPernixData FVPの観察(リンク先は英文)」で、最もチャレンジングなワークロードがどのように改善したかについて公開してくれています。IOPS、スループット、レイテンシの関係について述べるために、Peteは3つのフェーズからなるコードをコンパイルして実行しました。
2つ目、3つ目のフェーズでは平均して100IOPSを下回るのに対して、1つ目のフェーズの部分ではアプリケーションは多くの書き込みのIOPSを発行しています(緑のライン)。
スループットについて見てみると、最初のフェーズがもっとも多くのIOPSを記録していたのに対して、2つ目のフェーズと3つ目のフェーズのほうが更に高いスループットを出しています。これはアプリケーションがI/Oサイズを1つ目のフェーズの小さなものから後の2つのフェーズでは大きなものに変更したことを意味します。(スループット = IOPS ✕ I/Oサイズ) ではレイテンシへの影響を見てみましょう。
グリーンのラインは多くのIOPSがアプリケーションによって生成されているにもかかわらず、低いレイテンシを示しています。高速化プラットフォームが魔法のように効いているのです。アプリケーションが大きなI/Oサイズに切り替わった後、システムは多くのデータを処理することになったため、レイテンシが大きくなっています。おそらくはアレイがすべてのデータを処理しきれなくなったか、ホストとアレイ間のすべての帯域を使いきってしまったかだと考えられます。これについてはPeteが次の記事で書いてくれるようにお願いしようと思います。
実際のアプリケーションの検証と負荷生成ツールによる単一のI/Oサイズによる検証を比較しましょう。最初のフェーズで確認できたように、もしも小さなI/Oサイズを利用すれば検証の結果は非常に高いIOPSと非常に低いレイテンシを得ることができます。でも、もしもあなたのワークロードを加速させて、2つ目のフェーズの時もしくは最後のフェーズの時のパフォーマンスを確認してしまったら？結果は異なるI/Oサイズによって最初の時とは変わってしまいます。最初の時とは違って、デバイスが低いレイテンシや高いIOPSを出せないということで残念に思うことでしょう。高速化プラットフォームはちゃんと動作しており、アプリケーションが求める最高のパフォーマンスを出していたとしても、このような結果になってしまいます。
覚えておいていいただきたいこと
Peteが教えてくれたことは高速化プラットフォーム上でアプリケーションを動かす際には慎重に適切見方をしなくてはならないということです。是非Peteの記事を最後まで読んでください。有益な情報が満載です。その上で、あなたの利用しているアプリケーションで検証することが高速化プラットフォームの効果を学び、実感するために非常に重要だと言わせてください。実際に利用する環境で、実際に利用するアプリケーションを利用する、アプリケーションオーナーと話をし、ボトルネックを理解する。これが重要です。アプリケーションを高速化前にベンチマークし、前後を比較する。PernixData FVPは優れたパフォーマンスグラフを持っており、FVPによって高速化後のあなたのシステムでのスループット、発生しているIOPS、アプリケーションが記録したレイテンシについて考察することが可能です。
負荷生成による検証はダメだということですか？違います。負荷生成による検証はフラッシュデバイスの振る舞いや特性を知るためには非常に有用です。読み取りと書き込みの偏りや一貫した、予測可能な、繰り返し可能なパフォーマンスが可能か？などです。これらについては本シリーズの次の記事でカバーしていきます。
このシリーズの前の記事 :
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
