［プライベートクラウド編］CPUとメモリーだけでサイジングしてはいけない

　企業システムにおけるクラウド基盤の構築に当たり、まずITアーキテクトが検討することは、リソースプールの実現方式だろう。システムリソースのプール化とは、複数のサーバー、ストレージといった装置を論理的にまとめ、効率的に利用できる環境を作ることである。

　ユーザーは必要なタイミングで、必要な分だけ、それらのリソースを切り出して使う。この仕組みによって、迅速なシステム配備と、利用率の向上が期待できる。

　リソースプールの実現方式として、サーバーの内蔵HDD（ハードディスクドライブ）ではなく外部ディスクアレイにデータを格納し、ネットワーク接続するアーキテクチャーが一般的である。アプリケーションのデータはもちろん、システムデータも外部ディスクに配置し、ネットワーク経由でブートを行う方式もある。

　具体的には、FC SAN/iSCSIブートや、仮想化ソフトの共有ボリュームマネジャーが実装例だ。実行サーバーとデータの関係を固定しないことで、「どのサーバーでも起動できる、どのサーバーからもアクセスできる」柔軟な環境となる。

　リソースプールのサイジングを行う際、まず検討するのがサーバーのCPU能力とメモリー容量だろう。また、ディスク容量も計算するはずだ。リソースプールに求められる総量を算出し、それを満たすサーバーとストレージを選定していく。これらの項目はクラウドサービスを提供するときのメニューとして定義されることが多く、検討漏れはあまりない。

　だが、CPUとメモリーだけでリソースプールをサイジングしてはいけない。

容量だけ考慮すると起動時間が倍増してしまう

　クラウド基盤の設計時に見落としがちな要素は、ハードディスクの性能である。そしてクラウドで起こる悲劇の多くは、ディスク性能が原因である。

　サーバーに搭載できるCPUコア数とメモリー容量は、ここ数年で大幅に増加した。HDD容量も順調に伸びている。しかし、HDDの回転数は進化していない。HDDアクセス時間の大部分を占めるシーク時間は、短縮されていない（表1）。そのため、ディスク性能はCPUやメモリー以上に慎重に検討する必要があるのだ。

　ディスク性能を考慮していないと、どんな問題が起こるのか。例えば、CPUとメモリーの要件から、一つの物理サーバーに50サーバー分の処理を仮想化技術によって集約できたとしよう。また、50サーバー分のディスク容量が、一つのディスクアレイに収まったとする。

　そこで想像してみてほしい。仮にサーバーが故障し、待機サーバーに切り換わる際、50個の仮想サーバーがいっせいに起動する。そのためのデータ読み込みが一つのディスクアレイに集中するのだ。ユーザーは起動の待ち時間を許容できるだろうか。また、夜間バッチ処理も同様だ。繁忙期、朝までに処理を完了させることができるだろうか。

　仮に、システムの起動時に要求されるI/O能力を、1秒当たり30回とする。1万5000回転/分のHDDにおける秒当たりのI/O能力はおよそ150回であるため、1個のHDDで起動をまかなえる目安は5システムとなる。50システムを収容するディスクアレイには、HDDが10個以上必要となる計算だ。

　一方、HDD容量の観点からサイジングしてみよう。システム領域に必要な容量を1システム当たり50Gバイトとすると、50システムでは2500Gバイト。600GバイトのHDDを使えば、必要数は5HDDである。つまり、性能の観点から算出した数の半分で済んでしまう。容量だけしか考慮しないサイジングでは、単純に考えて、起動時間は要求性能の倍を要することになるのだ。

性能拡張方式をあらかじめ決めておく

　負荷分散方式や仮想化ソフトの機能の充実により、サーバーはスケールアウトによる性能拡張が比較的容易だ。一方、ストレージは前もって方式を決めておかないと、手が打てなくなることがある。よくあるケースは、「ラック内にHDDを増設するスペースがない」「ディスクアレイを増やしてもプールに組み込めない」「接続スイッチに空きポートがない」などだ。

　クラウド基盤のアーキテクトにとって、ストレージ性能のサイジングはCPU、メモリー以上に重要である。現実的には、ピーク時の要求性能を算出することは難しい。よって、性能拡張方式はあらかじめ決めておくべきだ。スケールアウト型ディスクアレイやSSDの採用は、有効な選択肢だろう。