本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第3弾です。
本記事の原文はUsing a new tool to discover old problemsで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
ストレージが高速化されている時に見つかるものは非常に興味深いものです。これまではパフォーマンスの足りないアレイのせいで制限されていた仮想マシンが自由に呼吸できるようになります。プロセッサが必要なスピードでストレージI/Oを返すことができるようになります。言葉を変えると、ストレージがCPUに限界を課すのではなく、アプリケーションはストレージからの要求にただ答えることができるようになるのです。
このことを踏まえると、PernixData FVPを実装する際の手順の中でいくつかのことがわかってきます。そもそも実装とソリューション自体を理解している必要はあります。ですが、一度実際のワークロードを高速化してしまえば、FVPが提供する解析機能を利用することもできます。高速化されているI/Oを生成しているのは何なのか？どのプロセスが高速化されていないものと紐付いているのか、それはなぜなのか？I/Oサイズの変更の裏にいるのはどのアプリケーションなのか、特定のI/Oパターンが生成されているが、それは何によって引き起こされているのか？これらのうち、いくつかは事前に上げておくことができます。(詳しくは新しいストレージソリューションを買う前に不必要なI/Oの狩りを行おう(リンク先は英語)もご参照ください。) 問題となるのはI/Oのデータのパターンを発見できるのに使えるツールが限られているということです。
なぜ、これがとても重要なのでしょうか？思い出すまでもなく、リソースが限られているからです。ここにコンパイルを走らせている本稼働環境のゲストOSのCPUの観点からの例があります。最初のスクリーンキャプチャはアプリケーションの要求に対して十分なストレージI/Oが提供されています。8つあるvCPUすべてをほぼ完全に利用しています。(スクリーンショットは私の以前の記事から持ってきました。ブイーン! パフォーマンス要求を満たすためにvSphereの仮想マシンをスケールアップする その2(リンク先は英語))
以下は全く同じコードのコンパイルですが、バックエンドのストレージの負荷にさらされています。ご覧のとおり、46%もながくコンパイルに時間がかかっていますし、ビルドの際のCPUのりよう率も変わっています。
この環境の主目的はストレージの高速化でした。しかし、すべてのストレージのトラフィックが正しく、有益なI/Oであると言い切るのも微妙な状態でした。情報システムの外から来ている多くの量のトラフィックがあり、そのI/Oの生成が必要なのかどうか理解したほうが良いと思ったのです。FVPの高速化のお陰でトラフィックがより自由に流れるようになったことで、以前は露呈してこなかったパターンが見えるようになってきたのです。これが最初の発見の根幹部分です。
IOPSについて調査する小さな｢CSI｣
多くのビルドを継続して行うシステムはいくつかの種類のポーリングメカニズムを持っており、いつコンパイルされるべきコードがチェックインされたのか理解するようになっています。これは非常に軽量なプロセスです。しかし、ストレージのパフォーマンスが自由に呼吸ができるようになって初めて、以下の様なパターンとしてすべてのビルド用の仮想マシン上に見えるようになってきたのです。
以下のイメージはビルド用の仮想マシンの1時間間隔のIOPSを表示しており、この間この仮想マシンはコンパイルを実行していません。仮想マシンは5分毎に新しいビルドのためのポーリングを行っています。そうなのです、それぞれの仮想マシンの｢ビルドのためのハートビート｣はなんと450 IOPSもあったのです。
なぜ以前はこれに気が付かなかったんでしょうか？これらのスパイクは私の以前の過深すぎるストレージに抑圧されてしまい、それによって見えにくくなってしまっていたのです。これらはすべて書き込みです、そして500から600の定常的なIOPSとして落ち着いていました。(後ろのストレージから見たものは以下で確認できます。)
何が原因なのでしょうか?お話したように、ポーリングのメカニズムはソースコード管理(SVN)を呼び出し、ビルドマシンがビルドを実施する必要があるかどうかの確認に利用しています。プログラム的には開発チームは開発したスクリプトが効率的か、そうでないかわかりません。インフラストラクチャのレイヤが彼らを2つに分けてしまっているのです。(そして、悲しいことに、これが一般的なアプリケーション開発においては、もっとよく起きていることを知っています) これでとても非効率な結果に終わってしまいます。問題をよく彼らに理解させた後、これは大きな変化を遂げました。現在の5分に一度のそれぞれの仮想マシンのポーリングは1から2IOPSになったのです。
以下のイメージは30のビルド仮想マシンが高速化され、コンパイルなしで稼働している様子を表しています。
非効率なポーリングアルゴリズムだけが見つかったものではありません。いくつかのLinuxのビルドマシンは隠れた｢猟犬｣のような検索デーモンが動作したままになっていました。このクローラー(検索巡回システム)がやっているのはそのLinuxマシン内のデータのインデックスだけで、全く不要なI/Oを生成していました。Windowdではインデクサーや他のCPUやI/OのトゲをつくりだすものはGPOで簡単に管理することができます。しかし、注意していないとLinuxシステムの同等サービスの漏れは、簡単に修正できるものの、見落としてしまいがちです。
積み重なっていくメリット
ストレージを高速化する努力をする、そしてもっと効率的に見えるようにする前のアレイの利用状況を以下のイメージに表しました。(6時間の単位で、アレイから見た時のものです)
そして、私のワークロードの組み合わせをより良く理解して、さらにFVPで高速化させた同じワークロードは以下のようになりました。(6時間の単位で、アレイから見た時のものです)
推定ワークロードの値は100%よりもはるかに下がり、1日24時間、週6日安定しています。実際に稼動日において、アレイは50%から60%程度がピークの利用率でした。ビルドが行われていない場合、ビルド継続用のマシンを配置しているVMFSのボリュームは25IOPS程度だけのカーブを描き、以前よりもはるかに合理的です。
バックエンドの物理ストレージがいろいろな角度からのプレッシャーから開放され、そしてホスト上のプールされたフラッシュの魔法によって、アプリケーションとCPUは必要なストレージI/Oの分だけ追従ができるようになったのです。以下は本稼働しているビルド仮想マシンのコンパイルが行われている時のIOPSのスクリーンキャプチャです。今日までのところでは1つのビルド仮想マシンがコードをコンパイルするのに4,000IOPSも必要ないということはわかりませんでした。というのも、物理ストレージがそうした要求を満たすことがなかったからです。
結論
これらの発見はFVPなくしてありえたでしょうか？おそらく、いくつかは可能だったでしょう。しかし、優れた解析はデータを利用できる状態に翻訳してくれます。棒グラフ、パイチャート、X-Y-Zプロットなどのデータの可視化の様々な方法が存在する理由です。FVPはワークロードの高速化において優れた働きをしてくれました、しかし、それだけではなく、管理者がI/Oをより良く理解するための手助けもしてくれたのです。PernixDataの今後のツール、もしくはリリースでこの解析がどのように拡張されるのかを楽しみにしています。
ある友人が以前私にこんなことを言いました。新しいトラクターそのものよりも、いいものがあるよ、それはそれを使わないといけない理由さ。多くのケースで、技術にも同じことが言えます。仮想化はその上で実際に動作させるワークロードがなくては輝きません。PernixData FVPも同じです。実際のワークロードに対して適用し、魔法が発動し、そしてプロセスの中のデータについてもっとよく知ることができるのです。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
