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

メインフレームLinuxが登場してから8年以上になります。いったいどんな目的のために、どのような形態で利用されているのでしょうか？ サーバ統合を中心とした適用の実態を紹介します（編集局）

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

　前回は、「メインフレームLinuxの実装（後編）」と題して、メインフレームという独特のアーキテクチャにLinuxをどのように実装したのか、特にハードウェア特有の機能に焦点を当てて解説しました。今回は、実際にメインフレームLinuxがどのようなところで使われているのか、システム形態や実際の使われ方について解説します。

何に使われている？ メインフレームLinux

　メインフレームLinuxが登場して8年以上が経過しましたが、いまではさまざまな領域に適用され、稼働しています。例えば、社会インフラを支えているさまざまな企業、具体的には銀行や電力会社、コンビニなどで使用されるようになり、広く普及しました。

　世界中で1500件以上稼働しているメインフレームLinuxを対象に統計を取ったところ、動いているアプリケーションは「Webサーバ」「Webアプリケーション」「データベース」が多いことが分かりました（図1）。メインフレームLinux顧客の7割以上でWebアプリケーションが、6割でDBサーバが動いているという結果です。

図1　メインフレームLinuxで稼働するワークロード

　またシステム形態としては、やはりほとんどが「サーバ統合」であり、1台のメインフレーム上で複数のLinuxシステム・イメージが稼働しています。統合のパターンは顧客ごとにさまざまですが、システム統合形態としては3つに分類されることが分かりました。

• 分散サーバの統合
• 基幹システムと分散サーバの統合
• ハイエンドUNIXサーバの統合

　統合元であるサーバの稼働状況や統合対象の台数によりシステム規模は異なりますが、数台から数百台という規模のサーバを1台のメインフレームに統合することで、TCO（総所有コスト）削減のメリットを出そう、というのが、これら3つの統合パターンにおいて最大の目的になっています。以下、それぞれの統合形態について解説しましょう。

■分散サーバの統合

　いわゆるエッジ系サーバと呼ばれるWebサーバやメールサーバの場合、機能ごとにサーバを立てていくと、それほどユーザー数が多くない場合でもどんどんサーバ台数が増えてしまいます。

　例えばメールシステムを構築しようとすれば、SMTP、POP、IMAP、Webメールなどの機能サーバに加え、ユーザー管理のためのLDAPサーバやファイアウォールなども必要となり、「1機能1サーバ」の原則で構成すると、かなりの台数のサーバが必要になります。これは、グループウェアやファイルサーバなどでも同様でしょう。

　このように分散したサーバを仮想化し、メインフレーム上に統合するというのが1つ目の統合パターンです（図2）。エッジ系サーバは一般的にCPU使用率が低いため、統合効率が高くなる傾向があります。ソフトウェアとしてはApacheやSamba、Postfix、openLDAPなど、Linuxディストリビューションに標準的に含まれているものが多いため、移行のしやすさに加え、ソフトウェアライセンスで追加コストが掛からないというメリットがあります。

図2　分散サーバ統合のイメージ

　また、ここ2〜3年で増えているのが、基幹業務サーバの統合です。JavaアプリケーションサーバとDBサーバの組み合わせで構築される基幹業務システムが普及していますが、業務システムごとに個別調達される傾向があり、これもサーバ台数の増大要因になっていました。このような分散して台数が増える傾向にあるサーバを、メインフレームに統合するケースが増えています。

■基幹システムと分散サーバの統合

　z/OSなどで従来から稼働中の基幹系システムをSOA対応やWeb化する場合、z/OSのバージョンが古いと新機能に対応できません。そこで、LinuxやUNIXなどを介在してレガシーアプリケーションをラップすることで、SOA化などに対応します。

　勘定系や基幹系システムで蓄えたデータを、情報分析などを目的とした情報系システムに展開するデータウェアハウスやデータマートでも、ETLプロセス（Extract/Transform/Load）によって基幹システムからデータ抽出したものを、UNIXなどの分散システムで処理する形態を取ります。

　以前はこれは、メインフレームの横にUNIXサーバやPCサーバを設置して実現していました。ですがメインフレームLinuxの登場により、メインフレームの同一筐体（きょうたい）内でz/OSとLinuxを共存させて、筐体内を内部LAN（クロスメモリ転送）で接続し、高速アクセスと運用管理の一元化を実現できるようになりました（図3）。既存システム側への変更は最小限に抑えながら、高速な情報連携を実現してSOAのような新しいパラダイムへ対応できるため、情報鮮度を保ちながらアプリケーションをリニューアルできるハイブリッドなソリューションだといえます。

図3　基幹システムと分散サーバの統合

　第1回「メインフレームでLinuxが動くまで」で解説しましたが、IBM社内でLinuxをメインフレームに移植する検討を始めたキッカケが、基幹系のレガシーシステムをWeb化するためにLinuxを活用しようとしたことでした。つまり、IBMとしては当時、この2つ目のパターンの普及を中心に考えていたのです。

■ハイエンドUNIXサーバの統合

　メインフレームLinuxは、ソフトウェア（＝Linux OS）の特性がUNIXライクであり、ハードウェアはスケールアップ型であるため、高性能なUNIXサーバと対象マーケットが重なっており、価格帯も同じレンジにあります。特にデータベースサーバについては、メインフレームのI/O性能の高さや高信頼性という特徴もあって競争力があり、メインフレームLinuxがDBサーバ専用として採用されるケースも少なくありません。

　大企業が大規模な全社DBや顧客情報DBを作ろうとすると、「高信頼で無停止かつ高性能で大容量」という厳しい非機能要件を満たすことが求められます。メインフレームLinuxは、高性能と高可用性を実現しているハードウェア上で、UNIXで普及しているミドルウェア製品を稼働できるため、ハイエンドのUNIXサーバと競合するケースが多くなっています（図4）。

図4　ハイエンドUNIXサーバの統合

　仮想化技術の普及によって、メインフレームLinuxに限らずほかのプラットフォームでもサーバ統合が一般的になりました。ただ、メインフレームの場合は1台で数十から数百サーバを統合していますので、統合効率はほかと比べてかなり高いといえるでしょう。

第4回へ

1/3

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

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

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