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

PernixData FVPの新しいUI詳細とその先

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

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

本記事の原文はA closer look at the new UI for PernixData FVP, and beyondで閲覧可能です。

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

一見すると、優れたユーザーインターフェイス(UI)を作り出すことは簡単な仕事に見えます。しかし、長年にわたってとても多くのソフトウェアメーカーが実証してきたように、これはまったくもって簡単ではありません。優れたインターフェイスは目に優しいというだけではなく、そう思っていなかったとしても、記憶の筋肉の一部のようになるものです。良くないUIは笑えないジョークのようなもので、頭のなかを引き裂き、ユーザーを苛々させます。もちろん、そうしようとして作ったわけではないのです。しかし、良くないビジュアルと機能のデザインはあらゆる産業でいつも生まれてきます。あなたのお気に入りの醜い車のことを思い出してください。ある時代には全員がそれを認め、親指を立てたことがあるのです。ユーザー・エクスペリエンス(UX)の設計は科学的にも、利用者の目を惹きつけるという意味でもまだ不完全なのです。

優れたUIは意図しなくても機能を理解させてくれます。複雑なものを簡単にしてくれるのです。しかし、ただのボタンやメニューだけがユーザー・エクスペリエンスを決めているのではないのです。もっともUXデザインを方向づけるものは、他のものからなっており、ビジュアルなインターフェイスの要件は生産的で、直感的であるということです。PernixData FVPはユーザー・エクスペリエンスを高く評価されてきました。プロダクトは単にストレージI/Oを加速するだけでなく、利用者に有益で必要な情報を提供します。

なぜ変わったのか?

PernixData社の製品(FVPと、今後リリースされるArchitect)はスタンドアローンHTML5を利用したインターフェイスを備え、あなたのお気に入りのブラウザで利用が可能です。vSphere Web clientからの乗り換えは最初は不自由だとちょっとばかり驚くかもしれません。変更はやり遂げたい目標を最高の方法で解決しようという期待と必要性が込められています。従来からのコンパイルされたクライアントは多くの理由でおすすめされませんでした。ですから、スタンドアローンのUIはモダンな、ウェブベースのフレームワークを利用することにしました。

スタンドアローンへ移行するに当たり、完全なHTML 5のUIを完全に新しく書き起こし、様々な操作がそうあるべきだというように作り変えてあります。これによって誰が見ても、必要かつ十分なものにしてあります。PernixDataはVMwareの現在のFLEX(訳注:Adobe社のFlash Playerを利用するGUIフレームワーク)の影の外へと踏み出しました。制限がなくなることで、より柔軟になり、今後、もっとそうなっていきます。

UIの特徴

まず最初に気がつくのはユーザーインターフェイス自身のパフォーマンスです。高速で、キビキビ動きます。UXの不満は大抵パフォーマンスー技術的なスピードだったり、ユーザーが求めているものを素早く見つけられるかどうかーから始まります。新しいUIは従来からのUIから不要なものを取り除き、さらに、迅速に操作できるようにしてあります。

以下のイメージを見てください。複数の製品で利用できる様にUIが設計されていることがわかるでしょう。フレームワークはFVPだけではなく、今後リリースされるPernixData Architectにも利用されるようになっています。これによって、製品間の移動も柔軟で、直感的です。

Fig314

新しい検索機能

大きな環境になると、仮想マシンを確認する際に隔離し、フィルタする機能は大きな効果を発揮します。それほど多くの仮想マシンを取り扱わない、たとえば数百程度の仮想マシンであったとしても、しっかり確認していくことは難しくなります。クイックサーチ機能は検索ワードベースで仮想マシンをフィルタして絞り込んでいくのに役立ちます。仮想マシンを並べて表示しながら比較することも可能です。

Fig315ヒーローナンバーの粒度の向上

ヒーローナンバーはインフラストラクチャからどれだけのオフロードが行われたかを理解するための優れた方法です。どれだけのI/Oがデータストアからオフロードされたか、オフロードのおかげで、どれだけの帯域がストレージインフラから削減されたか、どれだけの書き込みが高速化されたかというものです。以前のヴァージョンでは数値はFVPのClusterが作成された時からのカウントだけでしたが、FVP 3.0ではきめ細やかな時間を指定してその間にどれだけのオフロードが行われたかを見ることが可能です。

Fig316キャッシュの状態を表示する新しいグラフ

以前は「Hit Rate and Eviction Rate(ヒット率と廃棄率)」というメトリックがキャッシュの利用状況を表しており、一つのグラフに統合されていました。Hit Rateは高速化層からどれだけのReadが供給されたかという割合をパーセントで表していました。Writeについては一切考慮されていませんでした。Eviction Rateは流入してくる新しいデータのための空きを作るために高速化層から廃棄されたデータの割合を表していました。これらそれぞれは今回から、それぞれのグラフに別れ、更に拡張された情報を表示します。

以下のとおり、「Acceleration Rate(高速化率)」は「Hit Rate(ヒット率)」を置き換えています。新しいメトリックではReadとWriteの両方を考慮しています。覚えておいていただきたいのは、Writeに関してはWrite-Backモードで「高速化された」ものをカウントしています。Write-Backモードでも、Write-Throughモードでもキャッシュの生成は同じアプローチです。グリーンの「Write」のラインは仮想マシン(群)がWrite-Backポリシーを利用している際にのみ表示されます。

Fig317

「Population and Eviction」(下の図)によって「Hit Rate and Eviction Rate」のメトリックの残り半分が置き換えられています。廃棄率はもはやパーセントで表示されなくなり、GBの総量で表されています。この方が高速化層のサイズが変わるとパーセントが変わってしまうのではなく、確認しやすいからです。これからはある時点でどれだけのデータが廃棄されたのかを正確に知ることができます。Population(投入)はその名の通りです。これはWrite-Policyによらず(Write-Backでも、Write-Throughでも)キャッシュに投入される書き込みのデータを表示します。つまり、後ろのストレージから初めてキャッシュに書き込まれるデータ(「フォールスWrite」として知られています)もその一部です。このグラフは環境内でどのようにキャッシュが利用されているか、より詳細を知るのに役立ちます。

Fig318

そして、もっと多くの魔法のチャートを見て、それらから得られる気づきを得たい場合にはPernixData Architectを見てください。これについては次の投稿でカバーするつもりです。

まとめ

多くの優れた機能が最新のFVPに統合されています、しかし、今回はなぜUIが変更されたのかという部分だけをご紹介致し、どのようにPernixData社の製品が進歩してユーザーや環境に適応できるようになるのかをお伝え致しました。

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