第三歩 性能分析で仮想化の効果を最大化しよう：プライベートクラウド化のA to Z

前回解説した、プライベートクラウド化についての評価項目について、ポイントとなるパラメータを個別に紹介しよう。

[小坂剛生（EMCジャパン），ITmedia]

プロセッサに関する分析のポイント

　プロセッサについては、ここ数年で進化が著しかった要素の１つであり、ユーザーが所有しているものも、さまざまな種類があることと思う。数年前（4〜5年前）のシステムであれば、たいていのものはコアが1つしかないが、最近のシステムでは、比較的エントリークラスのサーバを購入しても、複数のプロセッサコアが搭載されたマシンが、容易に入手できてしまう。

　性能分析での評価は、収集したデータの平均値、および収集したデータの平均が最も高かった値をピークとして検討する（ここは分析においても重要なポイントとなる）。平均値だけでは、まったく使用されていない時間帯を考慮しなければならなくなるし、ピーク値だけでは高い値になり過ぎてしまう）。

　プロセッサ関連では複数のパフォーマンスカウンタがあるが、まず％Processor Time(_Total)を見ておこう。最後の（_Total）はすべてのプロセッサの合計を示している。例えば2プロセッサコアのマシンであれば、%Prosessor Time(_Total)では2つのプロセッサ合計の利用率を示している。プロセッサの年式にもよるが、この値が常に高い場合には注意が必要となるが、平均値が1〜5％程度であれば、プロセッサの利用状況はきわめて低いと言える。

　次に、System Processor Queue Lengthも確認しておきたい。これは、CPUの実行待ち命令数を示すパラメータである。CPUの使用率が高ければ、命令待ち行列も増えることがあるのだが、CPUの使用率が低いにもかかわらずキュー数が高くなるケースでは、特殊な命令を出すシステムコールが、ひんぱんに利用されている可能性が高い。こうしたマシンは仮想環境でパフォーマンスが思ったように出ないことがあるので、注意が必要だ。目安は平均値としてプロセッサ当たり、平均3〜6程度であれば、仮想化にはほとんど影響はないと言える。分析をすると、常に高い値（10以上）の待ち行列を抱えているシステムが存在することがあるが、移行時には発生させているプロセスを特定するなどの対応が必要だ。

　そして最後にSystem Context Switchのパラメータも確認しておきたい。上記のProcessor Queue Lengthでも言えることなのだが、CPUの特権モードをひんぱんに利用する命令を発行するアプリケーションや、大量のスレッドを生成するアプリケーションでは、コンテキストスイッチの発生度合が高くなることが多い。最近では、CPUにもハードウェアレベルでの仮想化対応機能（Intel VT-ｘ、 AMD-Vなど）が搭載されており、特に1年半以内に出荷されたプロセッサの性能向上は著しいものがある。このため、仮想化に不向きといわれるようなアプリケーションにおける性能低下は抑えられている（ただし、稼働状態は確認したほうが良い）。

ワンポイント

リソース管理製品などでは、コア当たりで1秒間の発生回数の上限の目安が5000〜15000回と、目安にかなりのばらつきがあるが、セキュリティ製品などの設定により、非常に高い値になっていることもあるため、確認しておくべきである。

メモリに関する分析のポイント

　メモリについては、クラウド（仮想）環境においてはその構成が特に重要な要素となる。仮想化ソフトウェア製品でもヴイエムウェアの製品は、メモリのオーバーコミット機能を利用することで、物理メモリに搭載している以上の仮想マシンを動かすことができる便利な機能の１つであるが、リソースが極端に不足すると、パフォーマンスを大きく低下させることにもなりかねない。

　また、物理環境の分析において、まれに見受けられるのが、物理環境にてメモリが不足しているマシンの存在である。これは、セキュリティソフトやバックアップソフトの高機能化に加え、アプリケーションの高機能化により、導入当時よりも利用要件が高くなったにもかかわらず、ハードウェアの見直しが行われていない、といった原因があるようだ。

　メモリ稼働の分析では、おもに4つの項目を確認する。その1つ目が、Memory Committed Bytesの値と搭載物理メモリの値である。Committed Bytesはオペレーティングシステム上で稼働しているアプリケーションも含めた、全体のメモリ使用量である。この値が物理搭載メモリより多い場合は、メモリの内容がディスクに書き出されたり、必要により読みだされたりする、いわゆるページング処理が発生している可能性がある。

　上記を裏付ける値として、Memory Pages Output/secを確認する。Pages Outputが発生している場合は、メモリが不足し、ディスクへのページングが発生していることになる。共有リソース上で動作させることを考えた場合、ディスクへのI/Oは少ない方が良いし、パフォーマンスの低下を抑えることができる。Pages Output/secが大量に発生しているシステムはメモリが不足しており、そのまま移行するには問題がある。

　また、Memory Pages/secも確認しておく必要がある。ページング処理には、ディスクへの書き込み、読み取りをともなうページング、ハードフォルトとメモリ内部で処理可能なソフトフォルトの2種類がある。物理環境において、ソフトフォルトの発生は大きな問題にはならないのだが、仮想環境ではソフトフォルト、ハードフォルトのどちらもコンテキストスイッチングを引き起こすため、パフォーマンスの問題を引き起こすことがある。もちろん、ページング発生処理は少ないほうがよい。

ストレージに関する分析のポイント

　ストレージについては、物理サーバで運用しているユーザーのほとんどは、データベースやメッセージングシステムでも稼働させない限り、サーバ購入時、ディスク容量以外は、ほとんど考慮していないユーザーも多いだろう。そもそも、１Uのサーバやブレードサーバでは、搭載できるディスク本数は限られている。

