たとえ冗談に聞こえようと、結論を出す。たとえ実現不能でも解決策を出す。
文章を書くときに私が心がけているのはこれである。というのは、反論が可能だからである。ともかくもオチを付けてしまえば、それをひっくり返すにはそれなりの論理が必要であるから、確実に理解は深まる。（実はポパー主義者だったらしい、私は。）今頃になって取り出すネタは「ダウンサイジングの問題点」。何を今更、もう飽きたというのが普通の感想と思うと、そうでもないらしい。だって「ダウンサイジングの問題点」でGoogleサーチしたら２サイトしか見つからなかった。
多分このへんの議論が盛んだったのはInternetが商用利用される以前なのだろう。で、InternetはUNIXというダウンサイジングの担い手たるOSで動くサーバーとネットワークで構築され、PCというダウンサイジングの担い手たるOSで動くクライアントで構築されている。商用化されてからのInternetはダウンサイジングされたアプリケーションの動作環境である。いちいち「ダウンサイジングの問題点」なんて気にしないわな。なんでいきなりこんなことを言うかというと、クライアントサーバーシステムの可用性向上をどうやって実現しよう、という深遠な命題を解決する義務を課せられたからである。正確に言うとクライアントサーバーシステムにおいては可用性向上を実現する努力をしなければならないと、改めて指摘する必要を感じたからである。で、改めて指摘しようとして、世間がこれを問題視しているか確認しようとしたところ「ダウンサイジングの問題点」の検索結果が３件２サイトということだったのだ。
さてさて、「コンピュータ帝国の興亡」という本でクリンジリー氏は「パソコンは途方もなく大きなチップなのだ」と言っている。正しいと思う。メインフレームコンピュータが小型化してパソコンになったのではない。少なくとも、メインフレームとパソコンは出来が違うと言っておかないと、アーキテクチャーのあまりの差がどうしても説明できない。メインフレームはアプリケーションを動かす為に作られ、アプリケーションを動かす為にOSというものが平行で開発された。しかしPCはOSがないのにハードだけあった。
PC-9800はMS-DOSがなくてもN-BASICで動いていた。もちろん、ユーザー管理もタスク管理もない。ファイル管理はあるかもしれない？ファイルをオープンし、クローズするということができただけだけど。（電源を入れると最初に出てくるメッセージはHow many files 1-15だったよね。）そういう点ではUNIXもパソコンの仲間である。箱があって、これを使うためにOSを作った。つまり、メインフレームはコンピュータの力を借りて解決したい問題があり、それを解決するために設計・構築されたものであるが、パソコンやUNIXはまず箱があって、それを使いたいがためにプログラムが作られたというものである。はっきり言って自分が趣味で使えればそれでよかったわけだ。ビジネスに使えるものを作ろうなんて夢にも思っていなかったはずだ。
そこから先はUNIXの歴史、という分野になるので私より詳しい人は、沢山いるようだ。「UNIXの歴史」をGoogleで検索したら59,100件あった。
ともかく、UNIXはプログラマが趣味で使うために、柔軟な設計となった。自分が使うことが最優先だったので、マルチタスクのバッチ処理ではなく、マルチユーザーの対話式の利用を念頭に置いて作られた。で、これは当方の推測なんだが、UNIXが柔軟な設計であったから、Ethernetをはじめとするネットワーク技術を実装する時の「実験台」となり、結果UNIXがネットワークの標準プラットフォームになった。（メインフレームでTCP/IPを実装するのは極めて大変だったらしい。IBM純正以外のネットワークカードを接続するとMVS（メインフレーム用のＯＳ）が止まったという信じがたい話を聞いたことがある。）
となると使いたいという趣味人が増えてくるわな。というわけで安価な部品で作られたコンピュータで動くように移植された。（ちなみにUNIXははじめから移植性を考えてC言語で作られたわけではない。少なくともオリジナルのUNIXとLinuxはアセンブラで書かれた。）ということで（かなり強引な論理展開だが）UNIXの特長として
を挙げることができる。ちなみにPCの場合は
- 柔軟な設計
- マルチユーザー対話式での使用
- ネットワークとの親和性
- 安価なハード
とでもまとめることができようか。で、これを使って「ダウンサイジング」と銘打ったシステム構築をすると、メインフレームに比べていろいろと問題点が出てくる。
- いい加減な設計
- シングルユーザー対話式での利用
- ネットワークへの接続機能追加
- 格安のハード
設計が柔軟なので、実装がプログラマ任せになる。アプリケーションが占有するメモリやセマフォのアドレスを、プログラマが決められるらしい。アドレス決め打ち、当然ディレクトリも決め打ち・・・コンフリクトを起こさせないためには、CPUを分離するしかない。というわけでサーバー台数は増える。でもまあいいや、ネットワークとの親和性がいいから。
が、ネットワークとの親和性がいいと今度は外部からの不正アクセスといった問題が出てくる。LANケーブルは縦横に走り、ハブには空きポートがある。水道管の継ぎ目と蛇口がたくさんあるようなもの、どこから水が漏れるか分からない。
ハードが安価なのも考え物だ。つまり壊れやすい。ちなみにRAIDのIはinexpensiveのIである。
しかし最大の問題は、対話式の利用というところにある。つまり、機械の前に人が必ずいるというのを前提として構築されてきたということだ。人がいれば機械が壊れたり、プログラムの動作がおかしくなったりしたときにはすぐに気がつくことができる。しかも原初においてはプログラムやOSそのものを作った人間が端末の前に座っていることが前提とされていたのだ。
かくして、どの機械で何のプログラムが動いているか、正常に動作しているかを確認する必要はなかったのだ。だって機械の前に分かっている人がいるんだから、いざというときは何とかなるよ。ジョブのスケジューリングなんてバッチ処理の発想が出てくるのはずいぶん先のことだ。つまり「管理」が生まれつき得意でないのだ。ウソだと思ったらSUNの社員に聞いてごらん。「あなたは管理されるのが好きですか」って。
まあ、仕方なく監視・管理のためのプログラムが書かれることになるが、それは必要に迫られてのことだ。OSやハードの製造元が作ってくれるとは限らない。というわけで副次的ながら「マルチベンダー」というややこしいことになる。
ここで問題となるのは障害が発生したときに、どの部位の（どのベンダーの製品の）障害であるかの切り分け責任を積極的にとるところはないということである。これに（とりわけMS製品の）「いい加減な設計」が加わると泥沼になる。原因不明のまま障害を起こし、その切り分けは自分でやらなきゃなんないとなると。
マルチベンダーでなくてもサーバーを分割していると大変なことになるぞ。あたしゃあネットワーク越しのファイル転送なんぞやりたくないぞ。文字コードの問題とか、時間の問題とか、ファイルサイズの問題とか。
で、サーバーが別のサーバーに何か問いかけて、返ってこなくてもそれが「先方のサーバーが止まっている（止まっているにも、OSが止まっているのとアプリケーション含むDBMSが止まっているの少なくとも２種類がある。）」のか「（たとえばサーバーのバックアップ処理やウィルス検索とぶつかって）応答時間が遅い」のか「ネットワークが過負荷で遅くなっている」のかわからないのだ。どうしてくれる！ということで「可用性向上」のためには、メインフレームとは別のアプローチが必要なのである。おしまい。
（結局、ダウンサイジングの問題点を洗い出す時に、このような演繹的手法はとらず、実に経験則的に、導入フェーズ各段階の問題として洗い出すこととした。）