楽天証券が金融庁から業務改善命令を受けた。ここのシステムがWeb2.0系の技術で作られているかは不明ですが、以前から指摘しているようにWeb系システムの弱点は更新系です。照会系はなにやったって怖くも何ともないのです。そういう意味では証券系のシステムにくらべて銀行やカード会社のシステムは、世間が想像するほど難しくはありません。
銀行やカード会社のシステムの取引単位は口座単位、カード単位です。この一つの単位に取引が集中することはまずあり得ません。その代わりオンライン取引での遅延が許されませんので、DBMS（データベース）ではなくDAM（ダイレクトアクセスメソッド）を使用してこれを実現しています。
DAMと言うのは、口座番号とかカード番号を、あるルールでハードディスクの物理的なアドレスに変換して、たった1回のアクセスでデータを取り出す、あるいは更新することを可能にする技術で、初期の汎用機から一貫して使用されてきたものです。この技術のおかげで、どの銀行のどの地域の支店のATMからでも瞬時にお金を引き出せるし、カードを使ってどのお店でも簡単に与信を取って買い物ができると言うわけです。
ところがこれがWeb系になると、何も知らないアーキテクトが設計して、何も考えずにそのままDBMSを使ってしまい、今回のようなとんでもない事態を引き起こしていると言うのが、オンライントラブルの実態です。特に証券系のシステムの場合、銀行のシステムと違って、取引単位が銘柄であるため、一つの銘柄に更新処理が集中します。更に通常取引だけでなく裁定取引など取引形態が多種にわたっていて、おまけに金融庁へのリアルタイムのレポートが必要であるため、更新するテーブルは銀行系システムの数十倍はあるはずです。
これをDBMSで処理していてトラブルとどうなるかと言うと、まず物理的な処理能力（これはハードの増強で何とかなる）を越えると一斉にシステムが動かなくなります。そうするとアプリケーションはタイムアウトによってロールバックと言う再処理を始めます。ところがここで更新中のテーブルの数が多すぎて、ロールバックも途中で止まってしまいます。完全にシステム停止です。
こう言った事態を防ぐためにもちろんハードの増強は欠かせませんが、そもそも“普通のDBMS”ではミッションクリティカルなオンラインリアルタイム処理には無理があります。これ以降は筆者も現場を離れて長いのであくまで想像ですが、証券向け特殊用途に最適化したDBMS（これは各社最高の企業秘密です）を開発して使っているはずです。
以前のエントリーに、はてなのサーバーシステムがおもちゃなどと失礼なことを書いているのも、今後はてなのサービスがコミュニティ型であることを考えると、この更新系が命になりますから、データがとんじゃったではすまされなくなると言うことです。
まあここらへんからものづくり魂にも書いてあるように、誰も教えてくれないかわりに、技術者のものづくり魂の発揮しどころなんですが、はてさてどうなりますやら。 KAI