株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

なぜ正確なIOブロックサイズの頻出度とワークロードの分布メトリックが重要なのか?

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はWhy accurate IO block size frequency and workload distribution metrics are so valuableで閲覧可能です。

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

ストレージのアーキテクチャの議論や比較をする際に、IOPS、レイテンシ、そしてスループットはその差別化のための主となるメトリックです。残念なことに、IOPSが業界の住人によって、ストレージ装置を比較する際の最初のメトリックとなってしまっています。正直な話、これは中毒性のある数字です。業界においては揺るがし難い影響を持っています。90年台においては3,000IOPSを実行できるシステムに皆が歓声を上げました。今では新しいSSDバイスが250,000IOPSもの性能を提供してくれています。

IOPSの値はストレージシステムの得点順位表において普遍的な単位である、そこに疑問の余地はないという所まで来てしまっています。しかし、その実、IOPSの値はそれだけでは何の意味も持たない事もわかっています。システムの特性を適切に理解するためにはIOブロックサイズをこの公式に加える必要があります。そして、私自身はあらゆるレベルの情報システム部門、つまり管理者からCIOに至るまでが正確なIOブロックサイズの頻出度を理解しておくべきだと信じています。もちろん、それぞれの役割によって必要とされる詳細さは異なります。

SLAを順守する

ワークロードのプロファイルを理解て、それがどのようにインフラストラクチャに合致するのかということを問い続けるのが今日の情報システムチームの頭のなかの大部分を占めています。以前はそれはストレージチームが中心になっていましたが、今日では仮想化管理者や設計者もがこれに挑んでいます。ワークロードのプロファイルの変化に気づくことができると、トレンドを理解した上で、インフラストラクチャやサービスを状況に応じて割り当てるなどのより高いレベルでの管理ができるようになります。それだけではなく、近年では開発チームがインフラストラクチャチームとインフラストラクチャの限界を理解しようとコミニュケーションが始まっています。こうした情報で開発チームはアプリケーションを本稼働環境のパフォーマンス特性に合わせた形で調整することが出来るようになります。今日、あらゆるチームはITインフラストラクチャをビジネス要件に合わせていくことにフォーカスを当てています。現在動作しているワークロードの特性を正確に分析し、今後動作させる可能性があるワークロードがどのように環境内で振る舞うかを理解することでSLAを順守する運用の中で得難い情報を知ることが出来ます。

顧客との会話の中で必要な(正しい)情報を得る

CTOやCIOの関心事項の中で大きなものの一つとして、自社のチームが顧客と適切に対話するための充分な正しいデータを生成できていないというものが有ります。例えば、これは開発ステージから本可動ステージにプロジェクトが移行されるときに発生します。ワークロードの使われ方が変化し、ユーザーは新しいプラットフォームを利用し始めます。人工的なテストはもう登場しませんし、インフラストラクチャに対する変更もたびたび発生します。ほとんどの開発検証環境は本稼働環境のインフラストラクチャとは異なっています。それにとどまらず、本稼働環境では負荷の同時集中や他のワークロードとの相乗効果による負荷など、そのプロジェクトが最後のステージで利用していた開発検証環境では殆ど起こらなかったような負荷も発生します。本稼働環境の機能的なキャパシティは充分なのか?とそもそもの会話が再び繰り返されます。こうした際には以前のステージと現在のパフォーマンスを適切に比較した分析データが必要となります。以前の環境とどこがちがっているのだろうか?正しいデータを簡単に入手することができればどっちのプラットフォームが今回の新しいアプリケーションにとって最適なのかを簡単に決めることが出来ますし、新しいワークロードやサービスにどのようにインフラストラクチャを適合させていくかということも明らかです。

ストレージシステムの購入プロセス

管理者や設計者の大きな問題は自身のデータセンタ内の現在のワークロードを適切に反映したデータをつくり上げることです。このデータは新しいストレージインフラストラクチャを購入しようというプロセスの中では非常に重要なデータです。ストレージベンダーは顧客にワークロードの特性とパフォーマンス要件の提出を求め、それによって顧客の供給を満たせるようにしようとします。加えて、償却完了までの期間内で、予測される将来的な成長も加味してパフォーマンスを保証できるようにします。にも関わらず、サイジングが正しくなく、ストレージ装置が性能を補いきれていないというような例は数えきれないほど見てきました。これは、大抵は正しくないデータを元にストレージソリューションに正しくない設定を施してしまったということが原因です。環境の適切な分析が行えていればこうしたコストの高くつく状況は防げるはずです。

