von_yosukeyanの日記： メインフレーム 3
SSCのナニを読んでいて思ったのだが、思ったよりメインフレームとは何かというのを理解している人が少ないように思えた。理解している人もいたが、伝統的な「メインフレーム対オープン系」という構図から抜け出せない人もいるし、メインフレームにLinuxを乗せればメインフレームになると思ってる人もかなりいるようだ。
金融系システムにおいて、なぜメインフレームが大量に使用され、どのような弊害をもたらしているのかをある程度理解しないと、あの手の話題はいくら議論しても意味がない。本来ならば、The house of MUNEO houseの続きを書くべきだろうが、微妙に関係してくると思うので少し触れてみることにする
■メインフレームの歴史と定義
メインフレームに対応する日本語として、大型汎用機という言葉が使われるように、メインフレームの語源はコンピューターの外観を呼ぶ俗語として生まれた。最近大型汎用機と言う言葉が使われなくなったのは、「大型」でも「汎用」でもなくなったからという理由もあるが、メインフレームベンダーが主に国内メーカーではなく、IBM中心になったことも関係しているようにも思える。
メインフレームとは、初期のコンピューターのCPUが巨大な鉄の筐体に内蔵されていたことから来ており、とにかく大きいコンピューターをそう呼んだ。例えば、1950年代に登場した初期の商用コンピューターのUNIVAC-1は、演算素子に真空管を使用し冷却装置を備えた巨大なシステムで、筐体内の保守用スペースは一部屋くらいの空間があったという。暑さに耐えかねた初期のプログラマーたちは、その保守用の空間に机と椅子を持ち込んで中で仕事をしたという伝説まである。
だが、現在ではメインフレームは小型化しているし、UNIX機の中にはメインフレームよりも遥かに巨大なものも登場している。また現在、一般的なメインフレームの概念とは遥かに乖離しているのでこの定義は正しくない。
メインフレームを語る上で歴史上最も重要なシステムは、MITとGEが共同開発したMULTICSオペレーティングシステムと、IBMのS/360コンピューターである。MULTICSは、1960年代に対話型インターフェース、高級言語によるOSの記述、TSS(Time Sharing System)など、現在のOSの基礎となる技術が確立されたシステムで、その思想はUNICS(後のUNIX)や、gcosなどのOSに継承された。S/360は1964年に登場したIBMのコンピューターシリーズで、初めてアーキテクチャーと言える設計を導入したシステムとして知られる。
使い古された感がある"アーキテクチャー"と言う言葉だが、S/360以前のコンピューターを見ると、これがいかに画期的な設計思想であったかがわかる。それまでのコンピューターは、システムの用途や規模に応じて異なるOSを採用しており、命令もCPUの設計に極めて依存しており、互換性がほとんどない場合が多かった。
S/360は、はじめてCPUの設計に今でいうマイクロアーキテクチャーを採用し、S/360のアセンブラは小型機から大型機まで互換性を持っていた。高級言語としてはPL/1(PL/I)が採用され、それまでのCOBOL=事務計算、FORTRAN=科学技術計算を統一するものとして売り込まれた。
現在、メインフレームと呼ばれるコンピューターは、IBMではS/360の上位互換システムとしてS/370 > MVS > S/390 > z/Seriesと発展し、日立と富士通はMVS互換のメインフレームを製造している。この他に、NECはgcosから発展したACOSを、UNISYSはOS2200やMCPといった独自のメインフレームを製造しているが、IBMメインフレームから大きな影響を受けているので、本質的なメインフレームの設計思想はあまり変わらない。
■メインフレームの特徴
以上のような点がメインフレームの形式的な概念だが、メインフレームは決して1960年代から全く変わらないシステムという訳ではない。時代を経るに従って、様々な機能や特徴が追加されて現在のような形になったのだが、その特徴についてまとめてみる
・高い信頼性
メインフレームは、一般的に99.99%の可用性を持つと言われている。これを年間稼働率に直すと、ダウンタイムが年間60秒以下となりUNIXの8分、PCの約3時間と比べて遥かに高い信頼性を持っている。これは、メインフレームOSが枯れたOSであるのと同時に、ハードウェアからOSまで単一のメーカーによる一貫したサービスを提供していること。ハードウェア的にCPUからバス、メモリーに到るまで徹底的な二重化･三重化が行われていることが関係している。またハードウェアの稼動中保守なども可能
・CoD
最近では、大型UNIX機やPCでも提供されているが、元々はメインフレームで提供されていたサービスだ。キャパシティー･オン･デマンドとは、コンピューター自身にあらかじめ予備CPUや予備メモリーを搭載した状態で出荷し、処理能力が不足すれば、リモートでCPUを稼動状態にできる。この予備CPUは、通常ではCPUが故障した場合の予備として置かれているもので、処理能力を増強するために使用する場合では型番が変更になる
・保証された互換性と高い処理能力
メインフレームは、基本的に同じのメーカーからハードウェアとCPU、OS、コンパイラが提供されており、時代を経るに従って新しい技術が盛り込まれているとは言え、過去の資産をそのまま活用できる。極端に言えば、何年も前にコンパイルされたプログラムでも、最新のハードウェアとOSでリコンパイルなしでそのまま稼動できる。また、メインフレームは徹底的に命令をハードウェア化したり、広い帯域のI/Oを採用することで高い処理能力を持っている。
・資源管理能力
メインフレームを語る上で欠かすことが出来ないのが、高いワークロード管理である。メインフレームOSは、CPUだけでなく、I/OやメモリーレベルまでWLMと呼ばれるシステムによってプログラムごとに資源を管理できる。この設計思想は、OSだけでなくメインフレーム用に提供されているミドルウェアにも同じような資源管理を行うシステムが組み込まれており、処理資源を最適化できる
・並列シプレックス
この言葉自体はIBM用語だが、メインフレーム版のクラスタリングと考えても差し支えない。UNIXやPCと異なるのは、メインフレームのクラスタリングは専用の接続装置と光ファイバーによって高速に接続され、また世代が異なるシステムでも単一のシステムのように扱える点である。
・VM
最近のメインフレームでは複数のCPUを搭載することが可能で、OSも一つの筐体で複数のOSを稼動させることが可能だが、ハードウェアに対して直接OSを稼動させる方法と、ハードウェアを抽象化するVMを使う二つの方法がある。VMは、前述した高い資源管理能力を搭載しており、一台のメインフレームでオンラインとバッチ処理を同時に稼動させてもパフォーマンスの低下を押さえることができる。また、VM上で異なるOS、例えばOS/390とz/OSとz/Linuxを同時に稼動させることができる。
こういった特徴は、最近ではUNIXやPC/Windowsでも取り入れられているが、性能的に不十分な面が多くまだまだメインフレームが優位に立っている部分が多い
■メインフレームの問題点
このとうな特徴を持つメインフレームだが、金融情報システムのプラットフォームとしてのメインフレームには問題点が多い
一つは、メインフレーム技術者の不足である。メインフレーム上の開発言語は、日本では一般的にCOBOLとPL/Iが中心である。高い生産性を持ったメインフレーム技術者の不足は金融界に限った話ではないが、特に金融ではインターネット対応や、情報系システムで大量に採用されているUNIX系システムとの接続の必要性から、いわゆるオープン系とメインフレームの双方の知識をもった技術者が求められる。
また、日立、富士通、NECなどの国内メーカーは、IBMに対抗してCOBOLを積極的に普及させてきたが、IBMはCOBOLにあわせてPL/Iの普及にも努めてきた。PL/Iはすでに過去の技術と思われているが、金融系システムではバッチ系やオンラインでまだ多くのPL/Iで記述されたコードが残っており、この保守人員の不足も問題である
さらに、勘定系システムのような高いパフォーマンスを求められるシステムには、高級言語ではなくアセンブラによって記述されているものもある。現在は、メインフレーム自体の性能が向上しているので、アセンブラによる記述は減っているように思われるが、銀行の勘定系システムではアセンブラによる記述が行われているものが勘定系を中心に大量に残されており、基幹系の近代化に悪影響を与えている。
二番目にはメインフレームは極めて高価である点である。メインフレームは基本的にハードウェアはレンタルやリースだが、ソフトウェアは購入ではなくワークロード利用料という形で課金される場合が多い。OSやVM、ミドルウェアのそれぞれで利用率やCPU数で課金され、さらに運用にはメーカー側の保守人員が常駐する場合の多いメインフレームは、運用コストが割高で、大量にメインフレームを使用している金融機関にとって大きな負担になっている。
三番目には銀行基幹系の多くが、個々に独自に開発されてきた歴史と、そのしがらみがある。多くの基幹系システムは、RDBMSやIMSのような階層型DBをあまり使っておらず、特に勘定系ではその傾向が高い。高い互換性から、何十年も前のコードが継ぎ接ぎのように保守されてきたものも多く、DWHやインターネットバンキングシステムなど新しく追加されたシステムとの不整合や、コードの肥大化などの問題を引き起こしている。また、予算削減方針などで、従来のようなプロジェクト管理や、保守体制を構成でいない場合があり、大規模な基幹系トラブルの原因になっている。
■メインフレームの高信頼性の嘘
実は、先に挙げたようなメインフレームの優位性には伝説的な部分もある。実態と照らし合わせてみると先に挙げたメインフレーマーが主張する年間99.99%の可用性には、重大な嘘が含まれている。大型システムにおけるハードウェア障害のトップはメモリーとストレージの障害だが、UNIXとPCの可用性統計にはストレージの障害が含まれているが、メインフレームのものにはストレージの障害が含まれていない。現実的な話、メインフレームのストレージは最近はほとんどSANを用いているが、大規模UNIXやPCでもSANを使用しているので、ストレージの障害という点ではメインフレームもUNIXも変わりがない。しかも、IBMが主張する可用性に関してはメインフレーム単体の可用性というだけでなく、並列シプレックス構成の場合が混じっている点に注意しなければならない
■メインフレームの将来性
メインフレームの将来性に関して、云々しても仕方がない面も否めないが、ベンダーの方針や現状について簡単だが記述したい
・日立
富士通と共に、MVS互換メインフレームを製造しており、90年代には最後までCMOS演算素子に移行せず、極めて大型のバイポーラ素子を採用する路線をとっていた。98年にこの独自路線は正式に放棄され、大型機では当分ACEと呼ばれる独自のCMOSプロセッサ開発は継続するものの、中小型機ではIBMからの購入に切り替える。海外の販売法人であるHDSのメインフレーム販売は縮小の傾向で、Linux対応は一応行っているようだ
・富士通
日立と共に、MVS互換メインフレームを製造しているが、90年代半ばにはIBM互換路線を放棄し、大規模なOSの機能強化は行わない方針。CPUの64bit化には消極的だが、処理能力の増強には今後も積極的な方針。Linux対応は基本的には行わず、中小型で筐体内にSolaris機やPCを内蔵できるモデルを発売している。アムダールは清算の方向に、富士通シーメンスのメインフレーム販売は縮小の傾向
・NEC
条件付ながら、64bitに移行した国内唯一のメーカー。Linux対応は基本的にはメインフレーム本体で行う予定はない。今後もシリーズの継続とOSの強化を行う方針。海外市場は元々それほど大きくないし、金融市場での採用は少ないこと、HPと提携してUNIXとItaniumシステムに力を入れている関係から金融市場への影響は低い
・UNISYS
独自のOS2200系、MCP系の二つの製品ラインは、IAサーバーをベースとしたシステム上でエミュレーションする方針で、独自のメインフレームは基本的には放棄の方向に向かっている。むしろ、超大型のIAサーバーに力を入れており、Windows DC系の提案が増えているように思える
・IBM
CPUとOSの64bit化、CPUの命令充実と処理能力強化、OSのUNIX化、VMの強化、並列シプレックスの強化、Linux対応、ミドルウェアの充実とどの点をとっても攻撃的にメインフレーム路線の強化を行っている。顧客に対するメッセージも明確で、オープン系の取り込みさえも行っているように思えるが、自社のUNIXと競合する部分も否めない
■では、銀行基幹系にメインフレームは適合しないのか？
という問題は、すこし題としてはボクには重すぎる感があるが･･･。
メインフレームからオープン系へ、というのは過去のソフトウェア資産から近代的で保守性の高い、新しい銀行基幹系システムへの移行のチャンスでもある。一つは、全くゼロから基幹系を設計しなおすことだが、上位地銀と比べても圧倒的に基幹系システムの設計が古い都銀でさえも、この投資コストは簡単にまかなえるものではない。
もう一つが、パッケージや共同システムを使う方法である。新生銀行がインド製の銀行パッケージを使用して、短期間に基幹系システムを構築したことが話題になったが、現実的に海外の銀行パッケージは独自の商慣習がある日本の銀行業務でそのまま使えるわけではない。だが、少数だが日本の銀行業務に適合したパッケージは存在し、Windowsで･･･という極端なものはあまりないが、第二地銀や組合系の金融機関の中にはパッケージを利用したものやパッケージを利用した共同システムを採用する例が増えている。
だが、プラットホームがメインフレームかオープン系かという問題はそれほど重要ではないことは確かだ。例えば、三井住友銀行の新基幹系システムはメインフレームベースで開発されているが、プラットフォームに依存し保守性の低いシステムから、柔軟性のある新しいシステムへの移行を実現している。SMBCの場合は、勘定系はACOSで構成されているが、やろうと思えばUNIXで構成することも可能であるという。
単純には比較できないが、海外の総合金融グループではこのようなプラットフォームに依存したシステムや過去の資源に依存したシステムからの脱却に成功している場合が多い。そう言ったシステムだからこそ、WindowsやUNIX、メインフレームなどメインのプラットフォームは適材適所で選択されている。
といったところで、（かなり変なところがたくさんあるが）めんどくさくなってきたので、今宵はこれまでにしとうございます
雑感 (スコア:1)
そんなわけで、メインフレームにはそれほど詳しくはないのだ。なので、メインフレームに関しては、一つだけＳＩサイドの課題（？）を提示するだけに止める。
それは、なぜ、メインフレームでのアウトソーシングと、オープン系でのアウトソーシングの収益性（利益率）が違うのだろうかという疑問である。
アウトソーシングとは、サービスを提供することに意味があるはずであって、サービスレベルが同等であるならば、それをメインフレームで実現しようと、オープン系で実現しようと構わないはずなのに、なぜか、世間の相場は、オープン系で実現した場合には安く抑えられるだけでなく、利益率まで低くなるという疑問である。
これに関しては、メインフレームの市場に、オープン系システムを売り込むときの売り込み方に失敗して、それが相場として定着してしまったのではないかと疑っているのだが。だれか明確な答えをお持ちの方は居ないだろうか？
それはさておき、本題としては、
という点に絞りたいと思う。
一応、論点を整理すると、
と言う感じか。順番に、行こう。
まずは、(1)に関して。これは、恐らく必要であろう。何より、新しいサービスを提供するときの足枷となっているようでは、今後の競争で不利になるのは火を見るより明らかである。理想を言えば、コンポーネントで開発することで、保守容易性を確保するとか何とかなりそうなものであるが、後述するように難しいようだ。
次に(1)(a)。これも事実だろう。今までもｘ次オンラインとかいって投資しているが、今の銀行の体力では、その投資に耐えられないと思われる。
次は、(1)(b)。これは誰でも思いつくのだが、意外に難しいようだ。聞いた話をいくつか並べてみる。
で、次が、(2)か。都銀クラスの場合と、地銀クラスの場合で分けた方がいいかも知れないな。
まず、都銀クラスの場合。都銀クラスの場合、システム再構築の選択肢としては、次のようなものが思いつく。（とりあえず、運用方式はおいておこう）
まぁ、(i)は論外として、(iii)はどうだろうか？オーバースペックの可能性はあるが、不可能ではないだろう。また、(iv)のように、外部のパッケージを導入できるだろうか？恐らく、新生銀行のように割り切らなければ、むしろ割高になる気がする。(v)も、都銀クラスだとメンツが絡むので現実的でない気がする。
written by こうふう
Re:雑感 (スコア:1)
・都銀、信託銀行、大規模地銀(預金量10兆円付近)、系統金融機関系共同システム(信金、信組、農協)、メーカー系共同システム（地銀）のどれもでも、勘定系にオープン系を採用しているところはない
・自営地銀、新生銀行（銀行勘定規模では中規模地銀以下）、ネット銀行ではオープン系勘定系を採用している例もある
・都銀でのオープン系の採用は、情報系、国際系、対外接続系、制御系といった勘定系から見ればフロントエンド的なシステムで、比較的複雑ではないトランザクションの処理に使用されている。
■基幹系を更新する理由
・金融庁の指導（実はこれ、結構大きい）
・勘定系運用コストの削減
a)共同運用化でスケールメリットを生かす
b)開発費の共同分担
e)業務の共通化、オーバースペックな第三次オンラインで付いた贅肉を落とす
・情報系やATM網を含めた運用コストの削減
c)開発費の共同分担
d)情報システム部門･子会社の分離（リスク部門の分離）
■基幹系を更新する方法
・パッケージを利用する
1)自営システムの更新
2)パッケージを使った共同システムに参加
・共同運用システムに参加する
3)すでに稼動している自営他行のシステムに参加する
4)すでに稼動している自営行同士が自主開発したシステムを持ち寄る
5)メーカー/コンサルが開発した共同運用システムを利用する
6)何行かがメーカー/コンサルを中心に集まって共同システムを開発･利用
7)勘定系、国際系、証券系といったシステムごとにASP利用
8)自行システムをメーカーに売却
・基幹系を更新しない
・自主開発を続ける
・余力のありそうな金融機関と合併する
■メインフレームを採用しつづける理由
・既存の資源が再利用できる
・管理･運用負荷が低く、開発も楽
・コストパフォーマンスが高い
・トランザクション管理、ワークロード管理のための特殊なツールをわざわざ開発しなくていい
・開発体制を変更しなくてもよい
・生産性の高い言語、ミドルウェア
■オープン系を採用する理由
・豊富なミドルウェア
・ハードウェア、ソフトウェアが安い
・豊富で優秀な技術者
・開発期間の短縮化
・開発したフレームワークを他にも販売できるかもしれないところ
・分散化がやりやすく、安定した運用が期待できる
■メインフレームがダメなところ
・運用･管理コストが高い
・技術者の不足
・既存の資源を再利用してもコストの削減にならない。将来的な拡張にも耐えられない
・メインフレーマーの掠奪体質、付き合いのあるベンダーとのしがらみを断ち切れない
・開発期間の長期化
■オープン系のダメなところ
・運用･管理コストが高い
・ワークロード管理やトランザクション管理などメインフレームで実現されている機能がオープン系では不足している
・既存の資源を再利用できない
・メーカーやベンダーによる手厚いサポートが受けられない
・開発体制や管理体制を再確立する必要がある
・開発管理がきちんとしてる金融系ベンダーやコンサルがあまりいない
Re:雑感 (スコア:1)
理由としては、現在NTTデータが運用している共同運用システムはメインフレームを使用したシステムだが、SSCの共同勘定系は地区センター(二箇所だか三箇所だか忘れたが)ごとに勘定系が稼動している。全信用組合数は340、預金規模は7月のデータで100兆円ほどだが、仮に共同センターに移行する金融機関が100金庫、預金総額30兆円、顧客数3000万程度と仮定すると、都市銀行並みの大型システムと考えられる。この想定だけでは、国内の銀行でオープン系に移行した事例はない。
だが、そもそも単一ないしは複数のシステムで30兆円規模、3000万口座レベルを格納する勘定系を用意する必要があるのだろうか？ 信用金庫の平均預金残高は3000億円程度で、平均口座数は30万程度に過ぎない。最大の信用金庫である京都信用金庫ですら預金規模3兆円ほど、地銀では中位行であるみちのく銀行や山陰合同銀行レベルに相当する。
極端な話、オープン系で勘定系を構成する場合には、金庫ごとにシステムを用意してもお釣りが来るくらいだし、このレベルであればすでに第二地銀レベルの銀行がオープン勘定系パッケージを利用した共同運用システムに移行しているのでメインフレームでなければダメだという理由にはなりにくい。単にシステム間は為替関連の通信をやってればいいわけで、イニシャルコストを安く押さえるために、UNIXではなくWindowsを採用したいというのもわからなくもない。
実は、過去にも巨大規模で似たようなシステムが存在した。旧住友銀行の第三次オンラインシステムで、旧NCRメインフレームからACOSシステムに移行するとき、単一な巨大システムを作るのではなく、店群ごとに勘定系を稼動させるという分散指向なシステムだった。
問題は、このオープン勘定系フレームワークをフューチャーが完成できるかだが･･･。