ワンちゃん、通勤ラッシュ、そしてストレージI/Oのベンチマークパート1

本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。

今回はそんなPete氏の記事翻訳第5弾です。

本記事の原文はDogs, Rush hour traffic, and the history of storage I/O benchmarking–Part 1で閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。

x86ベースのサーバやワークステーションのパフォーマンスの検証の実施は欠乏の歴史でした。20年前、システムのパフォーマンステストを行う管理者は50MhzのCPUを使ったら25Mhzのシステムよりどれだけ早くなるか、ということぐらいしかやっていませんでした。それ以上の検証はほとんどありません。哀愁が漂いますが、とてもシンプルな時代でした。

時代を少し進めます。テストは少しだけ洗練されてきました。システムの最も遅い部分(ストレージ)を検証するのが良いということに気がついてきます。ですから、手法やツールがそれに応じて創りだされてきます。ストレージはSAN装置内の専属のLUNを利用することで物理的なサーバの境界を超えて来ました。LUNは共有されてはいません、しかし、ストレージ装置の入り口であるファブリックは共有されています。にも関わらず、ストレージをテストすることは一般的には殆ど変わらずに進んできました。仮想化が単一システムの専属LUNについての気づきを与え、この状況は大きく変わってきます。今日、ファブリックやストレージシステムの全てのコンポーネントは共有されています。

検証のためのツールは移り変わります。あるものは傍流として打ち切りになり、あるツールは多くのダイアルでチューニングが出来ます。しかし、ほとんどのものは物理ホストとローカルの回転ディスクを検証する想定で動作しています。実際のワークロードを真似用途するものは多くありません。なぜそうしなくてはいけないかがわからないからです。殆どの場合、ツールは負荷を生成してパフォーマンスの計測値の最終値を導き出します。スタートとフィニッシュの間に何があろうとそれは気にする必要がないのです。

テストの手法もさほどは進化していません。｢トップスピード｣を探し出す事以外の方法というのは無いのです。様々な負荷や圧迫が共有されているということに対しての考慮は無いのです。ストレージアーキテクチャと利用されるメディアは進化してきました、しかし、検証についてはほとんど気にされてきませんでした。ほんとうに考えるべきことー仮想マシン内で動作しているアプリケーションのパフォーマンスーはスピードと多くの議論の中で迷子になっているのです。

この記事では人工的に負荷生成するストレージパフォーマンス検証(ツールやテクニック)の欠陥をお伝えします。しかし、受け取り方を間違うと、それらは全く使いものにならないと思ってしまうかもしれません。実際には真逆です。正しい用途で正しく使えば非常に有効なのです。詳しくは後ほど。

意味のある計測としてのベンチマークの欠陥

｢私はベンチマークは使わない、ユーザーがいるから｣ - 古のTwitterのことわざ

実際のパフォーマンス特性を観察する以上に優れたことはありません、しかし、そのパフォーマンス計測を繰り返し行うための良い方法を見つけ出すのは少し手間です。実際のワークロードは様々に移り変わり、環境やユーザーエクスペリエンスに異なった影響をあたえるものです。パフォーマンスのテストシステムは重要ですが、そのテストツールがどのような負荷を生成しているのかをダダしく理解してこそ意味があります。

人工的なベンチマークはいくつかのメリットを提供します。大抵は動作させやすい、そして、時にはダッシュボードで結果を表示し、あとから参照しやすくしてくれます。しかし、これらのツールとテスト手法はよくある特性を生成するだけで、実際のデータパターンを反映したものを生成することはありません。そうなると以下の様な特徴があります。

生成されるI/Oは対話的なループの繰り返しではない(訳注:ユーザーが実際に操作している場合のI/Oではない)
実際のワークロードのように動的な変数を真似てくれない
クラスタ化されたコンピューティング環境では適切なやり方ではない

これら全てについて詳細に説明が必要です。ではそれぞれ見て行きましょう。

生成されるI/Oは対話的なループの繰り返しではない

