第5回　広がるメインフレームLinuxの適用領域

日本アイ・ビー・エム株式会社
システムズ＆テクノロジー・エバンジェリスト
北沢 強
2008/12/22

歴史は繰り返される

　では、なぜ「メインフレームLinuxでサーバ統合」なのでしょうか。実は、サーバ統合はメインフレーム本来のシステム形態である集中型への回帰であると考えると、その本質が見えてくるかもしれません。第2回「メインフレーム温故知新」のSystem/360登場の経緯でも解説しましたが、ここで再び歴史を振り返ってみます。

　メインフレームは、コンピュータの黎明（れいめい）期に「業務アプリケーションを増やすたびに専用マシンがどんどん増えてしまう」という課題を解決するために、1964年に汎用コンピュータとして誕生しました。System/360の登場はコンピュータ史上、おそらく最初のサーバ統合といえるかもしれません。1台でさまざまなアプリケーションを稼働できたため、システム資源も運用管理も集中化でき、使用効率の高いシステムでした。

　しかし、当時の製品品質や仮想化技術は発展途上でしたから、業務ごとにマシンを分けたり、高可用性のために複数のマシンを用意したり、開発用に別のマシンを使用したり、能力不足でマシンを追加したり……と、1980年代までは多くの顧客が何台ものメインフレームを所有していました。

　そこで、結局はメインフレームでも台数が増えてしまうという課題を解決するために、1988年、ハードウェア機能として論理区画（LPAR）が登場しました。LPARによって1台のマシン上で複数のOSが稼動できるようになり、再びサーバ統合が進みました。

　1990年代にはダウンサイジングが進行し、UNIXやPCサーバ上でも基幹業務アプリケーションが稼働するようになりました。テクノロジの進歩と激しい価格競争によって、安価にコンピューティングパワーを手に入れられるようになったため、サーバ台数は増加の一途をたどりました。

　そして現在、サーバの取得コストよりも運用管理に掛かる人件費が大きくなってしまい、またエネルギー問題や環境問題などもあって、再びサーバ統合化の方向に向かっています。

　振り返ってみると、System/360の登場以来、10年周期で集中と分散が繰り返されています。メインフレームは、その発現経緯を見ても統合化が出発点であり、常に統合による効率性を追求する設計思想を持っています。たくさんの基幹業務システムをLinuxサーバによって仮想化統合することは、歴史の流れの中では必然といえるかもしれませんね。

サーバ統合の効率を高める秘訣とは？

　メインフレームLinuxによるサーバ統合で、統合効率を高くできるのはなぜでしょうか。あるいはメインフレームによるサーバ統合を成功させる秘訣は何でしょう。

　この疑問に対する答えも、もともとメインフレームが対象とする基幹業務の特性にあると考えます。

　従来、メインフレームでは1つのシステム上で、さまざまなアプリケーションやデータを作り込んできました。受発注処理、在庫管理、顧客管理、人事情報、給与計算、経理など、いろいろな基幹業務アプリケーションを作り込み、オンライン処理もバッチ処理もすべて1台で処理します。一般にメインフレームには数百〜数千台というたくさんの端末が接続されていますが、これらも1台で処理できる構造になっています。

　オンライン処理を考えた場合、端末からトランザクションが発生するのは、数十秒に1回程度です。これは、端末を操作する人が、画面を読んで考えたりキー入力をする時間としてシンクタイムが必要であるためです。

　また、ユーザー数が限られる社内業務システムである限りは、ピーク時のトランザクション数はアクティブユーザー数を超えることはあり得ません。アクティブな端末台数を平均シンクタイムで割れば、秒当たりのトランザクション数が概算でき、そのときの分散傾向はポアソン分布に従います。

　1つの端末において、同時に複数のアプリケーションにアクセスしてトランザクションを発生させることはできません。キーボードが1つしかないので、例えば受発注処理のアプリに入力している最中は、同時に人事情報に更新を掛けるようなことは不可能です（注：SOAなどによるアプリ連携の場合は別です）。

　それぞれのアプリケーションにおけるトランザクションの重さがほぼ同じであると仮定すれば、アプリケーションの本数に関係なく、アクティブユーザー数（あるいは端末台数）からメインフレームの必要能力が概算できます。つまり、ユーザー数が有限であるなら、必要なサーバ能力はピーク時のユーザー数に応じて決まるのであって、統合したサーバ台数（あるいはアプリケーション本数）ではないということになります。

　いい換えると、基幹業務は社内システムとしてアクセスできるユーザー数が限られているため、極論すれば、会社の中に分散しているすべての基幹業務サーバを統合しても、社員数（ユーザー数）に相当する処理能力があれば、オンラインアプリはすべて処理できるということです。

　その昔、メインフレームの能力は端末台数から概算しました。それは、オンライン処理においてシステム能力が決まる最大要因が「ピーク時のトランザクション数」であって、同時に稼働するアプリケーションの本数は、それほど大きな要因ではなかったからです。

　この考え方は、サーバ統合にそのまま適用できます。限られたユーザー数であれば、業務サーバごとのピーク性は異なるため、統合すればするほど資源効率は高められます。そして、CPU数の削減によってソフトウェアライセンス料を下げたり、サーバ台数の削減によって消費電力や設置スペース削減の効果が出る、という結果につながります。

　これはメインフレームLinuxに限った話ではなく、どのプラットフォームに統合する場合でも同様に働く原理に基づくものです。

　しかしながら、統合すればするほど、統合先のサーバにはより高い信頼性や無停止運用を求められ、保守の場合であっても停止ができなくなります。システムを稼働したまま活性保守をしたり、CPUやメモリ追加などの構成変更が動的にできるのもメインフレームの特徴であり、厳しい非機能要件を満たすために44年の長い歴史の中で培われてきたさまざまなテクノロジが、Linuxによる統合環境においても生かされています。

2/3

Index あなたの知らないメインフレームLinuxの世界 　第5回　広がるメインフレームLinuxの適用領域

Page 1 何に使われている？ メインフレームLinux 　 Page 2 歴史は繰り返される サーバ統合の効率を高める秘訣とは？   Page 3 仮想リソースプールとしての管理へ IBM自身の統合効果

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）