| エンタープライズ：コラム | 2002/08/26 19:55:00 更新 |
Gartner Column：第60回 メインフレームのすごさについて技術的に解説しよう［1］
UNIXもWindowsもOSのハイエンド機能においては実はメインフレームを追い続けている。メインフレームを勉強することで、ハイエンドのシステムに求められる要件も明らかになり、UNIX/Windows OSが将来的に目指す方向も見えてくるだろう。
毎年更改されるガートナーのサーバ評価レポートにおいて、テクノロジー分野の全項目で常に最高点を得ているのはIBM eServer zSeries、つまり、メインフレームである。「何かの間違いでは？」と言われることもあるが、これは、ガートナーのサーバ系アナリスト（メインフレーム系、UNIX系、Windows系のすべて）が調査と協議を重ねて得られた結果なのだ。
私は、常日頃から、UNIX/Windows系専門のエンジニアの方にメインフレームについて勉強してみてはと勧めてきた。UNIXもWindowsもOSのハイエンド機能においてはメインフレームを追い続けているからだ。メインフレームを勉強することで、ハイエンドのシステムに求められる要件も明らかになり、UNIX/Windows OSが将来的に目指す方向も見えてくるだろう。
とは言うものの、実際、メインフレーム環境の優位性についてあまり仕様の詳細に立ち入らず解説している手ごろな書籍はほとんどないようだ（日本IBMの方、出版してみてはいかがですか？）。ということで、本コラムの以後数回にわたりIBM系メインフレームの重要機能の概要について解説していくこととしたい。
「メインフレームはハイエンドの基幹系システムに最適である」というのは、IBMの営業ならだれもが言うセールストークだろう。しかし、本コラムではなぜメインフレームが最適なのかを具体的なテクノロジーの視点から解説していきたいと思う。メインフレーム系エンジニアの方には当たり前の内容かもしれないが、UNIX/Windows系エンジニアの方にはメインフレームについて知るための良い取っ掛かりになるのではと期待する。
第1回目では、メインフレームOSが伝統的に得意とする機能のひとつであるワークロード管理について解説しよう。ワークロード管理とは、オンラインやバッチなどタイプの異なるプログラムをハードウェア資源のバランスを取りながら同時並行的に稼動するための機能である。
一昔前のUNIXサーバやPCサーバにおいて典型的に見られた現象だが、オンライン系のプログラムが単独で稼動している場合に良好なパフォーマンスを発揮していても、裏でバッチ系プログラムを走らせたとたんに、オンライン系プログラムのレスポンスタイムが極端に悪化することがある。このような状況はプロセッサやI/O帯域などのハードウェア資源の不足により生じる場合もあるが、多くはOSが複数アプリケーション間の資源のバランス調整を適切にできていないため、つまり、ワークロード管理機能が欠如している場合に起こる。
これは、単純なCPUの優先順位の設定という話ではない。仮に上の例で、オンライン系プログラムの優先順位を単純に上げただけでは、バッチ系プログラムがいつまで経っても完了しない事態が起こり得る（いわゆるスターベーションと呼ばれる現象である）。（10年ほど前の話だが、某UNIXサーバ上で優先順位を下げてコンパイルジョブを走らせ、そのまま忘れていたところ、1カ月経っても終わっていなかったという話を聞いたことがある。）
ここで必要となるのは、各プログラムのパフォーマンス目標（レスポンスタイムやバッチの完了時間）を設定し、そのパフォーマンス目標を可能な限り満たせるように、優先順位を動的に調節する機能である。つまり、何らかのフィードバックループの存在が重要となるのである。
メインフレーム系のOSはこのような資源配分の最適化を目標として数十年にわたり進化してきた。過去においては、ソフトの機能がハードと比較して重厚長大すぎると非難されたこともあったが、ハードの処理能力が飛躍的に進化した今では、強力なワークロード管理ゆえにハードの能力を真に生かせるようになったと言ってよいだろう。
現在では、IBMのメインフレームの世界のワークロード管理はワークロード・マネージャ（WLM）と呼ばれるサブシステムにより提供されている。また、最近になり、UNIXベンダーもワークロード管理機能を強化している。SolarisにおけるSRM（Sun Resource Manager）、HP-UXにおけるPRM（Process Resource Manager）、AIXにおけるWLMなどのワークロード管理機能がある。Windowsの世界では、Windows 2000 Datacenter ServerがARMテックの提供による基本的なワークロード管理機能を有し、また、ユニシスなどのシステム・ベンダーが自社ハード向けに機能を追加している段階である。Windows OSに本格的なワークロード管理が追加されるのは、.Net Serverの次のバージョン（いわゆる”Longhorn”）の時点になるだろう。
UNIX OSのワークロード管理機能は急速に進歩している。また、Windowsもハイエンドへの展開が進むにつれ急速に追随するだろう。しかし、依然としてワークロード管理の領域では、メインフレーム＞UNIX＞Windowsの関係が存在する。この格差は、少なくとも2006年までは存在するとガートナーは見ている。
まず第一に、メインフレームの世界では、OS（Z/OS）、TPモニター（CICSないしIMS）、DBMS（DB2）の境界をまたがったエンド･ツー･エンドのワークロード管理を行うことができる。これは、システムのほぼすべての構成要素が一つのベンダーから提供されるメインフレーム環境の強みだ（もちろん、これはオープン性や価格という点では不利に働くが）。
第二に、メインフレームでは、CPUだけではなくメモリーやI/Oの優先順位も管理することができる（UNIXの世界ではCPUと実メモリーだけというように部分的なサポートしか行われていない）。さらに、パーティション（1台のサーバを分割して複数のOSを同時並行的に稼動するための機能、これもまたメインフレームが優秀な点である）をまたがった資源の割り振りが可能である。そして、最も重要な点として、z/OSではゴール・モードがサポートされた。これは、ビジネス上の目標の視点からパフォーマンス目標を設定できる、いわゆる、ポリシーベース管理である。UNIXの世界でポリシーベースのワークロード管理は、HP-UXにおいてCPUを対象として実現されているのみである。
PCサーバは安いのだから、プログラムのタイプごとに専用のサーバを備えれば良いではないかとの意見もあるだろう。しかし、サーバの台数をむやみに増やすことは、システムの複雑性を増し、管理負荷を増し、TCOを増大させてしまう。データセンターが大規模になればなるほど、できるだけ処理は少数のサーバに集約したいという要件が高まっているのである（それが、そもそも、UNIXベンダーやマイクロソフトがワークロード管理に力を入れている理由である。）
次回は、メインフレームが提供する世界最強のクラスタシステムである並列シスプレッックスについて解説しよう。
[栗原 潔，ガートナージャパン]
