本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第6弾です。
本記事の原文はDogs, Rush hour traffic, and the history of storage I/O benchmarking–Part 2で閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
パート1の｢ストレージI/Oベンチマークの歴史｣では人工的なベンチマークは単純すぎて意味があるレベルでストレージのパフォーマンスを生成したり、計測したりすることは難しいというお話をさせていただきました。実際のワークロードを再現することは非常に簡単なことのようにみえるのですが、その実、非常に複雑で技術的、そして技術的ではない問題の双方をはらんでいるのです。
- ワークロードの特性を測るために必要なのは推測です。正しい要素を観測していると理解して始めて、テストのためにシミュレーションが行えるのです。どんなツールを利用しているかよりも問題をどのように捉えているかが重要です。ほとんどのツールが不適切な値を表示しています。ストレージ装置はディスクアレイを監視するためには非常に優れたツールですが、仮想マシンやアプリケーションのパフォーマンスについては不完全なのです。
- データセンタのパフォーマンスを理解するためには特定の問題に対する専門性の境界を超える必要があります。従来型のストレージの管理者はディスクアレイが見ているのと同じように世界を見ています。ブロック、LUN、キュー、そして転送プロトコルです。パフォーマンスについて聞いてみると、レイテンシ、RAIDのストライピングの効率性、そしてRead/Writeの取り回しなどの繰り返しのひとりごとを聞かされることでしょう。仮想マシンから見えているレイテンシについてはどうでしょうか?これについて言及されないことに驚かないでください。これは管理者の問題では無いのです。というのも、彼らのインフラストラクチャに対する視野はアクセスコントロールで制限されているからです。
- フラッシュのようなテクノロジーを利用するソリューションを紹介するとき、言葉自体が大きく取り上げられ、テクノロジーはさほどでもありません。名前がすぐに早く、そして、スーパーヒーローのような品質を想起させてしまいます。素晴らしい業界のマーケティングによってこれがひとつの障壁になってきました。ストレージソリューションは、あとからFlashを利用するテクノロジーが登場し、周知の事実として過去の何よりもどんな場合も速いとされてしまったため、正しいテストをなされていないことがあります。単純化のために誤解もよしとしたのです。
パフォーマンスを評価するためにはインフラストラクチャ、ワークロード、そしてそれが動作しているソフトウェアプラットフォームをバランスよく理解する必要があります。これは非常に時間がかかりますし、正しいツールを見つけ出す必要がありますーが、大抵はみつかりません。パート1では実際のワークロードの特性は再現しにくく、クラスタ化されたコンピューティング環境では誤ったアプローチであると述べました。残念ながら、それだけでは済みません。他にもまだ考えなくてはいけないことが残っています。ストレージパフォーマンスの階層レイヤの特性や、そのレイヤ間をどのようにデータ移行させるかというロジックです。
ストレージパフォーマンスの階層化
ほとんどのデータセンターが複数の永続ストレージと様々な形のキャッシングとバッファリングでストレージのパフォーマンスを提供しています。人工的なベンチマークはこれらの階層に非現実的な動作を強要します。殆どの場合、これは理解ができない事態に陥ります。というのも、階層のサイズやデータのハンドリングはストレージベンダーによって検証を行う人にとって、あいまいか、分からないという状態にされているからです。我々にわかっているのはストレージの階層化はそれなりの形とサイズで確実に入っているというこということだけです。それは従来型ストレージのデータの先読みの技術であったり、ハイブリッドアレイであったり、PernixData FVPのような分離アーキテクチャであったり、ハイパーコンバージドソリューションであったりします。現実的にはこの階層化はあらゆる時に起こっています。
覚えておいてください。この環境をテストするためには2つの別々のアプローチがあります。
いずれのアプローチがあなたにとって正しいものでしょうか?目的によってはどちらの方法が正しいこともあり、間違っていることもあります。さて、通勤ラッシュの例を再度取り上げましょう。
- 電気自動車はたかだか航続距離が100マイルぐらいなので、嫌がる人がいるかもしれません。ですが、通勤が1日辺り30マイルを超えることが殆ど無い場合には?これをキャッシュやバッファの層だと考えてください。キャッシュの階層が非常に大きく、95%ものI/Oを捌けるとしたら、パフォーマンスの低い階層のストレージのパフォーマンスの検証にフォーカスする必要はなくなります。
- 同じ車で、この車のオーナーが職を変え毎日200マイル運転するようになったとしましょう。そうなるとこの車はソリューションとしては非常に貧しい物になります。同様にストレージアレイ外20GBのキャッシュ･バッファの領域しか持っていないにもかかわらず、100TBの保存ストレージ領域があったとします。実際のストレージの領域上で動作しているそれぞれの仮想マシンは20GBのキャッシュ領域からだけではほとんどメリットを受けられない事になります。こうした場合はストレージの低い層のパフォーマンスを検証する方が良いです。
ストレージのすべての層からデータが読み出されることを想定した検証はどうですか?2つの負荷を一緒に走らせてみるのが理想的ですが、実際のデータがどの階層にあるのかということをシミュレーションすることは難しく、実際のワークロードでの振る舞いをどれだけ反映しているのかということを判断することも難しいです。これはキャッシュ層のサイズの不足がどれだけなのかということ判断できないということと、階層を隔離できないためです。このため、殆どの場合、このアプローチは皮肉な結果に終わります。 つまり、事故です。(訳注 : この検証はやっても意味が無い)
人工的なワークロードを生成して、そのワークロードのほとんどがWriteであった場合、簡単にバッファの上限のしきい値に引っかかってしまうことがあります。繰り返しになりますが、これはベンチマークはCPUサイクルのすべてを使ってWrite I/Oを生成するためで、現実的な時間の間隔を開けてくれるわけではないからです。非常に書き込みが多い環境であってもまったくもって現実とは異なっています。これが階層化ストレージソリューションで人口的なベンチマークを行う際の真実です。ほとんど現実の環境では起こりえないのです。
巨大なテストファイルを利用し、Read I/Oを人工的に生成しているような場合、このReadはキャッシュ層にヒットすることもあり、他の場合はパフォーマンスの遅い階層へとヒットします。それによって結果散在してしまいます。この結果のためにテストを長く走らせるということを行う場合もあります。ですが、問題はテストのやり方であって、テストの長さではありません。仮想マシンのワーキングセット(データが良く動いている量)を理解することが鍵で、環境に合わせてどのように懸賞を行うべきか翻訳すべきなのです。どのようにワーキングセットのサイズを決めるかって?これは将来の記事のために残しておきます。究極的にはこれは実際のワークロードの問題です。ですから、実際のワークロードを真似できる限り真似すればより良くなっていきます。
ストレージキャッシュへの格納と廃棄、全てのキャッシュは同じではない
ストレージソリューションのキャッシングのレイヤはありとあらゆる形や大きさになっています。しかし、どのようにそれが利用されるのかというのは簡単にはわからないルールに依存しています。とても重要な特性の2つの例として:
- キャッシュ内にどのようにデータを置くか。｢データ先読み｣のアルゴリズムのようなものを利用しているか?その階層がバックエンドのストレージから読みだしたデータ以外に、Write-Throughキャッシングでもデータを読み込むのか?
- キャッシュからどのように廃棄するデータを選ぶのか。階層は｢先入れ先だし｣(First-in-First-out : FIFO)を利用するのか、再長時間利用されなかったもの(Least Recently Used : LRU)を利用するのか、参照頻度が最も低いもの(Least Frequently Used : LFU)を利用するのか?または、廃棄に他のアプローチを利用するのか?
人工的なベンチマークはこれにうまく対応していません。ですが、実際のワークロードはこれに大きく依存しますし、本番環境では違いが出てくることになります。
他の検証の誤り
テストを行う際に十分な手がかりがない場合のために、以下にいくつかのストレージパフォーマンス検証においての典型的な誤りを列挙しておきます。
- アプリケーションに可能な限り近くでテストを行っていない。こうした機能検証はアプリケーションが(そしてそれが動作しているOSが)実際のデータをどのように扱っているかをよりはっきりさせて行うべきです。
- 検証時間が長い。(数時間に及ぶ)人工的なベンチマークから得るものはほとんどありません。大したことはわからないので、時間の無駄です。
- ベンチマークツールのパラメーターを軽んじる(ただツールを動作させるだけ)。設定が重要です、そうでなければ全く別の結果が得られることになります。
- 環境のRead/Writeの割合を間違う。割合をIOPSやスループットで計算していませんか?この2つだけでも別の結果が得られてしまいます。
- ReadとWriteの環境内での典型的なサイズを間違う。どのようにI/Oのサイズを決めていますか?
- ReadとWriteを2つの独立したものだとして検証する。実際のワークロードはそうではありません。ですからこれらを分けて検証する理由はありません。
- ベンチマークによる最終｢得点｣だけを利用する。フォーカスすべきは検証の最中の振る舞いです。特にフラッシュのようなテクノロジーの場合、ガーベージコレクション技術や他のレイテンシがスパイクさせてしまうイベントなどに細心の注意を払う必要があります。このスパイクこそが問題です。
テストを行っている人々はしばしば検証の妥当性を争うあまり、検証方法や、このブログの記事で紹介しているような誤りが排除できるような標準を押し付けてきます。残念なことに、どんな状況においても、これはうまくいくことはまずありません。問題になっているのがあなたのデータであり、あなたのワークロードだからです。
人工的ベンチマークの良い利用方法
人工的なベンチマークや人工的な負荷生成器は意味が無いと思うようになってしまったかもしれません。そうではありません。実際、私はそれをよく利用しています。違うのは一般的な知識でいわれているような利用の仕方をしていないことです。本当のメリットは実際のワークロードをシミュレーションできないという事実を受け入れてからです。以下は非常に有用なシナリオ野内の幾つかです。
- 定常的な負荷の生成。これは少ない数のシステムが負荷を生成しているような仮想環境の場合には特に有効です。環境を学び、トラブルを発見するのに役立ちます。
- 小さなベンチマーク。本当に小さなワークロードのかけらで、テストや評価をしようという場合です。5秒から30秒ほどの長さですが、ほんとうに必要なものを見つけ出すことができます。I/Oが生成されている際に何が起こるかを観測するためで、絶対的なパフォーマンスを図ろうというものではありません。こちら(訳注:リンク先は英語原文)に良い例があります。
- 独立したハードウェアコンポーネントの比較。新しいSSDと古いSSDと後k街を見るのに非常に良い方法です。
- 大きなアーキテクチャの幅広い動きを理解するために利用する。
観測、学習、そして検証
意味のない状況を｢検証｣して時間をムダにしないために、vCenterやesxtopや他の方法で、統計を集める時間を作ってください。ベンチマークを走らせる前に、今あるワークロードをよく知るのです。例えば、もしもSQLのパフォーマンスを改善したいのであれば、いくつかの検証をシリーズとして作成するか、既存のSQL内で実行されているバッチジョブを変更してベースラインを確立して、振る舞いを観察するのです。負荷集中時や負荷が低い時間帯の両方でテストを行うと、それぞれで素晴らしい結果が得られます。このアプローチは私がコードのコンパイル環境を最適化する際に非常に役に立ったアプローチです。
まとめ
ストレージのパフォーマンス検証はディスクアレイの検証ではないという事実を忘れないようにしてください。あなたのワークロードがあなたのストレージアーキテクチャに対してどのように動作するのかという検証なのです。実際のアプリケーションはいつも事実を告げてくれます。このような答えを望まない理由は再現性がなく、正しく計測することが難しいということです。正しく検証を行う方法はアプリケーションのデマンドを正しく理解するための時間を費やし、それを環境に取り込むことなのです。
さて、やることはたくさんありますね。ハッピーテスティング!
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