PernixData Architect

PernixData FVPのワークロードに対してのメリットや以前には不可能だたストレージプラットフォームを構成できる能力を理解した顧客が次に口にする疑問は非常に興味深いものです。それはどのワークロードからやったらいいでしょうか?というものでした。これがPernixData Architectの誕生につながりました。ワークロードとインフラストラクチャの振る舞いについての正確な分析を提供することで、これまでにない気づきを得ることが可能になります。情報を充分に保持するハイパーバイザーを活用することで、Architectは仮想化インフラストラクチャのあらゆるレベルでの気づきを提供することが可能です。私がArchitectで最も気に入っているのは先進的な設計のビジョンにもとづいて作られているというところです。システムは運用を手助けし、そして要素的なレベルにまで掘り下げた情報を提示します。クラスタレベルから特定の仮想マシンワークロードへと抽象的な部分から特定レベルへと遷移していき、適切なタイミングで必要な情報を提示します。ArchitectがIOブロックサイズの頻度やRead/Writeの分布と言ったメトリックをどのように表示するか、よく見ていきましょう。

PernixData Architectは独立した製品でPernixData FVPが必要でない場合にもあらゆるストレージ装置を分析することが出来るとうことを覚えておいてください、。以下のスクリーンショットはすべて、オールフラッシュストレージ装置(AFA)をArchitectで分析したものです。

クラスタビュー

スクリーンショットになっているのはクラスタレベルのワークロードの概要です。ここにはvSphereクラスタで動作している全ての仮想マシンでのRead Writeの分布の概要が表示されています。青いバーで表示されているのはvSphereクラスタ内で生成しているすべてのI/OのI/Oブロックサイズの分布です。

バーの上にマウスカーソルを乗せると、特定のブロックサイズについての更に詳細な情報が提示されます。この場合、全体のIOブロックのうち17.2%が4Kよりも小さいということになります。何故この情報が重要なのかということと、4Kよりも小さなブロック仮想マシンのパフォーマンスとストレージのオーバーヘッドを理解するのに役立つかということは後々の記事でお話します。

Fig402

IO Frequency(IO頻度)ビュー

IO Frequencyビューを選択すると、Architectによって更に詳細なビューが表示されます。ReadとWriteの操作がわけられて表示されるようになります。グリーンの色の濃さがブロックの頻出度を表します。マウスカーソルを乗せると、その特定のI/O操作が全体のI/Oのどれだけに当たるか、など詳細な情報が表示されます。

Fig403

Architectではユーザーにとって適切な期間での分析結果を表示することも可能です。管理者は特定の期間をドリルダウンして見ることもできれば、長い期間でみてトレンド分析のレポートを作ることも出来るようにしてあります。

Fig404

こうしたメトリックは仮想化インフラストラクチャの複数のレベルで見ることが可能です。これによって仮想マシンの振る舞いについて、ターゲットを決めて探索を行うことが出来ます。以下のスクリーンショットSQLを動作させている仮想マシンスクリーンショットです。管理者が(クラスタレベルでの表示と同じような情報に)アクセスをしようと思えばすぐに行えるようになっています。

Fig405Architectは刻々と変わりゆく仮想マシンのワークロードや仮想化インフラストラクチャの振る舞いを継続的に表示してくれます。Read/Writeの分布やI/Oブロックサイズの頻出度などの正確なメトリックはストレージインフラストラクチャの購入のプロセスを成功に導くためには重要なデータです。また、SLAを管理し、順守していく際に重要な影響をもつ、差分分析、ワークロード要件分析などを提供します。「Maximizing performance with the correct drivers - Intel PCIe NVMe driver(訳注:翻訳予定なし)」という記事でふれたとおり、Architectは主だったストレージのメトリクスの詳細なパフォーマンス分析も提供しています。こうしたメトリクスで現在の環境や、新しいストレージを購入する際のPOCの環境などのインフラストラクチャの振る舞い分析をより精緻なレベルで行うことが出来るようになります。PernixData Architectについての記事はまだまだ続きます。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)