本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はThe hit rate metric, an elementary metric in your virtual toolboxで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
この記事は「高速化プラットフォームの評価」シリーズの一部であり、その中の「高速化レイヤアーキテクチャとI/Oリクエスト」で私はなぜ、通常よくパフォーマンスの検証のために行われる評価手法がFVPのような高速化プラットフォームを追加したインフラストラクチャのパフォーマンス検証で利用できないのかを説明しました。
読み取りの高速化
読み取りの高速化を行う場合、気に留めておくべきは2回目以降の読み取りアクセスです。読み取りのパフォーマンスを高速化するためにはデータがフラッシュデバイス上に存在していなければなりません。このためにはフラッシュデバイス上に直接書き込みデータを格納するか、データを「裏書き」させなくてはなりません。裏書きは要求されたデータがフラッシュデバイス上に存在しない場合に発生します。データはデータストアから読み込まれ、アプリケーションにデータを渡すと同時に、フラッシュデバイスにコピーされます。
一度データがフラッシュデバイス上に保管されると、このデータに対するI/Oの操作のリクエストはフラッシュデバイスから行われるようになります。不思議に思う方もいらっしゃるかもしれませんが、読み込んだ後に書き込む(Read After Write = RAW)操作はアプリケーションの観点ではよくある操作です。
リクエストされたデータがフラッシュ上にある場合、これをキャッシュにヒットしたと考えます。このヒット率の評価基準がパフォーマンスのトラブルシュートを行う場合にはとても重要になります。単純にいうと、このヒット率はレイテンシーへ変換することが出来ます。新しい層が登場しているため、読み取り、書き込みは複数のターゲットを持つことになっています。ターゲットへのレイテンシの特性、フラッシュデバイスのレイテンシ、データストアのレイテンシです。どのターゲットに対してI/Oのリクエストが発行されているのかを確定しなくてはなりません。
エンタープライズレベルの高速化プラットフォームを利用している場合、この情報は絶対に提供しなくてはならないと思っています。VMware vSphere Read Cacheはesxcliコマンドでこの情報を提供しています。(詳しくはDuncan氏の素晴らしい投稿(訳註:リンク先は英語)を参照)。FVPはパフォーマンスグラフでこの情報を提供します。
理論を検証
このパフォーマンスのグラフを見てください。この検証ではビデオサービスを提供するアプリケーションを利用しています。最初の検証ではアプリケーションはユーザーのリクエスト毎にビデオを取得しています。ビデオはサーバにとって新しいコンテンツなので、ビデオはデータストアから取得されます。この場合ヒット率は0となります。
レイテンシについて見てみると、実効レイテンシがデータストアのレイテンシとほぼ同じであることがわかります。実効レイテンシは仮想マシンから見た際のレイテンシです。
この後、別のユーザーが同じビデオを再度リクエストした場合、データはFVPがアプリケーション動作中に裏書きを行い、コピーしておいたフラッシュデバイスから提供されます。この場合のヒット率は100%になります。
面白い点はトータル実効レイテンシの数値が以前はデータストアのレイテンシであったところから、今度はローカルフラッシュのレイテンシに近い値になったということです。こうなってしまえば、データストアがどれ位読み書きを行っているかということは、I/Oを提供する上で問題にならなくなります。アプリケーションは低レイテンシで非常に安定した予測可能なパフォーマンスを得ることができるようになります。
DRSを動作させる
ローカルフラッシュからのパフォーマンスは変わる可能性があるパーツを避け、減らすことに大きく貢献します。共有ストレージネットワーク、ストレージコントローラーやディスクスピンドルプールを抱え込む別のワークロードなどはもはやなくなっています。しかし我々は2014年もすぐに迫る2013年(訳註:原文記事の公開は2013年12月23日)を生きているのです！仮想マシンが移動してしまうことは今日のデータセンタの運用手順書の中にしっかりと根付いています。FVPは仮想マシンの移行を一元的なフラッシュリソースのプールを提供することで完全にサポートしています。I/Oはローカルフラッシュデバイスからはもちろん、リモートフラッシュデバイスからも提供可能です。
FVPの注目すべき振る舞いはリクエストに対しての、データの提供の仕方です。不要なオーバーヘッドを避けるようになっています。アプリケーションがデータをリクエストした際に、FVPはそのデータをフラッシュデバイスから返します。これはリモートからのこともあれば、ローカルからのことも有ります。さらにFVPはフラッシュ上のキャッシュを可能な限りアプリケーションに近づけようとし続けます。つまり、リモートフラッシュデバイスからデータが提供される場合には、ローカルフラッシュデバイスへコピーしてくるということです。2回目以降の読み取りがアプリケーションに最も近いフラッシュデバイスから提供されることを保証するわけです。詳しくは「PernixData FVPのリモートフラッシュアクセス」を参照してください。
この仮想マシンは別のホストに移行し、09:54 AMに同じビデオファイルを見てみました。
データの要求に対して、取得はフラッシュプールから行われています。このため、パフォーマンスグラフはキャッシュへヒットしているということを示しています。しかし、レイテンシにおいてはリモートフラッシュデバイスからデータを転送しているために通過するパスが長くなり異なる結果が出ています。
実効レイテンシはローカルフラッシュやストレージのレイテンシに従うのではなく、ネットワークのレイテンシに従っています。もっとよく見るためにカスタムパフォーマンスからネットワークフラッシュの読み込みとローカルフラッシュの読み込みを抽出しました。
このグラフではリモートフラッシュデバイスがI/Oの要求に答えていることを確認できます。仮想マシンが移行前に動いていたホスト上のフラッシュデバイスです。
このビデオを2分ほど再生していますが、以前のホストでは5～6分再生しました。ユーザーは2回目のビデオ再生を行いますが今度の再生時間は最初の2つのテストと同様です。
ヒット率ですが、今度も100%です。I/Oがフラッシュデバイスから提供されていることがわかります。しかし、どっちのフラッシュデバイスでしょうか？FVPがデータをローカルフラッシュデバイスにコピーしたため、ビデオの最初の3分間はローカルフラッシュから提供されています。リモートフラッシュの値は最初の3分間は一切活動しなかったということを表しています。しかしながら、ビデオが前半3分を超えたあたりでFVPによって再度リモートフラッシュデバイスから取得されています。
これはどのようにレイテンシに影響するでしょうか？
検証は9:59にスタートしています。実効レイテンシはローカルフラッシュデバイスのレイテンシに近い値を示しています。3分が経過後、レイテンシはリモートフラッシュのレイテンシの値に近くなっています。
私がこの検証をおこなった際にはオールフラッシュアレイの環境を専有して実施したことを付け加えておきます。一般的にはストレージアレイのレイテンシが大きすぎるため、レイテンシが消えてしまい(グラフで確認できないほど小さくなってしまい)ここで見えているような小さな値を見ることが出来ないからです。
レイテンシを見る前にヒット率をチェックしましょう
レイテンシはパフォーマンスのトラブルシュートを行う上でもっとも支配的な評価軸の一つです。しかし、高速化プラットフォームを利用する場合にはヒット率を最初にチェックしてください。これによってどのレイヤがI/Oのリクエストに答えているかを知ることが出来るからです。ヒット率が仮想ツールボックスの最初の評価軸になります。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
