第2回　メインフレーム温故知新

Linuxがメインフレームの上でどう動作するかをきちんと理解する前提として、今回は、メインフレームそのものの特徴を解説します（編集局）

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

　前回「メインフレームでLinuxが動くまで」では、メインフレームがいったいどういうもので、なぜそこでLinuxを動かすことになったのかという経緯と、それがもたらす価値について説明しました。

　今回は、その上でLinuxがどう動作するか……をきちんと理解するためにも、いったんLinuxから離れ、メインフレームそのものの特徴について解説していきます。ただし、限られた誌面でメインフレームのすべては語り尽くせませんので、Linuxが稼働するうえで関係する部分、主にハードウェア・アーキテクチャを中心に取り上げてみたいと思います。

メインフレームに歴史あり

　最初の商用メインフレームである「IBM System/360」が発表されたのは、1964年4月7日のことです。メインフレームとはいえ、最初から高信頼で高速なマシンだったわけではありません。長い歴史の中で改良に改良を重ね、必要とされる機能の追加を繰り返してきた結果が、現在のメインフレームなのです。

　そこで、メインフレームが必要とされてきた背景と、要請に応えるべく実装してきた機能について、歴史を振り返りながら解説します。

■基幹業務のためのコンピュータ

　メインフレームが使われている分野は、昔もいまも、ほとんどの場合が基幹業務です。基幹業務とは、受発注処理や販売管理、在庫管理など、その企業・団体の事業内容と直接的にかかわる業務のことをいいます。以前は紙と人手で処理していたこうした業務を、電算化（コンピュータ化）したものが基幹業務システムです。

　一般的に、それぞれの基幹業務は処理やデータがそれほど複雑ではなく、定型的なものが多いため、コンピュータ化しやすいといわれています。しかしながら、企業の中にはさまざまな業務があるうえ、それぞれ要件や特性が異なり、業務間で複雑に絡み合っています。そのすべての業務に汎用的に対応できるコンピュータとして、メインフレーム System/360が誕生しました。

　360という数字には、船のコンパスをイメージして「360度の全方向に対応できる」という意味が込められていたそうです。S/360登場以前は、科学技術計算用と事務計算用とでそれぞれ別々のコンピュータを用いていたものを、1台で実現したのです。1台のメインフレームがあれば、どんな業務もコンピュータ化できるわけですから、ユーザーはその上でどんどんさまざまなアプリケーションを開発していきました。

　また前述のとおり、メインフレームは会社の中心的な業務処理を担います。このため、正確かつ安定に処理を行い、高信頼なシステムである必要もあり、さらに厳しい可用性要件も満たす必要がありました。その企業の事業内容が大きく変わらない限りは、基幹業務アプリケーションを大幅に作り替える必要がありませんから、長期にわたって使用を続けることができるという特徴もあります。

　基幹業務の処理形態を見ますと、大きく「オンライン処理」と「バッチ処理」に大別されます（図1）。数百台あるいは数千台という端末のキーボードから入力されるデータを即時に処理し、端末の画面に表示するのがオンライン処理であり、夜間などにまとめて計算処理したりバックアップしたりするのがバッチ処理です。

図1　オンライン処理とバッチ処理

　典型的な例としては、日中のオンライン処理によってデータが更新され、夜間のバッチ処理によって集計する、というような流れが挙げられます。

　会社での交通費精算を思い浮かべてください。皆さんは、端末やWeb画面から自分が使用した経路や料金などの情報を入力しますが、これがオンライン処理です。社員みんなが入力した数字は、月極め処理によって集計されて銀行へ送られ、自分の口座に振り込まれますが、こちらがバッチ処理です。

　このようなアプリケーションは、多くの場合「COBOL言語」で開発されてきました。基幹業務アプリケーションの本数ですが、ある程度の規模の企業では数千本以上に上ることも珍しくありません。オンラインとバッチの比率は3:7くらいで、バッチの方が2倍以上もアプリケーション本数が多いという傾向があります。

