メインフレームにはないオープン系の問題点はコレだ
—— 安定性という点では、メインフレームのほうに軍配が上がる?
島田 システムの形態によるのではないでしょうか。たとえば、金融機関、銀行さんもそうかと思いますが、長期間にわたって大量のデータを保存し続けなければいけない場合などはそうですね。
いまのオープン系の技術でも同じことはできると思いますが、バックアップとかバージョンアップ対応などコストのかかる部分が出てきて、オープン系のコストメリットが感じられなくなる。その点、上位互換がある程度担保されているメインフレームというのは、そのような懸念要素がない。信頼して使えるひとつの基盤として捉えればいいのではと思います。
—— たしかに基盤というイメージはあります。
島田 2000年頃は、オープン系技術が進み、オープン系の良さが大きくアピールされました。すごくコストが下がるんじゃないかとか、今思えば幻想みたいな期待もあったような気がします。一方でメリットがあったのも事実です。実際にいろいろなことが可能になりました。
ユーザビリティの観点でも利用者にはすごくいいし、勘定系以外の部分にどんどん活用されシステムの適用範囲が大幅に広がっていきましたよね。
—— さきほどのような新しい分野が広がってきた。
島田 オープン系技術が進化し、それを活用・享受することでシステムの適用範囲も格段に広がり、ITシステムが企業や社会に影響を及ぼすような重要な基盤のひとつになって来ました。一方で、品質面や継続性の問題というものが浮かび上がってきました。いろいろな経験から、ユーザーも学んで来ている。いまオープン系という名の下にたくさんの種類があり、システム化を実現するための手段は多様化してきています。その中でメインフレームもひとつの実現手段・基盤としてとらえればいいと思う。システムの形態・種類に応じて使い分けていけばいいんじゃないかとなるわけですね。
現実的に、メインフレームだけというわけにもいかないし、オープン系だけ押し進めることにこだわる必要もない。オープン系の基盤だって、ゆくゆくは使えなくなって入れ替えが必要になってくるわけです。そういう全体の流れの中で、メインフレームも捉えていくのがよいのではないでしょうか?
—— 具体的に、オープン系で出てきた信頼性、安全性、継続性というのはどういう点でしょうか? 継続性に関していえば、ファイル形式などが業界標準になっているオープン系のほうが有利に思われがちだと思うのですが。
島田 オープン系にはオープン系ならではの良さがあるのは事実です。しかし、大量のデータを長く持ち続けなければならない場合や、いろいろなログの取得・保存・分析などを考えると、オープン系の場合は相当な工夫と費用が必要になるのです。
さらに、これはその会社の成熟度や求められるレベルにもよりますが、アクセス管理やセキュリティなどの点ではメインフレームのほうが管理しやすいですし、確実な気がします。ま、ひとつの基盤の中で閉じていますからね。また、印象的ですけれど、メインフレームというのはすごく懐が深く感じます。いくつデータベースを構築していっても確実に管理してくれる。限界もあるでしょうけど。何と言っても、この1つのシステム基盤として守っていればいい。
—— 1つだけならその分だけサービスレベルを上げられる。
島田 管理対象となる基盤システムを、1個増やしてしまうとどうなるか? オープン系というものは増やしはじめると、オープン系基盤として1個ではなくて、オープン系A、オープン系B、オープン系Cというふうに増えていきますよね。
—— そもそも、自由に追加できるのがオープン系だから必然的にそうなる。
島田 メインフレームの世界なら1つの世界でコントロールできるものが、オープン系が、A、B、Cとあると、これをまたがったアクセスコントロールというのは、なかなか難しい。アクセス管理って企業システムにおいては非常に重要なテーマですよね。複数のオープン系環境の下で、それを一元的に統合的にやろうとすると結構大変なんです。それぞれのオープン系基盤で同じものを作って回していくんですよ。そういうものがどんどん増えていく。 また、ログの問題も大きいですね。
—— というのは?
島田 多くの業務プロセスがオンライン化されていますよね。うちの場合は、まず認証(オープン系)から入って、フロントエンド(オープン系)があって、さらにメインフレームにアクセスしていく、この一連の流れを追っかけるログが必要になる。ログというのは、アプリケーションログとか基盤ログとかいろいろあるわけですが、何か起きたときにプロセスやトランザクションの動きをこれで見る(再現する)わけです。そこに、複数のオープン系のシステムが入ってきていると、これがとてつもなく複雑になってくる。
—— メインフレームならシステムが最初からそういうことを意識して作られている部分があります。
島田 昔のログの考え方というのは、データが壊れてしまったときにどう対応するかというようなものでした。ところが、いまは利用者に対してどう説明責任を果たすかといったことが重要になってきている。「私は、こういう操作の仕方をしなかった」、「いや、実はこうだった」などという説明責任を我々システムサービス提供サイドが負うようになってきましたからね。
—— そういうことは実際に発生するわけですか?
島田 滅多には発生しませんが、お客様が直接オンラインを操作されるようなシステムでは常にそういうことを考えて作っていかないといけないでしょうね。何かあったときにプロセスを再現しなくちゃいけない。「私たちのログでは、何時何分にあなたはこういうことされました」、「その後こうされましたね」、「ここで“OK”を出していますね」と。
—— 要するに、メインフレームの安定性とか継続性というのは、ハードウェアやソフトウェアそれ自体の安定性の話ではない。1つの基盤で閉じていてアクセスコントロールなどが統一的になることで管理品質を上げられる。きちんとログをはき出せてそれを追えるようになっていることが信頼性や継続性であると。
島田 逆に、そういうことが求められるようなシステムでなければオープン系は良い点は多いですよね。
—— その場でトランザクションが終わってしまうようなシステムとか、ネットのようにうまく動かなければもう1回叩いてみるというようなシステムならですね。
島田 しかし、一方でさきほどの「レガシー」と呼ばれる、いずれなくなるような技術にのっかっているものをどうすればいいかという問題は残るわけですよね。
次ページに続く
この連載の記事
-
第12回
ビジネス
下部構造から脱却する人材育成を──ITSSの狙い -
第11回
ビジネス
なぜITSSの導入は失敗してしまうのか? -
第10回
ビジネス
エンジニアのスキルを共通の「ものさし」で計るITSS -
第9回
ビジネス
「メインフレーム終焉」のウソ(後編) -
第7回
ビジネス
自分たちで決めた自分たちのサービスを出す楽しさ -
第5回
ビジネス
日本発の最注目サイト「pixiv」のヒミツ(後編) -
第4回
ビジネス
日本発の最注目サイト「pixiv」のヒミツ(前編) -
第4回
ビジネス
ビジネスの発想を身につければ研究者は即戦力になる -
第3回
ビジネス
目的がハッキリしていれば産学公連携は成功する -
第2回
ビジネス
コンテンツ消費の縮図「とらのあな」が考えていること - この連載の一覧へ