【新連載】ITアーキテクトのひとりごと
第31回 「IOPSのジレンマ」

 

お正月明け早々、去年の年末に注文したPCが到着、私がメジャーで使っている家PCのリプレースを実行した。私もSIerの端くれなので、準備万端、7年間使ったリプレースされる古いPCの中に積もり積もったフリーウェア、シェアウェア、買いまくったアプリケーションを棚卸しする。最近使わなくなったソフトは容赦なく移行対象から外すことに。移行すると面倒なだけでなくお金もかかるからだ。ついでに使わないと決めたソフトのCDやら印刷媒体も思い切りよく大量に捨てる捨てる。

 

一方で、これがないと困るという一押しのソフトはWindows7に移行できるかどうか調査を実行。グレーゾーンのものが意外に多い。うぅ～ん困ったぞ。ダメだった場合の代替方法も考えてリストを作っていると、PC以外にも出費がかさみそうだと戦々恐々となるが、試験してみると動くものが多いのでホットする。実はちょっとおかしな動きをするものも発見したが、まあ、しょうがない、そんなもんだと思って使えばいいんだから。これも慣れだね。これがお客様相手だとこんな悠長なことを言うと怒られそうだが、割り切れれば無駄なお金も必要ないのだから、ここが運命の分かれ目だ。

 

さて、この6,7年で私のPCは、1core（+HyperThread）から4core（+HyperThread）、メモリも2GBから10GB（本当は16GBが目標）、ネットワークも100Mbpsから1Gbpsへと飛躍的な性能向上を実現した。価格も約半額になってしまったので、価格性能比は10倍くらいは向上したことになる。ちなみに、今、これを書いているときのCPU使用率は2,3％、メモリ使用量は2.32GB、CPUとメモリを一番使っているアプリは iTune だ。

 

こんなにCPU、メモリの価格性能比は向上したが、ディスクの価格性能比はどうなっているのかというと、容量は増えたがIO性能が大幅に向上したような気がしない。この記事を書いているOneNoteのアプリくらいなら大したIO性能は必要ないが、ビジネスで使うサーバとなるとそうはいかない。この辺りのフィーリングはCPU、メモリとディスクはちょっと違う。

 

仮想サーバ環境でのサイジングは、必要なものは必要になるまで調達しないという調達戦略がとれるという特徴がある。特にCPUとメモリは足りなくなったら増やすのも簡単だし、必要なくなったら返すのも簡単だ。仮想サーバ環境では、こんなサービス提供ができるから需要変動が大きなITサービスの利用環境としてはもってこいだが、様子を見ながら調達を先延ばしできる先延ばし戦略は、IT稼働基盤の構築、整備の点でも画期的なことだ。悪く言うといい加減なサイジングでもスケールアップ、スケールアウトに対応できる、しっかりとしたアーキテクチャでアプリケーションが設計できていれば、あとからいくらでもサイジングをオンラインしながらでも変更できてしまう。

 

ディスク容量の増減も基本的には同じだが、データベースのようなトランザクション系のサービスでは1秒間に何回ディスクIOできるかというIOPS性能がアプリケーション性能に効いてくる。

 

このIOPS性能もディスク容量と同じように簡単に調達可能、サイジング変更可能なら話は簡単だが、今の仮想サーバ環境の運用管理の仕組みではしっかりとしたIOPS性能のSLAが確保できるかどうか不安だ。

 

サービスプロバイダからIaaSとして仮想環境を借りる場合は、この点の保証は無い。 不安なのでデータベース用には専用のディスクIOチャネル、専用のRAIDディスクを確保するしかない。ここが肝だ。こう考えるとハイブリッドな構成が必然となってくる。

 

ストレージネットワーク上の iSCSI、FibreChannel、NFS接続のRAID、そのRAIDの構成もSAS、SATA、SSDの混成構造、さらには仮想マシンが動いている物理マシン上のPCIeバス接続されたSSDと大量搭載された物理メモリを使ったキャッシュ。

 

これらを組み合わせて IOPS性能をSLA保証してくれるようなハイグレードなサービスって、IaaSではちょっと無理っぽいのでプライベート・クラウドで作るしかなさそうだが、運用管理は大変そうだ。運用管理ノウハウを蓄えて自動化する運用自動化ツールも必須になりそうだ。