「本当に必要なこと」は誰が決めるのか|企業クライアント戦略|ブログ|Computerworld

あらゆる機能には、利点とともに欠点がある。何の欠点もないように見える場合でも、「機能を実装するための手間」は確実に必要になる。今回は、利点と欠点のトレードオフについて考える。

●オーバーコミット

Windows Server 2008 R2のHyper-Vには、動的メモリ割り当て機能が付くそうだ(目で見る Windows Server 2008 R2 SP1 Beta の新機能)。

これにより、仮想マシンが起動したときは最小限の物理メモリを割り当て、必要に応じて利用するメモリを拡大する設定ができる。ただし、仮想マシンに割り当てる物理メモリの合計は、実際に搭載されている物理メモリを超えられないようだ。

実際に搭載された物理メモリを超えて仮想マシンに割り当てる機能をVMWareは「オーバーコミット」と呼ぶ。Hyper-Vはオーバーコミットには対応しない。実際にオーバーコミットを使うと性能がかなり落ちるため、実用的ではない。テストケースでは役に立つこともあるだろうが、物理メモリを追加する方がずっと簡単である。

VMWareが登場した当時、サーバーは32ビットシステムしか存在せず、物理メモリの最大量は4GBから64GBであった。性能低下を承知でオーバーコミットを使わざるを得ない状況もあっただろう。しかし、Hyper-Vは最初から64ビットシステムにのみ対応し、(サーバーのハードウェア仕様にもよるが32ビットシステムに比べれば)大量の物理メモリを搭載できる。わざわざオーバーコミットのような面倒な仕組みを採用する理由がない。仮にオーバーコミットを実装しても、1年先、2年先まで使われるとは思えない。そんな機能を実装するのは無駄である。

筆者はVMWareを批判しているわけではない。VMWareが登場した当時のハードウェア環境を考えると、オーバーコミットの実装は画期的なことであり、大きな価値があったはずだ。しかし、もし、今、新規に実装するのであれば無駄だろう。オーバーコミットが無駄なのではなく、実装時期に価値があるかないかの問題なのだ。

だから「Hyper-Vにはまだオーバーコミットの機能がない」という表現には違和感がある。近い将来に必要になるとは思えないからだ。もちろん、64ビットマシンの限界を超えてメモリが必要になるなら話は別だ。しかし、数年程度は限界が来ることはないだろう。

●VAXのページサイズについての誤謬

32ビットコンピュータのベストセラーVAXは、仮想記憶の単位(ページ)のサイズが512バイトだった(VAXは以前紹介した「超マシン」のライバルだ)。

VAXを始め、Windowsでも使われている「デマンドページング方式」の仮想記憶は、ページ単位でメモリを割り当てるためページサイズが大きいほど無駄が増える。インテルのCPUで動作するWindowsは、ページサイズが4Kバイト(4,096バイト)である。もし4,100バイトのメモリが必要であれば、1ページ分に収まらないため2ページ分、つまり8,192バイトが必要になる。実に4,000バイト以上の無駄である。

VAXが採用した512バイトというサイズは、1978年当時でもかなり小さいとされていた。しかし、当時はメモリが高価であり、物理メモリの無駄をなくすためには小さなページサイズが必須だったのだろう。何しろ典型的な構成のVAXは物理メモリ量が1Mバイト程度の時代である。

ただし、小さなページサイズを採用することで、ページの管理領域であるページテーブルのサイズが肥大化するという問題が発生した。この問題は、ページテーブル自体を仮想記憶に配置するという画期的(あるいは非常識な)な実装により解決した。また、頻繁にページ切り替えが発生するために、性能が落ちるという問題もあった。これは「ページクラスタ」という概念を導入し、隣接した数ページをまとめて扱うことで解決した。しかし、ページクラスタを扱うためにOSが複雑になってしまったことは確かである。

現在では、512バイトという小さなページサイズは間違いだったとされている。小さなページサイズは、物理メモリを節約するためだったが、その代償が大きすぎた。VAX設計時点でもメモリ価格が年々低下することは予測されていた。1970年代半ばには「半導体の集積度は2年で2倍になる」という「ムーアの法則」は、既に業界の常識となっていたからだ。

「将来解決することが確実な問題」を重視したことはVAXの最大の失敗とされている。ある機能の実装には利点と欠点があるが、時間とともに解決する欠点を重要視することは得策ではない。

●要／不要を決めるのはIT部門ではない

あらゆるITシステムには利点と欠点がある。将来にわたって解決不可能な欠点や、今すぐ解決して欲しい欠点は受け入れることができないだろう。しかし、我慢できる欠点ならコストや納期を考えて許容することを考えるべきだ。そして、欠点が許容できるかどうかを判断するのは利用者である。

一般にIT部門の人は責任感が強く、必要以上に高い信頼性や機能を設定する。先週末、筆者の勤務先のビルが設備点検のために停電となった。毎年の法定点検である。多くの場合、点検は日曜日に行なわれる。以前は、IT部門の人が土曜日の夕方に出勤して社内にあるシステムを停止していた。自宅からリモートアクセスする人もいるので、少しでも停止時間を短くするためだ。しかし、あるときからシステム停止が金曜日の夜になった。当時の社長が「土曜日にシステムが使えないと本当に困る人は申し出るように」と言ったところ、誰もいなかったからだ。

ハードウェアの進歩により自然に解決することとしないこと、許容できることとできないこと、本当に必要なこととそうでないこと、こうしたことをよく考えたい。そして、最終的な意志決定はIT部門ではなく利用者だということを忘れないでほしい。