発端
去年、Naoya Ito さんがこんな話(System of Record と System of Engagement)をした後、SOEとかSORとか話題になることも多くなったと思う。
そんな折、ちょうどいいタイミングで、SOR中のSORなシステムである銀行システムの話を、日本における銀行システムの曙までさかのぼってまとめた本が出たのでさっそくゲットした。
Title: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus)
Publisher: 技術評論社 (Feb. 2, 2017)
Author: 星野 武史 (著), 花井 志生 (監修)
ISBN-13: 978-4774187297
Publish Date： 2017/2/4
Amazon: https://www.amazon.co.jp/dp/4774187291
一応、「書評」とはしたが、書きはじめたら与太話が長くなってしまった(苦笑)
以下のような感じである。
- 本書の紹介
- 銀行システムのデータベースの話
- 若い人にはわかりにくい(かもしれない)事項の補足解説
- 私の想いのようなもの
- まとめ
- 参考
本書はどんな本か？
まずは本書に何が書かれているのか、箇条書きでまとめておきたい。私視点では以下の通りである。
- 日本の銀行システムの黎明期から現在、そして著者による今後の予想が書かれている。
- 「n次オンライン」といった話は、誰でも名前くらいは聞いたことがあると思う。(いや、ないのかな...^^;
- IBMのメインフレーム (現在は z Systems)のハード、ソフト(OSおよびDBやTPのような基幹ミドルウェア)の機能、構造、動作が、歴史も含めて詳しく解説されている。
- 折りに触れて、Linuxや商用UNIX等、あるいはRDBMSとの比較もある。
- 各時代の銀行システムに求められる要件を、IBM製品を使ってどのように実現してきたのか、詳しく解説されている。
銀行データベースとは
本書でもっとも重要なのは、銀行システムの特に勘定系(要するに口座のお金を管理するところ)で使われているデータベースの、特にデータモデルの話だろう。
昨今、SQLでさえ直接は書かない人が多くなりつつある状況下で、リレーショナル・モデル/RDMBS/SQLの登場よりもさらに前から存在するものがあり、実は今も社会の中枢はそういうもので支えられているというのは驚きではないだろうか。しかも、その実装(IBM IMS)の開発経緯は、実は'60年代のアポロ計画の部品管理のために作られたというのは私も知らなかった。驚きである。
さて、このデータモデルを、階層データモデル と言う。木構造でデータを表現するもので、親と子の間には 1:n の関係がある。本書で手厚い解説がなされるIBMのIMS (Information Management System)は、階層データモデルの代表的な実装である。各種データモデルの発展の歴史については、この記事がまとまっていると思う。なお、IMSはDBMSであるだけでなく、トランザクションモニタの機能も包含しているのに注意してほしい。もう一点、トランザクションの実態だが、Jim Greyの "Transaction Processing: Concepts and Techniques"の p42 1.5 Historical Notes によると、IMSでは1973年には既にACIDトランザクションを実装していたとのことである。
(IMSの各データベース実装の、トランザクション分離レベルについてはよくわからない。どなたかご存知であればご教授いただければ幸いである。)
SOEとSOR
冒頭で触れた Naoya Ito さんの場合は、エンジニアのチーム視点で「リスペクトが～」という問題意識だったようだが、SOR と SOE、どちらのシステムが尊いということはない。どちらもないと困る。
一方、「(SORの権化たる(?))汎用機なんて化石」と思っている人も多いと思うのだが、その化石で作られたシステムがなくなったら自分の生活がどうなるか？考えてみてほしい。実際、化石のように昔から変わらない側面もあることはあるのではあるが、社会の、しかもいちばん厳しいところを支え続けているシステムがどうのようなもので、どう進化を続けているのか、実情を知っておくのは非常に有益だと思う。
補足解説(与太話)
以下、与太話が長くなってしまったので、あまり興味ない人は読み飛ばしていただければと思う。
本書を読みすすめるにあたって、ハード・ソフトともに、オープン系になれた人にはなじみのない概念が多いと思うので、メインフレームの特徴的なところを少し補足しておきたい。ただし、私が現役でメインフレームを触っていたのは20世紀までの話なので、基本的に知識が古いということはご了承願いたい。ただ、本書でも触れられているとおり、50年前のS/360のプログラムがそのまま動く事実が示すように、後方互換性に多大な注意が払われているのがメインフレームの特徴でもある。基本的な部分はそのまま踏襲されていると考えていただいてよいかと思う。
ディスク装置
メインフレームのディスク装置は、DASD (Direct Access Storage Device)と呼ばれる。
現在、普通に使うHDDは、セクタ長512バイトの固定長(LBDはおいておく)のはよいかと思う。しかし、標準的なDASDは可変長のレコードサイズを持つ。ハードウェアレベルで、シリンダ、トラック、レコードという構造を持っており、これがそのままソフトにも見えるということだ。なお、固定長のディスク装置もあるのだが、それはFBA (Fixed Block Architecture)と呼ばれ、少なくとも私が現役のころは標準的ではなかった。
ファイルシステム
UNIXのファイルはbyte streamであって、構造はないのはよいかと思う。一方、メインフレームのファイルには構造がある。これは前述のハード(DASD)の構造がそのまま見えるようになっているということである。また、本書でも触れられているが、メインフレームではDASD上のデータのまとまりは、ファイルではなく「データセット」と呼ばれる。
では、ファイルシステム全体としてはどうか？
メインフレームのOSには、UNIXのような階層ファイルシステムという概念はなく、DASDのボリューム通番(VOLSER)とデータセットの名前で指定することになる。本書でも言及があるが、カタログと呼ばれるしくみを使うとボリューム通番の指定は省略できる。
なお、データセットには「編成(organization)」という概念がある。Partitioned Organization (PO)という編成を使うと、1つのデータセットをオープン系のディレクトリのように使うことができる。
コンソール
一般に、コンソールといえば本体に直接接続されたディスプレイ＋キーボードのことを挿すと思う。これはメインフレームでも同じなのだが、メインフレームの場合、コンソール自体がインタラクティブな機能をもっており、(TSOでログインせずに)サブシステムの起動停止やデバイス操作などのコマンドを投入できるようになっている。
チャネル
コンソール、ディスク装置(DASD)等あらゆる入出力を扱うのがチャネルである。チャネルは専用のIOプロセッサを持っており、CPUからは、CCW (Channel Command Word)と呼ばれるI/Oプロセッサの命令列を組み上げてI/O処理を要求する。オープン系で言えば、SCSIコマンドプログラミングのようなものだと理解してもらえればよい。
なお、私が扱っていた互換機では、チャネルDATと呼ばれる仕組みがかなり初期から実装されており、I/Oプロセッサがメインメモリに/からデータを書き込む/読み出す際に、仮想アドレスを使えるようになっていた。iommu が出てきた時には、チャネルDATの特許も切れたのだな...と思った記憶がある。
クラスタ用通信機構 : CF (Coupling Facility)
本書でも、クラスタの説明などで何度か出てくる CF という装置がある。これは、Coupling Facility の略で、実体は外付けのメモリ装置である。専用のCPU命令で、メインメモリとCFの間でデータのやりとりできるようになっている。CFは複数のサーバから接続して共有DISK的に使えるようになっている。これを利用して、たとえて言えば黒板にみんなで自分の生存情報を書き込んで死活確認をする…といった使い方もできる。なお、少なくとも富士通のCF相当の装置は、外付けメモリも仮想記憶が使えるようになっていて、CF(相当)アクセス専用のDATがあった。
クロスメモリ
本書で解説があったとおり、メインフレームのアドレス空間のサイズは当初16MB(24bit)、次に2GB(31bit)に拡張された。(zArchitecture では後に64bit化されている)
しかし、大規模になるにしたがって、2GBでも足りなくなることがある。このため、secondary address space という概念が存在する。Unix/Linux でたとえて言えば、他のプロセスのメモリを読み書きするCPU命令、あるいは他のプロセスの中のルーチンを呼び出すCPU命令があるということである。
ハードウェアスタック
このへんからだんだん与太話になる。
CPU命令の知識がある人は、ハードウェアスタックがないコンピュータなんて想像できないかもしれない。push/popとか、call した際のレジスタ退避先とか。
実は、当初のメインフレームには、ハードウェアスタックがなかった。
なので、関数コールの前にmalloc(相当)のシステムコールを使ってレジスタ退避域を呼び出し側が用意し、呼ばれた側が処理のはじめに退避するというリンケージ規約になっていた。つまり、レジスタ退避域が不連続に双方向リンクトリストとしてメモリ上に散在しているということだ。もちろん、ある時期にハードウェアスタックも(オプションとして)実装されたのだが、私が現役の当時はOSの処理一般には古いリンケージ規約のままだった。今はどうなっているのだろうか？
EDIT命令
これは本当に与太話。
信じられないかもしれないが、メインフレームには、printf のような指定フォーマットにしたがって、指定の変数を文字列展開してくれるCPU命令がある。ED命令という。新ハードサポートに伴う性能レポートの開発を担当したときに使ったのだが、今となってはよい思い出である。
私の想いのようなもの
さて、与太話はこのくらいにしておいて、元々の話に戻ろう。
実は、正直に言うと、読み進めながら少し違和感を感じていた部分がある。
suggestion の意味もこめて、少しまとめておきたい。
- IBMメインフレームの視点に偏っている
- 著者はIBMの方で、視点は一納入ベンダからのものになるので致し方ない側面もあるのだが、日本の銀行システムの場合、富士通/NEC/日立のシェアも大きく、ベンダによってはIBMとは違う技術を使っていることもある。
- 特に、DBのデータモデルはもっとも重要なポイントだと思うのだが、都銀勘定系レベルでも、本書で詳しく解説されているIMSの階層データモデルだけではなく、ネットワークモデルのDBも広く使われていた。当然、提案の現場では比較を行っていたはずなので、そういった見識も書かれていればよかったのではないかと思う。
- Linux等オープン系の技術、製品についての理解は最新ではない部分がある
- これも致し方ない側面があると思うが、現在では比較の根拠がなりたたない部分がある。本書は非メインフレーム系で働いているエンジニアにこそ読んでほしいものだとすると、すこしもったいないと思う。
- 基本的に製品の機能や動きの説明であり、背景理論に踏み込んでるわけではない
- 私がこの本を一番読んで欲しい、一群の若くて優秀な人たちがいる。彼らが私のような世代と決定的に違うところは、最初から情報科学を基礎からきっちり学んで身に着けているということだ。この意味で、彼らに説得力を持って訴えかけるためには、特に分散システムまわりの背景理論との関連の解説があればよかったと思う。
ところで、非メインフレームで銀行システムを作って運用できるのか？できたとして、それは長い目で見てペイするのか？これについては、さまざまな意見がある。私個人の意見も時期によって揺れているのだが、twitter 上の有名な金融クラスタの(というか、なんでも)論客のつっちーさんのつぶやきまとめを紹介しておきたい。
「銀行システムにメインフレームが残る理由 by @tsuchie88」
まとめ
本書の紹介のつもりだったのだが、思わず与太話が長くなってしまった。
最近の進化や、今後の展望までふくめて、ここまでまとまった銀行システムの本はなかったと思う。労作である。人によっては違和感を感じるところもあるかもしれないが、ぜひ一読してみてほしいと思う。
参考
- 階層データモデル https://en.wikipedia.org/wiki/Hierarchical_database_model
- 各種データモデルの比較 http://www.kogures.com/hitoshi/history/db-ndb/index.html
- IBM IMS https://en.wikipedia.org/wiki/IBM_Information_Management_System
- トランザクション処理 https://en.wikipedia.org/wiki/Transaction_processing
- 「メインフレーム・コンピュータ」で遊ぼうhttp://www.arteceed.net/
- アメリカのメインフレーム系コンサルの会社 http://www.longpelaexpertise.com.au/index.php
- つっちーさんのツイートまとめ https://togetter.com/li/784889
- https://en.wikipedia.org/wiki/Count_key_data
- 小川さんによるS/360系資料の連ツイ https://twitter.com/ogawa_tter/status/734360400557281281
disclosure : 私はなにものか
自分の立ち位置を書いておくと、私はこんなバックグラウンドの人である。
経歴的には、日系メーカー→大手SIer→外資メーカーと渡り歩いた。
IBM互換メインフレームのOS開発部隊でのソフト開発業務を振り出しに、研究職を経由して、(インフラ系)SEと立ち位置を変えながら現在に至っている。汎用機以外の技術やプロダクトとしては、Solaris・クラスタインタコネクト・Linux・オープンソース・OpenStack あたりがキーワード。立ち位置はR&Dと現場火消し部隊の間をいったりきたりしながら、今は Solutions Architect という肩書きで仕事をしている。
この雑文が、かなり異なる２つの世界の橋渡しに少しでも役立てば幸いである。