【新連載】ITアーキテクトのひとりごと
第30回 「キャパシティ計画を必要としないシステム設計」

 

このシステムの利用者はどのように推移するのか、データはどのくらい増えていくのか、トランザクショナルなデータはどのように推移するのか、そもそもビジネス計画はしっかりしているのか。いつものことながら、システムの基本設計段階で、こんな分からないことだらけで基本設計をするのは気が引ける。前提条件を付けるしかないのだが、その前提条件、本当に守れるのか？と考えると、心配事はつきない。性能問題なら、不測の事態が発生したらスケールアップかスケールアウトで制約から逃げられるように設計しておくしかない。

 

Webアプリケーションでは負荷分散を前提に設計しておけば何とかなることが多いが、そんな前提を置いたとたんに、負荷分散装置やらL2ネットワークスイッチやらで、えっ、こんなに高くなるの、と思う位のコストアップが発生する。最近はコスト低減の締め付けが厳しいので、お金で解決できれば良し、というわけにも行かない。それでもDBサーバだけは困ったことになる。うかつにスケールアップすると料金表を読み間違えたと思うくらいライセンス料金が跳ね上がる。オープンソースのDBソフトを使ってどうにかならないのかと考えていると、そこまでやるのはどうか？という周囲の雰囲気で、オープンソースは諦める。DBのスケールアウトもこなれた製品は限られているし、考えておくことも増えて気軽にできない。

 

過去を振り返ると、心配しすぎで作ったもののオーバキャパシティになってしまったシステムは数知れない。メモリだけは多すぎてもOSやらアプリケーションがあるだけ使い切ろうとするのでオーバキャパシティの実感がないが、本当はオーバキャパシティだったのかも知れない。

 

仮想化技術はこれらの問題の多くを解決出来る。

 

どうせ最初はユーザが少ないから、CPU、メモリ、ディスクは最小限に設定。ひょっとすると、そのままずーっと動いてしまう、なんてこともあるかも知れないが、そうなると嬉しいやら悲しいやら複雑な心境だ。大容量のディスクがあるかのように少ない物理ディスクで見せかけるThin Provisioning というストレージ技術もあるが、OSのLVM（ロジカルボリューム管理）機能で後からディスクを追加しても OK だ。

 

足りなくなったら増やせばいい、という安易で即効性のある対応が仮想化技術によって可能になり、部分的かも知れないが「キャパシティ計画を必要としないシステム設計」が実現した。これにより、コストの厳しいビジネスに臨機応変に対応できるという俊敏性とコストの最適化を手に入れたが、どんなビジネスをするのか、という大命題は変わっていない。ここが一番大事だ。

 

仮想化と共に、SaaSやASPが洗練されてくるので、重厚で頑丈なITシステムを時間をかけて作り上げる、という発想はぶち壊した方がいいが、ビジネスを描いて、それを成功させるためのビジネスプロセスを考えることは重要になる。

 

そこがしっかりと出来ていれば、後は、組み合わせブロックのように、リスクとコストを見ながら自由自在だ。しっかりとしたビジネスプロセスがあれば、プロセスの作り直しも容易になり、さらにコストを低減することもできるかもしれない。

 

ビジネスを描ききれる人にとって、仮想化技術、SaaS、ASPの隆盛は夢の時代の到来だ。