性能指標

次に、ストレージの性能について解説します。

性能指標

IA（インテル・アーキテクチャ）の世界では、CPUのロード・アベレージによって性能を管理することが一般的でした。これは、I/Oも含めてサーバーのCPUに依存する処理が多く、1つの指標で全体を把握しても大きな間違いはない、という前提に立っています。

しかし、現在は、いろいろな処理がオフロード（サーバーのCPUから処理負荷を切り離すこと）するようになっているため、サーバー単体の負荷だけではシステム全体の負荷を把握することが出来なくなっています。

汎用機（メインフレーム）も含めたエンタープライズ・ストレージの性能管理指標には、以下のようなものがあります。

• 応答時間（レスポンス・タイム）
• スループット（トランザクション量、データ転送量）

仮想化環境において重要な指標は、レスポンス・タイムとトランザクション・スループットです。複数の仮想サーバーからの多数のI/Oに対して、安定して速い応答を実現することが重要です。一方、大量のデータ転送を行うようなアプリケーションは、仮想化環境には向かないといえます。

したがって、データ転送量の性能指標（MB/s）については、それほど気にする必要はないでしょう。目標トランザクション・スループット（IOPS）を実現できていれば、結果的にデータ転送量も問題ないと考えてよいと思います。

IOPS

IOPSは「入出力（Input/Output）回数 Per Second」の略であり、1秒あたりにいくつのトランザクション（I/Oパケット）を処理できるかを示しています。

仮想化環境のストレージ管理は、IOPSの管理に尽きるといっていいでしょう。高いIOPS処理能力を実現していれば、おのずと応答時間も速くなります。IOPSを高めても速くならないI/O処理は、仮想化環境はやめて単独のシステム構成を採用すべきです。

しかし、各ストレージ・ベンダーは、IOPSを公表していません。このため、事前に検証テストをさせてもらい、ある程度は推測（期待）で導入することとなります。ホワイト・ペーパーなどで「高いIOPSを実現した」とアピールしている場合もありますが、以下のような落とし穴があるため、注意してください。

• IOPSのブロック・サイズが小さくないか。
• ディスクを最大構成としていないか。

ベンダーが公表しているベンチマーク・テストというのは、非現実的な構成のケースが多いので、あまり真剣に受け取らないほうがよいでしょう。実際の運用現場で出すことができる性能値に関しては、よく注意して検証する必要があります。

LinuxのWebアプリケーションにおけるI/Oブロック・サイズは、通常は4KB程度です。このため、4KB程度のトランザクション性能を重視してください。高価格で高性能なエンタープライズ・ストレージは、もっと大きなブロック・サイズ向けにチューニングされていることが多いので、注意が必要です（特にメインフレームやUNIX系の製品）。

ストレージ・ラインナップへの反映

GS10-IIでは、仮想サーバーへのIOPS処理能力ごとに、異なるストレージを適用したメニューを用意しました。アプリケーションのI/O要件に合わせて（ストレージ性能が異なる）仮想サーバーを選択できるようにしました。

図2に示したレスポンスの数値は、あくまでも目安であり、この数値を保証するものではありません。また、IOPSの値は、sarコマンドから取得できる512B単位の値を換算して求めた数値であるため、実IOPSとは異なる点に注意してください。

性能管理について

ストレージ性能がいくら高くても、そこにアクセスするI/O量（仮想サーバー数）が多ければ、パンクしてしまいます。このため、GrowServerでは、以下の2つの指標で運用管理を行っています。

応答時間

各仮想サーバーからの応答時間が50ms（ミリ秒）以内になるように監視する。常時50msを越えるようなサーバーについては、アプリケーションのチューニングやリソースの追加、高性能ストレージの利用などを提案する。

ボリュームあたりのIOPS

仮想化環境では、1つのボリュームを複数の仮想サーバーで利用する。同じボリュームを使っている仮想サーバーのトランザクション量を合計した数値をもとに、ストレージ・ボリュームの性能を管理する。この値が性能限界を超える場合は、仮想サーバーの再配置を行う。