メインフレームを知れば、クラウドが見えてくる

　クラウド・コンピューティングは、何を目指しているのだろうか。その答えは、メインフレームにある。

　「クラウド・コンピューティングとは、オープン・システムのメインフレーム化」といってもいいだろう。

　クラウドが、以下のような技術要素の集大成であることを考えれば、小職の暴言も、多少はご納得いただけるのではないだろうか。

• コンピューティング資源の仮想化
• ストレージの仮想化
• 運用の自動化
• プロビジョニング
• 高可用性
• 負荷の最適化（負荷管理機能）
• マルチ・テナント
• ・・・

　１９６４年にＩＢＭが、システム３６０という汎用コンピューターを世に出した。ここから、メインフレームの歴史が始まった。その後、１９７０年にシステム３７０が出現し、仮想化の進化が始まった。

　当時のコンピューターは、大変高価なものであり、一台の機械を大勢が共有することが前提となっていた。そのため、少ないシステム資源を公平かつ便利に使ってもらうために仮想化は、不可欠な機能となっていた。

　利用者の個別のニーズに対応して、必要なシステム資源を最適配分するための技術として用いられたのである。

　また、処理特性の異なるバッチ系とオンライン・リアルタイム系に対して、一定のサービス品質を維持しながら負荷の最適化を図るロード・バランシング機能も進化した。

　また、リソースの必要量に応じたプロビジョニング、基幹業務を支えるためのノンストップ・システムの追求、そして、自動運用機能の追及による運用負担の軽減を目指してきたのが、メインフレームである。

　しかし、メインフレームは、その高額さ故に敬遠され、ＵＮＩＸやＰＣをベースのサーバーへと、その地位を譲り渡すことになった。

　しかし、ここにきて、今大きな変化が訪れている。

　ＰＣサーバーの取得コストは、毎年劇的に下がっている。そのため、アプリケーションあるいは、機能単位にサーバーを導入した。その結果、多くの企業が、必要とする処理能力をはるかに超えるＰＣサーバーやその周辺機器を所有する事態となっている。

　また、基幹業務への適用も増えているため、可用性の確保も重要な課題だ。そのため、冗長化により、ますますシステム資源が、肥大化し、ＴＣＯの拡大に拍車をかけている。

　また、ＣＯ２削減が、ＣＳＲ（企業の社会的貢献）という意味合いから、ＣＳＤ（企業の社会的義務）となりつつある中、システム資源の２割程度しか使われていない実態を何とかしなければという機運も生まれつつある。

　その解決策が、仮想化であり、運用の自動化であり、マルチテナントであるといった、クラウドを実現する要素技術の活用であるといえるだろう。

　つまり、その行き着く先が、クラウド・システムということになる。

　しかし、以前のブログでも紹介したが、オープン・システムを前提としたクラウドは、いくつかの課題を抱えている。

• 単体で信頼性の低いＰＣサーバーを冗長化により可用性を高めた結果、システムが複雑化して、運用負担が増大すると共に、システム全体の信頼性の低下も招いている。
• 仮想化や運用の自動化を実現するために異なった企業やオープンソースのミドルウェアを導入。単体での完成度は上がっても、全体の組み合わせに対する信頼性や責任の所在は、逆にあいまいになってしまっている。

　その観点から見ると、メインフレームは、この上記、ふたつの課題を解決している。その４０年を超える歴史の中で、信頼性を追求し、ノンストップを当然とした設計思想を貫いてきた。また、仮想化や運用の自動化も一社が、一貫して開発し、保証してくれる。

　つまり、メインフレームは、それ自体、「クラウド・マシン」として進化してきたといえるだろう。

　ＩＢＭは、２０００年にz/Linuxのサポートを正式に表明し、EBCDIC以外のコードでも利用できるオープン・プラットフォームとなっている。意外と知らない人も多いが、Linuxコミュニティの相当数は、ＩＢＭのエンジニアであるといわれている。

　メインフレームの大きな魅力のひとつが、負荷の最適化を管理する機能だ。

　オンライン系のプログラムが単独で稼動している場合に良好なパフォーマンスを発揮していても、裏でバッチ系プログラムを走らせたとたんに、オンライン系プログラムのレスポンスタイムが極端に悪化する。これは、プロセッサやI/O帯域などのハードウェア資源の不足のためであったり、複数アプリケーション間の資源のバランスを適切に調整できないためである。

　これに対処しようと、オンライン系プログラムの優先順位を単純に上げても、バッチ系プログラムが、いつまで経っても完了しないという現象が生じることがある。これをスターベーションという。

　メインフレームでは、このような事態が発生しないように、各プログラムのパフォーマンス目標（レスポンスタイムやバッチの完了時間）を設定し、そのパフォーマンス目標を可能な限り満たせるように、優先順位を動的に調節するといった「ワークロード管理機能」が、ＯＳレベルで実装されている。

　そのため、一台のメインフレーム上に数百や数千といった仮想マシンを同時に動かしてもＱＯＳを保証することができる。これをＰＣサーバーで実現することは、不可能だ。

　確かにＰＣサーバーを単体でみるとＴＣＡ（取得コスト）は、安い。しかし、クラウドを構築するとなるとＴＣＯ（所有コスト）は、むしろ高くなる。ましてや信頼性や可用性についての不安は、払拭できない。

　私は、決して「メインフレーム」を無条件に推奨するものでない。しかし、「メインフレームは、レガシー（過去の遺物）」という先入観は、捨て去るべきであろう。メインフレームは、明らかに時代に対応して進化し続けている。クラウドの時代と叫ばれている現在、あらためて、メインフレームを冷静に見直してみては、どうだろうか。

　かつて、ベストセラーとなった徳大寺有恒氏の著「間違いだらけのクルマ選び」に、「車を買うならまずベンツを見ろ」と書いてあった。車のあるべき姿がそこにあるから、それを基準に車を選べば、間違えはないという話である。

　メインフレームが、コンピューター・システムのあるべき姿かどうかは別としても、今、クラウド・コンピューティングが目指している理想は、それに近いことは、間違えない。

　クラウドのビジネスを考えるとき、メインフレームの目指してきたものを見ると、その本質が見えてくる。また、お客様が、プライベート・クラウドを求めているとすれば、メインフレームによるクラウド（？）も選択肢として考えてもいいのではないか。そちらのほうが、可用性と信頼性は保証され、ＴＣＯは、大幅に削減できるだろう。

　クラウドとメインフレームは、形こそ違うが、その狙いや思想は、共通している。改めて、歴史的進化のスパイラルを見せ付けられているようだ。