　ストレージのテクノロジもサーバやネットワーク同様に進化を続けており、RAID6などの耐障害性が高いRAID構成も一般的になりつつある。 また、フラッシュドライブや自動階層化などの新しいテクノロジはクラウド環境にもすぐに適用できる。

　さて、クラウド環境（仮想化環境）では、今までの物理サーバは仮想化ソフトウェア（ここではVMware vSphere ESX）が利用するデータ、つまりファイルに変換される。ライブマイグレーション（vMotion）やHigh Availability（HA）などの技術は、この「ファイル」に対して、複数の仮想化ソフトウェアが導入されたサーバからアクセスすることで実現している。このため、ストレージは仮想化ソフトウェアの共有リソースとして扱われるようになる。そして多くの場合、管理の簡素化を目的とし、単一のディスク領域上に複数のファイルが仮想マシン（または仮想ディスク）として格納されることになる。

　クラウド基盤の中心となるストレージは、非常に重要な構成要素の１つとなる。耐障害性はもちろん、現在の環境におけるI/Oのパターンなどを評価し、適切なストレージ環境を利用できるようにしておくことが求められる。

　最近は、仮想デスクトップやミッション・クリティカルなシステムの移行を検討しているユーザーが多くなってきているが、クラウド環境におけるI/O分析は既存システムを移行する、あるいはししないにかかわらず、必ず必要になると筆者は断言する。クラウド環境を構成する要素はどの構成要素も一定の性能基準は満たせなければならない。車に例えれば、エンジン（サーバ）の性能が優秀でもタイヤ（ストレージ）の性能が発揮できなければ、結局のところ本来の性能は発揮できない。

　ストレージの分析では、確認する項目は実はあまり多いわけではない。というのも、クラウド環境におけるストレージの利用のされ方は、物理環境でのディスク構成とはあまりに異なるため、稼働率やI/O待ち行列を測定する必要性は少ない。むしろ管理方法など、クラウド環境での利用を見越した議論をすべきである。

　では、クラウド環境への移行、利用に当たり収集すべき項目は何になるかと言えば、それは、現状の使用容量とI/Oの回数（Disk Transfer/Sec）である。I/Oの回数は、書き込みと読み取りを個別に収集するのが望ましい。容量は移行時の時間に関係し、書き込み（Write）、読み込み（Read）I/Oは、RAIDの構成に関係する。

　RAID6の利用は、耐障害性に優れているものの、書き込みにはパリティ生成のペナルティが生じるため、書き込みがひんぱんに発生するシステムへの適用は考えなければならない（一方で読み取り性能はRAID5とほとんど変わらない）。RAID5、RAID6ともにI/Oの読み取りと書き込みでのディスクに対する負担を比較すると、数倍のペナルティが発生している。一方で、パリティ処理の発生しないRAID0+1などでは、読みとり、書き込みともに高い性能を発揮できる。

　ストレージの構成は、規模の大きなクラウド環境では、かなり困難になる。さまざまな用途のシステムが利用される中で、ディスクの構成や、仮想マシンの配置にも気を配らなければならないからだ。個別のシステム利用に当たっては問題にならなかったこのような挙動も、「ファイル」となった仮想マシンが集められることで考えもしなかったリソース消費が必要となる場合があるので、注意が必要だ。

まとめ

　サーバ、ストレージ、ネットワークなどの各要素について分析してみると、システムによってさまざまな挙動であることが分かる。中には、思ってもみなかったシステムが大量にリソースを消費していたり（現状の構成不備などあるだろう）、高額な予算を投資して構築したシステムがあまり利用されていなかったりと、さまざまな結果が出てくる。

　筆者自身、多くのユーザーから話を聞く機会があったが、パフォーマンスについての漠然とした不安に対して、サーバの台数を増やして対応するのは、適切なアプローチとは言い難い。リスクを低減できる反面、サーバの台数を増やすことで管理のポイントが増大し、仮想化ソフトウェアのライセンスコスト、OS、ミドルウェアのライセンスコストが上昇するなど、リスク低減の代償があまりにも大きいからだ。重要なのはリスクと構成のバランスよく検討することある。

　実測に基づいた結果から、対象のシステムについてリスクを分類してゆくと、簡単に移行に着手できるシステム、そうでないシステムを評価することができる。対象を分析することで、環境についていろいろなことが分かる。

　また、測定専用のツールを利用している場合は、ツールが収集したデータを基に、クラウド環境で利用することを想定しているサーバのスペックをインプットすることで、集約台数を出すこともできる。ここでは、控えめに見積もったり（重要度の高いシステムを対象）または重要度の低いシステムに対して強気に集約をかけたりなど、さまざまな形で分析できる。

　また、今回は性能の分析についての話が中心となったが、ソフトウェアの導入状況やセキュリティの面でも、このようなクラウド環境への移行を機に見直しを行うのはどうだろうか。ヴイエムウェア製品ではUpdate Managerと呼ばれるパッチ適用を自動化するツールも利用できる。

　次回は、実測のデータと業務の重要度を総合的に考慮することで、システムを分類し、最適なクラウド環境を検討する方法について説明したい。

---

筆者プロフィール：小坂 剛生

EMCジャパン テクノロジー・ソリューションズ本部 コンサルティング部 コンサルタント。2004年3月、EMCジャパンに入社。主にプライベートクラウド化のためのサーバ仮想化、デスクトップ仮想化の計画策定に従事する。