典型的なI/Oの対話は以下の様なものです。データを取得します。そしてそれに何らかの処理をします。そしてそれを送信します。ワークロードのI/Oの｢個性｣はどのようなパターンで、どれぐらい対話が行われるかにかかっています。ワークロードを長時間観察していると、しばしば何度も頻繁に繰り返されることもあります。

データを取得し、何らかの処理をし、そのデータを書き込むことを考えましょう。これは犬がボールを拾ってきて、あなたがボールに付いたよだれを拭いて、もう一度投げると考えればわかりやすいでしょう。何度も何度も、その順番で行われます。もちろん、シングルスレッドでの話です。

人工的な負荷生成はこれとは全く違う攻撃を仕掛けてきます。人工的なI/O生成器の仕事は全CPUサイクルを利用してできる限り早くキューを埋めてしまうことです。I/O生成器は周りのことは何も気にしません。データの処理を行うことはありません。そうしてほしいとは言われていないからです。比較するのであれば人工的なI/Oは以下の様なものになるでしょう。

人工的な負荷生成器では、すべてのCPUサイクルで単一のアクションを発行し続けます。全くもって意味のないReadが要求され、Writeが発行されます。もちろん、特定の生成器はReadとWriteをミックスして発生させることができますが、それでも問題は残っています。意味のある対話が反映されておらず、これでは実際のワークロードを真似ることができないのです。

実際のワークロードのように動的な変数を真似てくれない

実際のワークロードは人工的な負荷とは非常に異なったリソース(CPU、メモリ、ストレージ)消費を行います。あらゆる場合において、ストレージI/Oは様々で、ReadとWriteの割合、I/Oサイズ、そして1つのCPUから多くのCPUのスレッドへと変化します。以下の2つの画像は単一の本番か同環境の仮想マシンから実際のI/Oを6分半にわたって採取したものです(vscsiStatsとExcelのSurfaceチャートを使っています-リンク先は英語)。重たいアクティビティの最中、それだけのタイプのI/Oが生成されているかがわかります。

以下はReadのI/Oについてのものです。I/Oの数、中心となるI/Oのサイズなどを見ることができます。4Kと32Kの間のサイズが多いです。

以下はWriteのI/O数、そしてI/Oのサイズを表しています。サイズは32Kから512Kまでにわたっています。これは同じ仮想マシンで同じタイミングで起こっています。

見て頂いてお分かりのとおり、たったひとつの仮想マシンでもRead/Writeの割合が刻々と変化しています。更に重要なのはI/Oのサイズと数はありとあらゆる値を示していることです。I/Oのサイズはストレージパフォーマンスに非常に大きな影響を与えます。ですから、正確にこれを真似することは非常に困難です。VMwareのI/O Analyzerはトレースファイルを作成し、実際のワークロードを再生させることで忠実にこれを再現しようとしていますが、これでも複数のホスト上で複数の仮想マシンが様々に渡るI/Oパターンを生成しているような振る舞いを再現することはできません。ストレージ装置の解析にも期待することはできません。ストレージはこのようにデータのパターンを見ることはできないからです。

クラスタ化されたコンピューティング環境では適切なやり方ではない

大抵、ストレージのパフォーマンステストを行おうとしているほとんどの管理者は、単一のシステム(仮想マシン)をセットアップして、バックエンドのストレージのピークパフォーマンス(IOPS、スループット、レイテンシ)を検証しようとします。一見してこれは理にかなっているように見えますが、この方法ではクラスタ化されたコンピューティング環境でとりまわされているデータが通る道を反映することができません。クラスタとして配置されたコンピューティングから出てくるストレージI/Oは州をまたぐフリーウェイの通勤ラッシュのような状態になります。フリーウェイのパフォーマンスは車をその上で1台運転してみることでは検証することができません。パフォーマンスの計測ができるのは複数の車で、異なる意志、目的地、大きさを持ち、様々な密集具合で負荷をかけた時に初めて可能となるのです。近年の交通シミュレーションとモデリングソリューションはこれらの様々な変数を考慮に入れて、もっとも重要な結果を改善しています。それは実際の交通です。