基幹業務システムに求められる厳しい要件

　基幹業務システムは企業活動の屋台骨となるものなので、システムが停止したり、データが消えたりすることはもちろんのこと、処理が滞ったりするだけでも会社の損害につながったり、社会的にも影響を与えてしまうような事態にもなりかねません。そのため、非常に厳しい要件となります。

　特にRAS（信頼性、可用性、保守性）という3つの要素は最も厳しい要件です。現在でもメインフレームが使われ続けているシステムの多くは、メインフレーム以外では高いRAS要件を満たすことができないからだといわれています。40年以上かけて、世界中のユーザーから寄せられるRAS要件を満たすように改良してきたわけですから、それももっともな話です。

　性能も、非機能要件として重要な要素です。パフォーマンスの観点で見ると、オンライン処理よりもバッチ処理の方が性能要件は厳しくなる傾向にあります。

　オンライン処理の場合、人間がキーボードから入力する時間や表示を読む時間が必要となるため、キー入力時間（Thinking Time）は数十秒単位と比較的長くなります。総使用端末台数を平均入力時間で割れば、秒当たりの最大トランザクション数が簡単に概算できます。1つ1つのトランザクションが大きくない限りは、オンライン処理に必要なキャパシティは、端末台数とトランザクションの重さから概算できます。処理能力の限界に近づくと平均レスポンスタイムが長くなりますが、サービス停止に陥るわけではなく、レスポンスタイムの要件（例えば3秒以内）を満たしていれば実害はありません。

　一方、バッチ処理については、開始から終了までの許容時間が決まっている場合が多く、例えば夜間バッチだと「朝7時までに終わっていなければ、翌日のオンライン処理にぶつかってしまう」というような、致命的状況を招きかねない厳しさがあります。

　バッチ処理では、日中にオンライン処理で蓄積されたデータと過去に蓄積されたデータを処理するために、大量のI/O処理を行う必要があります。また、アプリケーションの本数自体が多いので、バッチ・ジョブの制御なども複雑になります。数百から数千本もあるバッチアプリケーションを限られた時間で処理するために、ジョブ・ネット（複数ジョブの実行順序関係）を工夫して実行するのですが、数十というジョブを並行実行することが一般的です。

　40年前にメインフレームに「仮想記憶」が実装され、複数のアドレス・スペースで並行処理ができるようになったのは、複数のバッチ・ジョブを並行実行したかったからです。

　また、多くのエンジニアが経験していることですが、バッチ処理においては「I/O」がボトルネックとなる傾向にあり、I/Oをいかに高速化するかがシステム設計における鍵となります。

　メインフレームはもともと、パンチカードやテープの入出力を中心としたバッチ処理マシンであり、バッチ処理用にチューニングされたマシンだともいえるでしょう。

　アーキテクチャで見た場合、ほかのプラットフォームと最も異なるのがI/O処理の部分です。バッチ処理の要件を満たすために工夫が施され、結果として高いI/O性能を持ち、たくさんのI/O装置が接続可能となっています。また、マルチパス制御、負荷制御、エラー検知・リカバリー処理などがすべてハードウェアの中で実装されているため、OSやアプリ側では余計なことに気を使わなくて済みます。

　おかげでメインフレームLinuxの場合も、ハードウェアで実装されているこのような機能の恩恵をそのまま享受できます。つまり、たくさんのLinux仮想マシンを並行稼働できますし、高信頼で高いI/O能力がそのまま利用できるのです。

1/3

Index あなたの知らないメインフレームLinuxの世界 　第2回　メインフレーム温故知新

Page 1 メインフレームに歴史あり 基幹業務システムに求められる厳しい要件 　 Page 2 メインフレームの仮想化技術 仮想化における課題、オーバーヘッド   Page 3 マイクロ・プログラム方式（マイクロコード）の功績 System/360登場の経緯

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