メインフレームはなぜなくならないか?
By 高尾 - Posted: 2009/03/02 Last updated: 2009/04/06
- 2 Comments
多くの若者がこの疑問をもつ。
完全な答えじゃないけれども、オープン系も見てきた私から、理由をいくつかあげておく。
また、大規模プロジェクトにおいてプログラムの品質をそろえようとすると、相当に技術レベルとしては低めになる。大規模開発の場合は、オブジェクト指向にすぐれた人材をかき集めてテストするより、そこそこの人間を集めたほうが確実という面がある。
intelが長年i/o専用プロセッサーの研究を続けていて、いまだに出せないのは、オープン系での適用は、それなりに困難さがあるのだと思われる。
また、初期のMVSからESAに変わった時、チャネルの設計は大きく変更され、OSのI/O関係のルーチンも書き直された。このようにハードとソフトを一体で作ることで、堅牢なシステムを作るという目的に焦点をあてることができる。
一方、メインフレームは基本が「純正」でできている。ハードウェアもOSもミドルウェアもすべて同じ会社が提供する垂直統合型である。そのため責任はきわめて明確である。問題を切り分けるところから、メインフレームベンダーに渡したって構わない。
サードパーティのハードウェアは、すべて純正のふりをしているから、動きも明確である。
ミッションクリティカルなシステムな場合、仕事の精度は常人じゃ驚くほどの精度で行われる。問題が起きて「わかりません」とか「相性の問題です」なんていうベスト・エフォートを根底とした発言はあり得ない。すべてのハードとコードに責任をもつ世界の重さというのは、オープン系の人間にはわからないと思う。
あらためて書いてみると、すべてではないけれども、メインフレームが頼りにされる場所があるのは当然か、という気がしている。
完全な答えじゃないけれども、オープン系も見てきた私から、理由をいくつかあげておく。
乗り換えコスト
2007年問題に代表されるように、初期のプログラムを設計、開発した人がほとんどいない。メインフレームシステムを移行しようとすると、その初期の設計からを完全に理解しないと、新しいアプリケーションを作るわけにはいかない。この莫大なコストをいまさら負担するだけの潤沢なキャッシュフローを持つ会社は少ないと思われる。技術の素直さ
メインフレームの前身は、カード処理システムだったことをご存知の方もいるだろう。膨大なデータをプログラムで処理して出力する。「コンピュータ」出現前夜はすべてが手作業と算盤だった。それを素直に機械化したのが、現在のメインフレームである。基本の考えにはオブジェクト指向もなければ、RDBもない。なにより莫大にコードを費やすGUIはなかった。それゆえシンプルで圧倒的な速度を持つ。いまだにテープ搬送や大量印刷は性能、コスト面でオープン系は勝てない。また、大規模プロジェクトにおいてプログラムの品質をそろえようとすると、相当に技術レベルとしては低めになる。大規模開発の場合は、オブジェクト指向にすぐれた人材をかき集めてテストするより、そこそこの人間を集めたほうが確実という面がある。
台数
オープン系サーバーがここ数年、大きく方針を変えたのが台数である。ブレード、VM、すべては筐体をひたすら減らしている。エネルギー問題もあるが、台数を減らすと確実に運用コストは減る。もともとメインフレームは一台でさまざまなプログラムを流すか、LPAR,VMなどでシステムをいくつももつ、といういずれのパターンにも対応できる。目先の導入コストが安くても、運用を考えメインフレームに戻したお客も少なくはない、と聞く。運用の細やかさ
シンプルな動きであっても集積していくと、運用は煩雑になる。そのため、メインフレームは運用管理ソフトのレベルが非常に高い。都銀で多いところは一晩に1000本近いバッチジョブが走ることがあるが、それらをエラーをふくめて、きちんとコントロールできる。なんでもオンラインで済ませるという考え方もあるが、いろんな会社と仕事をしていく上でチェックポイントを儲けてデータを受け渡しし、バッチで処理していく、というほうがビジネス上は合理的な場合もよくあるのだ。ハードとソフトの密接なかかわり
オープン系の人は実感しないだろうが、メインフレームのI/O処理にはCPUがほとんど介在しないため、ターンアラウンドタイムが早い。しかも接続されているデバイスの数は数百なんてのは当たり前にある。intelが長年i/o専用プロセッサーの研究を続けていて、いまだに出せないのは、オープン系での適用は、それなりに困難さがあるのだと思われる。
また、初期のMVSからESAに変わった時、チャネルの設計は大きく変更され、OSのI/O関係のルーチンも書き直された。このようにハードとソフトを一体で作ることで、堅牢なシステムを作るという目的に焦点をあてることができる。
問題解決の確実さ
ブラックボックス、ホワイトボックスにも書いた問題である。オープン系は、専門家の集まり、水平分業の典型である。プロセッサはintel,メモリーはkingstone,HDDはHDS,ネットワークカードはどことも知れない。OSはオープンソース、言語環境はJavaでIBM,ミドルウェアはWebSphere, データベースはOracle。開発にはEclipseを使いました、なんてのは珍しくもなんともない。これらはお互いが接続点で規約を守る、というルールに基づいてできている。しかし、必ずしもそのルールどおりにならないこともある。JVMの微妙な動きはIBMのバージョンによってもSun Microによっても違うなんてこともある。一方、メインフレームは基本が「純正」でできている。ハードウェアもOSもミドルウェアもすべて同じ会社が提供する垂直統合型である。そのため責任はきわめて明確である。問題を切り分けるところから、メインフレームベンダーに渡したって構わない。
サードパーティのハードウェアは、すべて純正のふりをしているから、動きも明確である。
ミッションクリティカルなシステムな場合、仕事の精度は常人じゃ驚くほどの精度で行われる。問題が起きて「わかりません」とか「相性の問題です」なんていうベスト・エフォートを根底とした発言はあり得ない。すべてのハードとコードに責任をもつ世界の重さというのは、オープン系の人間にはわからないと思う。
あらためて書いてみると、すべてではないけれども、メインフレームが頼りにされる場所があるのは当然か、という気がしている。
Posted in つぶやき・雑感 • • Top Of Page
2 Responses to “メインフレームはなぜなくならないか?”
Comment from hike
Time 2010年2月10日 at 16:03
単純な構成でメインフレームより可用性に勝るプラットフォームが出てこない限り、企業の”ミッションクリティカル”と呼ばれる業務は、まだまだメインフレームで稼働していきそうな気がします。ただ、本来メインフレームで動かさなくても良い規模及び内容のシステムは、どんどんOpenに移行されるので、全体のパイが減少するのは確実なんでしょうね。
Comment from 野良猫
Time 2009年4月13日 at 03:29
また、安定性もオープン系に比べて優れていると聞いたことがあります。