残念ながら、ほとんどの検証を行う人やツールはこの｢たった一台だけの車｣のアプローチを取ります。そして、クラスタ化されたコンピューティングレイヤという近年の仮想化インフラストラクチャの最も重要な要素を考慮に入れていないのです。いまも、そしてこれからもずっと、高速なストレージインフラストラクチャは与えられた数のコンピューティングノード(物理ホスト)すべてを取り回せなければなりません。結局のところ、I/Oはいつも仮想マシンで生成されます。仮想マシンが動作している全てのホストで生成されるのであって、バックエンドのストレージで生成されるのではありません。これは大変なことです、そしてしばしば見落とされています。

以下を見てください。これは実際の環境(従来のクラスタ化されたコンピューティングとSANのアーキテクチャ)でのI/Oアクティビティをイラストにしたものです。緑のラインはReadのI/Oを表し、赤いラインはWriteのI/Oを表しています。

では、従来の人工的な負荷を生成するベンチマークのアプローチのI/Oアクティビティを見てみましょう。以下を見て分かる通り、全く異なったものになります。

実際の環境で生成されるストレージI/Oはワークロードが動作しているクラスターの数によってことなります。ですから、(完璧とは程遠いですが)最低でも以下のようなテストを行うほうがはるかに良いです。

単一ホストで生成できる負荷だけではその能力を使いきれないようなストレージを使っている場合には、この方法でストレージがどれだけの高い性能を出せるのかを確認することはよく行われています。ほとんどのストレージベンダーはこの数字を利用しています。同じ計測手法で数字を並べるのがマーケティングマテリアルにとっては優れているからです。残念ながら、これは実際の数字を図ることができていません。数字は仮想マシンから見た際の値です。実際にはどんなパフォーマンスのテストを行う際にも忘れてはいけない真実があります。ストレージ装置はかならずどこかでストレージ装置の特性もしくは通過するファブリックによって限界を迎えます。

あらゆるクラスタ化されたコンピューティングシステムにおいて、単一の仮想マシンを利用するだけではコンピューティングプラットフォームの完全な能力を図ることはできません。同じことがあらゆる分散ストレージアーキテクチャにおいても当てはまります。PernixData FVPのような、クラスタ化されたホストでの高速化ソリューションやハイパーコンバージドソリューションでは、適切にパフォーマンスを計測するために同様のアプローチが必要です。従来のデータパスを変形させる異なるアーキテクチャでのため、上記のようなテストを実施した場合、パフォーマンスの評価に役立ちます。このアプローチはどこで何をするべきなのかという重要なポイントに集中できます。仮想マシンのパフォーマンスが重要であり、物理ストレージ装置に見当違いなことをいくつもやることではありません。

全てのホストからのI/Oを適切にシミュレーションすることでストレージファブリックやすべての接続ポイントのパフォーマンスを把握するための重要な要素です。ほとんどのファブリックはトラフィックが全然ないときには非常に高速です。残念ながら、実際の環境ではそうではないのです。環境が拡張していくにつれてファブリック由来の影響が出てくるということを理解するのは非常に重要です。それはファブリックはすべてのホストへの接合点であり、ストレージからのデータ取得やデータの書き込みを行っているからです。すべて(HBA、ストレージ装置のコントローラー、スイッチなど)に負荷をかけてシミュレーションしてみる必要があります。もしそうしたことがないのでしたら、私の大好きなFrank Denneman氏の記事を読んでみてください。パート3 - データパスはクラスタリソースとして管理されていない

複数ホスト上の複数の仮想マシンでのテストを行うと、クラスタ化されたコンピューティング環境全域にわたって、仮想マシン毎に高速化(WriteのバッファリングとReadのキャッシング)が行えるFVPを最もよく活用することができます。これはなぜFVPの分離アーキテクチャが非常に拡張性が良いのかという理由を説明することにもなりますし、なぜ実際のワークロードがこのアーキテクチャから非常に大きなメリットを受けられるのかという説明にもなります。