私は年に100件近くのお客様のストレージのコンサルテーションを行っています。
その中でよくある話。
「このストレージはパフォーマンスはどれぐらい出るんですか？」
「10万IOPS出せますか？」
「このストレージに移行して問題なくパフォーマンスが出せますか？」
答えとしては環境によるので一概に言えない、という答えになるのですが、それでは身も蓋もないですね(笑)
今回はこのストレージのパフォーマンスについての考え方について書きたいと思います。
ストレージのパフォーマンス指標
まず、ここで聞かれているパフォーマンスですが、ストレージの処理能力のことを指していて、その指標としては主に以下があります。
・IOPS(I/O per second。一秒あたりの入出力処理の数。最近はFlashの台頭もあり、数十万IOPSを出せるストレージもあります)
・MB/sec、GB/sec(Megabyte per second、Gigabyte per second。一秒あたりの入出力処理容量。こちらも最近は数GB/secを実現しています)
・レスポンスタイム、応答時間(1処理あたりにかかる時間。これまでは数ms(ミリ秒)がほとんどでしたが、Flashにおいては数百μs(マイクロ秒)まで高速化しています)
多いのはIOPSのみを指標にしてパフォーマンスの見積もり、提案をされるケースです。しかしこのIOPSの数字にのみ着目するのは間違っています。
ストレージに多少携わっている方は以下のようなグラフを見たことがあるかと思います。これはストレージのパフォーマンスを表しています。
見方としては、4KB Readで100%キャッシュヒットしている場合、10000IOPSで1I/Oあたりの応答時間が2ms程度、80000IOPSだと5ms程度、100000IOPSだと、10ms程度になるという見方をします。
つまりIOが増えていくに連れて応答時間が長くなる、という事になります。
この応答時間は重要で、これが長くなればなるほどお客様の業務処理に跳ね返ってきます。
100000IOPSの場合、「100000 x 10ms=1000sec」というように処理に1000秒かかるということになります。
IOPSなので、1000秒はおかしいと思われるかもしれませんが、実際にはこれは並列で動かせば1秒で終わる処理という事になります。
100000IOPS出せたとして、応答時間が1msなのか10msなのかで全体の処理時間は10倍も異なることになりますので、IOPSを見る場合は、応答時間も気にする必要があります。
また、応答時間が10msを超えるようなケースはストレージとして限界が来ていると考えられます。一般的には5ms程度が良好なパフォーマンスかどうかの境目とも言われています。
ただし、この一般的な数値は必ずしもすべての環境に適用できるわけではありません。
例えば、ある処理が2msで済んでいるような環境に、同じ処理をした場合に5msの応答時間のストレージを持ってくると処理時間は2.5倍になります。
お客様業務として処理時間が2.5倍になることを許容できるのであれば問題ないですが、それが許されなければ5msは良好なパフォーマンスとは言えません。
バッチの処理が長くなった、というお客様はこの応答時間が伸びているケースがよくあります。キャッシュミスをしてHDDにアクセスをしたりすると、キャッシュヒットした場合と比べて格段に遅くなります。キャッシュヒットだと1msなのが、キャッシュミスだと5msになる、ということもよくあります。従って、キャッシュにヒットするかしないかというのは重要です。Flashを使用している場合はキャッシュがなくても高速なI/Oが出来ます。
また、I/OがReadなのかWriteなのか、ReadとWriteの混合なのか、その場合のI/Oのブロックサイズはいくつなのか、によって結果の値も全く変わってきます。
通常、ブロックサイズが大きくなると、出せるIOPSは少なくなります。ブロックサイズが大きくなると処理の内容もランダムからシーケンシャルの処理になる傾向にあります。
ランダム処理とはデータベースのトランザクションのような処理で、シーケンシャルは動画の読み書きだったり大量のバックアップを行うような処理になります。
ちなみにMB/secという指標はIOPSとは別物の指標ように捉えられている方もいますが、実際は「MB/sec=IOPS x I/Oの平均ブロックサイズ」となるので、全く異なる指標ではありません。
ランダム処理は一秒あたりのトランザクションが重要なため、IOPS、シーケンシャル処理は一秒あたりの処理量が重要なため、MB/secという指標を用いるのです。
ストレージのパフォーマンスとお客様のパフォーマンス要件は同じではない
ストレージのパフォーマンスは先に上げた項目で判断しますが、実際のお客様は、業務がお客様の希望する時間内に終わることや、ストレスなく業務ができる事が要件となることがほとんどだと思います。
例えばバッチ処理が2時間以内に終わらければいけない、という要件があったとして、ストレージが10万IOPS出せることと直接は結びつきません。なぜならば負荷の内容が分からないからです。
つまり冒頭に挙げた会話の内容は、お客様の要件がストレージの処理能力に言及していなければ、意味のないものということになります。
お客様の業務用件を満たすことが出来るストレージを提供するためには、詳細にストレージの負荷の内容を把握する必要があります。
それはパフォーマンス・サイジングの元になるような以下の情報です。
・Read/Writeの割合
・Read/Writeのブロックサイズ
・IOPS
・ストレージのキャッシュヒット率
IBMではDiskMagicというツールがあり、これらのデータをプロットすることでIBMストレージの処理能力を見積もることが可能です。
更改や増強案件などであれば、既存のストレージからデータを取得すれば比較的精度の高い見積もりが出来ます。
既存で使用できるようなデータが無い場合は、データ量や同様のアプリケーションのI/O特性から当たりをつけてサイジングを行います。
そのようなデータもない場合は、ごく一般的なOLTP(Read7:Write3 ブロックサイズ4～8KB、キャッシュヒット率50%)というような値でサイジングを行ったりします。
ここで注意が必要なのは必ずしもすべての環境でこのパフォーマンスが満たせるわけではないということです。
パフォーマンスの結果を受け入れろ！出なくても騒がない！
パフォーマンスはストレージのみならず、サーバーやアプリケーションの処理など様々な要因で変わりうるものです。
当然見積もりやスペック通りのパフォーマンスが出ないということもあります。
お客様環境で、「とある負荷をかけたらスペック通り、期待通りのパフォーマンスが出なかった」という話をよく聞きます。
「これって正しいんでしょうか？そういう可能性ってあるんでしょうか？」というおかしな質問もあります。
よほどの不具合でない限り、答えは「正しい結果で可能性は100%」です。そういう結果として出ているわけですから夢ではなく現実のものです。
その環境には、その結果を出す原因があり、それは設定だったり、構成だったり、負荷のかけ方だったり様々です。
例えばioなんちゃらとか、Crystalなんちゃらとかの負荷ツールを使用して、他の結果と違うというのはまさにツールの負荷のかけ方が違ったりするからです。
スペック通り、見積もりどおりのパフォーマンスを出そうとするベンチマークをするところもありますが、これもあまり意味がないこともあります。実際の業務負荷とは異なるからです。
ストレージのパフォーマンスのゴールは処理能力の限界を出すものではなく、お客様の業務要件を満たすことにありますので、この点に注力する必要はありません。
要件や環境にもよりますが、多くのお客様環境ではストレージの限界値を出していることはほとんどなく、I/Oは少ないけれども、短い応答時間が求められたりします。
結局のところ、ストレージの処理能力を追い求めるのではなく、お客様要件を満たすことができればそれで良いのです。
パフォーマンスは定常的な監視が必要
パフォーマンスは生き物です。常に変動します。日中時間帯の処理、夜間のバッチ処理、バックアップの処理など全く異なる負荷がストレージにかかります。
昼間は大丈夫だけど、バッチが遅いとか、その逆もあったりするでしょう。特定の負荷だけに耐えられるようなストレージではいけませんし、ある日突然遅くなる、ということもあります。
遅い時、遅くなった時に、なんで遅くなったかを分析する足がかりの一つとして、正常な状態であった時のパフォーマンスデータが必要となります。
このデータがないと今までがどうだったのかというのが分かりません。いざパフォーマンス問題が起こった時に、そのデータがない、というケースも散見されます。
ですので、定常的にデータを収集するようにしなければいけません。
Spectrum ControlはIBM Storageのパフォーマンスデータを自動で収集してくれます。DS8000系やSpectrum Virtualize系に対しては非常に有用なツールですので、一緒に導入することをお勧めします。
最後に、繰り返しになりますが、パフォーマンスは数字を達成することが重要なのではなく、お客様の業務要件を満たすことが重要であるということを覚えておいて頂けると幸いです。