東証システム、構築は10年前ですでに耐用年数もオーバーしていた 240
ストーリー by GetSet
10年は夢のよう… 部門より
10年は夢のよう… 部門より
nq曰く、"asahi.comの報道によれば、東京証券取引所の清算システムは、10年前に導入した日立製メインフレームで、一日分の取引内容を記録するハードディスクの容量で取引件数の上限が決まっているという。システムの貧弱さが断片的に報道されていたが、10年前の機材でネット取引の時代に対応できると考えていた証券取引所へ日本の経済が頼っていることに、唖然とするのは私だけではあるまい。"
続報：NIKKEI.NETの記事によれば、この週末で処理能力の増強テストを行い、23日からは約定件数の1日当たりの上限を500万件に引き上げる、とのことだ。「空白の10年」が更改遅れの原因の一つかもしれないが、迅速な決断と行動に期待したい。
NYとの差 (スコア:5, 参考になる)
Re:NYとの差 (スコア:5, 興味深い)
システム増強に掛かる費用を市場から入手できるか否か、というのも大きいと思います。
思い切った増強をしようにも、上場をしていなければ、
手数料の値上げなど、市場としての使い勝手に関わる部分に手をつけざるを得ないので、
難しいのではないかと思います。
そういう意味で、上場はシステム増強に掛かる費用を捻出するための、有効な手段だと思うんですが、
残念なことに、東証の上場には金融庁からストップが掛かってるわけで、
今後、金融当局の責任も問題になってくるのではないかと思います。
Re:NYとの差 (スコア:2, 興味深い)
平時の大商いの3倍程度の処理能力は様々な「有事」を想定すると必要。さらに、大商いは現在300～400万件だとしても、近い将来に倍の水準ぐらいになることは簡単に予測可能なわけで、そうすると2000万／日位に最低限設計しなければ安心出来ないですよね。ＮＹのようなスーパースペックでないにせよ。
今から新システムを立ち上げるにあたって、500万／日と2000万／日でそんなにコストが違うもんですか？あとからちまちま増強するよりむしろトータルで安上がりな気がす
るんですが。
Re:NYとの差 (スコア:4, 興味深い)
米証取でシステム障害 [yahoo.co.jp]
これについて何か詳しい情報って出てないんでしょうか？
どうも情報がねじ曲ってるような気もしますので (スコア:5, 参考になる)
(2)1約定48byteもあればできるんじゃない?みたいなこをを書かれていますが、そんなに簡単じゃないです。色々な処理番号やらありますので。
(3)デスマーチ....でしたよ（笑）
(4)10年使ってたのは何故なんでしょうかね。取引所に金がない、ということが全てではないでしょうか。正確に言うとシステム投資をケチっている、ということです。あとは、取引所内では一番規模の大きなシステムでかなり(仕様が)スパゲッテイな状態だったみたいです。
(5)新聞を出してどうの、って言ってますが、「それだけ社会的に中ようなシステムなんだよ」という説明にはわかりやすかったのではないでしょうか。今みたいにTVのニュースやワイドショーじゃ、取り上げられてないので一般人に近い新入社員にはこのシステムの重要性は分らないと思います。でも、これじゃ誰もやりたがらないと思うけど。
でも、株の取引量の推移を正しく読めるようであれば大儲けできると思うんですけどね。じゃあ、5倍10倍のキャパを常に用意するのか、と。10年間キャパの見直しをしなかったのはともかくとして、じゃあどれだけ用意すればOK、なんて誰が言えるのでしょうかね?
元関係者なのでAC。
待ってました(Re:どうも情報がねじ曲ってるような気もしますので) (スコア:2, 興味深い)
(1)アプリ開発はどこだったのですか？まさか、日立の子会社ではないですよね？
(2)色々な処理情報だのなんだのあってということですが、一約定あたり48byteの20倍の1kBあったって、5M倍してもたかが5GB。大した量じゃないんじゃないですか、ということを書いたのですが。
(3)略
(4)「システム投資をケチっている」これが本質ですね。時代の推移と技術の動向に関してまったく判断ができなかった東証の経営陣に呆れるばかりです。
だけど、システム屋さんの方も、普通、3，4年ごとぐらいには、処理能力を倍増するような改修を提案するものじゃないんですか？それとも、そのような提案はしたけれど、東証の経営陣がまったく一顧だにしなかったとか？
どれだけ用意すればOKなんて誰が言えるか、ということですが、一日あたり出来高のぶれの大きさをみて、その5～10倍ぐらいの余裕を見たほうがよい、というのは統計学的には難しくない判断です。
米国のデイトレーダーが話題になってから、すでに数年経っています。e-Trade が日本で営業始めた時には、現在の状況を可能性の一つとして想定して準備を始めているべきだった、と思うわけです。
Re:待ってました(Re:どうも情報がねじ曲ってるような気もしますので) (スコア:4, 興味深い)
最近15年程前の事務機の後継者が居ないと言う事で、
引っ張りだされていたので苦労話を少し。
当時のスペックでは、速度を稼ぐ為にアセンブラに近い事をやらされます。
具体的にはレジスタに入れて出してと言う操作ですね。
オブジェクト指向はもちろん、クラス化もされていない（出来ない） ため、
小規模の改修でもすぐスパゲティになってしまいます。
また、ソースのサイズが64KBに制限されていたため
コメントが書けなかったり、変数の数に上限が有ったり、
ソースの保存はFDだったり、印刷には制御コードを使うなど、
久々に手応え（？）の有る仕事でした。
今回の話で考えますと、ハードを追加する事で上限を引き上げる事が
可能のようですから、ハード・ソフト的には10年以上を見越して
構築されているのは間違いないと思います。
それでも問題になってしまったのは東証サイドの判断の甘さ
（具体的には金銭でしょう）が根底にあるのではないかと
感じましたが、実際どうなんでしょうか。
中の人がいらっしゃれば、是非お聞きしたい所です。
Re:待ってました(Re:どうも情報がねじ曲ってるような気もしますので) (スコア:3, 参考になる)
(2)1件の約定で複数のファイルを作るので、もうヒトコエあると思います。ただ、メインフレームの5GBって安くないですよね? 最新のストレージって繋がらないような気がするし。
(4)他。10倍のキャパを用意するとして、普段使われない90%のキャパをムダ、という経営判断をしても仕方ないのでは? 単純に入り(手数料収入)を10倍に引きあげる訳にはいかないですから。
もちろん、取引所はそうじゃねぇだろ、ってのもわかるけど。でも、何か起きないと誰も特別扱いしないよね......
デイトレの読みは甘かったとは思いますね。それは言い訳のしようがないと思われる。
Re:どうも情報がねじ曲ってるような気もしますので (スコア:5, 参考になる)
少なくとも、メインフレームのクラスタリング技術はオープン系のものよりもかなりと進んでいます。ホストを追加した分シームレスに性能が向上しますし、郵貯のオンラインやNTTのSTARシステムなど、10台以上のホストを使った、オープン系クラスタでは構築できないような大規模なシステムもあります。大体、東証の市場系システムも、ニューヨーク証券取引所のシステムも、メインフレームを使った並列シプレックス構成なので、プラットフォームは関係ないと思います
問題は東証のシステム負荷の見積もりが甘すぎるところでしょう。現状の運用方針では、1日の最高処理数の40%を余剰処理能力として想定しシステムを構築して、75%を超えればシステムを停める検討を行うという体制をとっています。これは、取引に人手が介在して限界が決まる場立ちがあった時代のシステム想定で、今のようにネット経由で大量の注文が寄せられ市場の取引量がシステムの処理能力によって限界が決まるような状況は想定していませんし、場中の発注･取消のレスポンスタイムを一定内に押さえるといった想定はしていません。これは、東証に限った話ではなく、大証やJASDAQは昨年から場中のレスポンスが大幅に低下していて、非常に問題になっています(東証より状況は悪いと思います)
ビジネスがどう行なわれているかの想像力の問題 (スコア:4, すばらしい洞察)
東証はどうかは知りませんが、私が知る限り、日本の会社の場合は、経営者の考えが未だに手書きの書類で処理を行なう事を前提にしか考えられないのが問題を複雑にしていると思います。
そのため、事務処理はコンピュータを主にして行なうように設定されるのではなく、あくまでも補助の役割しか与えられないような中途半端な導入をしてしまいがちです。
それで、さらに仕事の方法を複雑にする。
そのため、一般の事務職も、管理職も、自分が扱っている仕事の資源やデータをコンピュータのデータベースに集中させずに手書きの書類やら、独自に集計したエクセルの表ばかり頼りにしてしまい、仕事の手順をスタンドアロンのコンピュータによって分断してしまうというバカな結果を得てしまいます。
また、その状況を追認するように、コンピュータシステムの投資は消極的になり、現状維持があくまでも当面の目標となってしまいがちです。
また、経営者も経営のプロではなく、ただの業界の政治的な調整者である場合も多いという現状も問題でしょう。
経営のプロであるなら、自らの経営資源や事務処理の流れがどうなっているのかを知っておくのが当然でしょうが、契約や、事務処理がどういう流れになっているのかさえ知らない人もいるくらいです。
そういう経営者ですから、自社のコンピュータシステムがどうなっているかの知識すらないのが実際でしょう。
だから、東証の今回の事件も社長がどれだけコンピュータシステムの事を分かって言っているのかとっても疑問です。
問題が起こってからその内容を技術的な問題で突っ込んで質問なんて事は当然できるはずも無く、また、技術者が一生懸命説明しても無駄で、ただただ怒るばかりの状況でしょう。
目に見えるようです。
そうして、部下と技術者に見下されるばかりで恥を晒しているんでしょう。そうして、技術者と経営者の溝は深まり、、、っと思います。
技術の問題じゃないです。
ライブドアの株式数は異常 (スコア:3, 興味深い)
ライブドアショック 上場廃止への不安広がる 売買単位で全市場の３割超 [business-i.jp]
Re:ライブドアの株式数は異常 (スコア:3, 参考になる)
今夜のNHKニュースでやってましたが、ニューヨーク証券取引所の限界処理能力は平時の10倍あるらしいですよ。
Re:ライブドアの株式数は異常 (スコア:5, すばらしい洞察)
Re:ライブドアの株式数は異常 (スコア:5, 興味深い)
投資家層(特に短期投資系)の増大を見越せ、
っていうのは無理でしょうが、
５年前には予測できたんじゃないかなぁ。
今はライブドアが寄らないから崩壊していませんが、
寄った瞬間から恐ろしい祭りが始まるでしょう。
何せ、今出てるだけでも3億株ほどの売り注文を捌く必要がありますから。
(件数は別問題ですけど)
東証がどんな対応をとるか見物です。
そのあと、祭りが本格化して短期派が総出で引っかき回し出したら・・・
Re:ライブドアの株式数は異常 (スコア:5, 参考になる)
去年の誤発注事件がおきてから慌ててCIO職を新設して、現在は社外から候補者を捜している最中だそうです。
立ち会いも無くなり完全にオンライン化されて何年もたつのに、そのインフラの切り盛りをイニシアティブをとって行うポジションが未だ存在しなかったと言うのが驚きです。
素人考えですが、システムの現状把握や更新に関するトップの意志決定に遅れが生じていたのではと疑ってしまいます。
まさかまたデスマ? (スコア:3, 興味深い)
> 次期システム開発は、東証と日立で数年前から進めていたが、０４年後半に迎えた耐用期限に間に合わず、その後は現行システムの保守・整備で対応していた。
また無茶な開発をしているのか?
上記記事通りなら最低一年の延伸をやっている訳だよね。
#昔の関係者なのでAC
Re:まさかまたデスマ? (スコア:5, 参考になる)
就職活動で日立に行った人間曰く、
「私らが失敗すると、このように記事になります。」
と新聞の一面を見せたそうです。
怖いのは、それを反省材料ではなく、社会的影響度・会社の
規模のデカさの自慢として伝えていたこと。日立外せ、
確かにそうですね。
-- gonta --
"May Macintosh be with you"
風聞の流布 (スコア:2, おもしろおかしい)
Re:風聞の流布 (スコア:4, 興味深い)
どっかの記事で読んだと思うけれど、
NY証券取引所も
Solaris -> Linuxのはずだけれど。
(ソース忘れた)
その記事では、NY証券取引所自体がシステム部を持っていて、
そのシステム部がカーネルに手を入れていると読んだような気がする。
kusanagi shin
ムーアの法則でいくと (スコア:3, おもしろおかしい)
500万件なんて足りなさ過ぎますよ！
Re:ムーアの法則でいくと (スコア:2, 参考になる)
http://www.yomiuri.co.jp/atmoney/mnews/20060120mh06.htm
いったい日本はなにをやっているんでしょうか・・
Re:いったい日本はなにをやっているんでしょうか (スコア:2, すばらしい洞察)
虚業として見られがちで、実際にそういうスタイルで売買を行う個人投資家の増加が昨今は著しい。
ライブドアショックで騒ぎになってる、信用取引を行って借金を作ってしまった人間のような、
身の丈を考えない個人投資家が殺到していなければ表面化していなかったわけですし。
バブル崩壊のショックがでかく、株式投資市場の拡大成長が遅れたという要因もあるでしょう。
それにしたって見通しが甘いという批判をかわせないでしょうが。
＃でも、耐用年期間は十分だったんだから見通しが甘いとも言い切れない。
＃リソースのプチ更新も、新システム移行を前にした暫定処置だとすれば、
＃本格的に大増強できるはずが無く、ライブドアショックが例外で不運だったような。
Re:いったい日本はなにをやっているんでしょうか (スコア:3, すばらしい洞察)
> そうはいっても、日本人には株式投資が「１日で儲ける」とかいう地に足のつかない、
> 虚業として見られがちで、実際にそういうスタイルで売買を行う個人投資家の増加が昨今は著しい。
こういうスタイルは、投資じゃなくて投機だとおもうのです。「個人投機家」って呼ぶべきなんじゃないか、とニュースで「個人投資家」という言葉を聞くたびに思っています。
改修って… (スコア:3, 興味深い)
処理件数がHDD容量に依存、ってことは
今回の改修ではそこしかいじってないわけですよねぇ。
となれば、これ以上の増強は不能なのか、まだ増強の余地があるものを小出ししてるだけなのか、
非常に気になるのですが。
こういう言い方したらアレですが、もし後者なら
100万件分増やすのも600万件分増やして許容数を一桁上げるのも
費用的には実は大して変わらんのと違うのかなぁ。
Re:改修って… (スコア:5, 興味深い)
桁数が変わるとレコード設計が変わるので大事です. 正しいプログラムならかなり機械的に修正できるはずですが, プログラム的には間違っているけどたまたま動いている, 例えば本来使用すべきレコード型ではないけど桁数が合っているので動いていたなんて物が火を吹く可能性が高いです.
というか, この種の古いシステムはたとえ10年前に改修されていたとしても, その当時の技術レベルで作られているなんて甘い期待はしちゃだめです. 特に設計については旧来のシステムとの継続性を最重視するので, 20〜30年程度前の思想に基づいて作られています. そのため, 最近のプログラムの様にヘッダやモジュールの修正で全体を一気に作り直すなんてことは不可能と思っておいた方が安全です.
それじゃ完全に一から作り直した方が速そうな気がしますけど, これもダメですね. 仕様を切れる人がいませんから. こうした大規模システムを扱っている人って, 下手に昔からやっているだけに, システムを大所高所からトップダウンで分析的に行うって手法に疎く, 個々の処理手順や出力といった末葉からボトムアップで積み上げることしかできませんから. 流通業なんかなら, 営業とか経理あたりの部門がイニシアチブを取って進めることで刷新するなんてこともありますけど, 証券取引業だとどうなんでしょ?
Re:改修って… (スコア:4, 興味深い)
結局、一から作り直したものに更新するしかないように思いますが、完全に新式のものと、旧式のものを二つ並行して半年ぐらい走らせながら検証して移行する、というわけにはいかないものでしょうか？
ソフト屋さん、システム屋さんには、すごく大きなビジネスチャンスのように思いますが。
Re:改修って… (スコア:3, 興味深い)
新システム系と旧システム系でまったくおなじデータを処理するならともかく、新システムに伴い周辺の接続システムも機能追加などでインターフェース要件が変更になることがままあります。すると、並行稼動のためには、両系のシステムのデータをさばく必要が出ます。しかし、現実には、そのためのインフラを保守する費用の問題や、それゆえのパフォーマンス問題などで、結局、どちらのシステムも危機的な状況に陥ってしまうことになります。
お客さんが、夢見なけりゃできるんだけどね＿|￣|○
でも、すんごいお金投資してオープン化するんだし、その分、便利になってよ、っていう気持ちもわかるのよ。そうして、すべてのシステムを一夜にして切り替える、というすばらしい計画ができる、と。
# やっぱりAC。
Re:改修って… (スコア:2, 興味深い)
古き良きCOBOLで書いてあるとすると、1000万未満までは保つかと。だから逆に数カ月以内に７００万〜８００万件に増強する方針 [asahi.com]と小出しにし、何とか件数を押え込もうとている気がします。で問題なのはその３０日には予定されていた新コンピューターによる次期システム移行でしのぐ方針 [asahi.com]がこの縛りにあることで、次期システムとやらでも遠くは無い未来には行き詰まってしまい、その頃にハードウェアもソフトウェアも全面更改した次次期? システムが稼働できる当てが無いことかと。
Re:改修って… (スコア:2, 参考になる)
Re:改修って… (スコア:2, 参考になる)
| …
| これ以上の増強は不能なのか、まだ増強の余地があるものを小出ししてるだけなのか…
周りのinterfaceやbus(たうぜん10年前仕様。)がボトルネックになって、既にサチッてるかそれに近いので、単純に足しただけでは駄目になってるのでせう。全体の容量を増やすのは簡単ではないと。
# さもなければ、とっくに増設して一件落着の筈。
# は? もしかして「その10年前仕様の汎用機用HDDが入手難」なーんてことは、よもや無いですよねそーですよね。
## ということで、全面更改以外に抜本策が無い気がします。
Re:改修って… (スコア:5, おもしろおかしい)
Re:改修って… (スコア:2, 興味深い)
脆すぎないか東証のシステム [itmedia.co.jp]で
とあるので倣うのも手かと。Re:改修って… (スコア:2, 参考になる)
現実にとある生産管理システムで処理対象品種を大幅に増やそうとしても，桁数が足りなくてどうにもならないなんて例を目にしたことがある．
そんなんチョイとソフトをいじれば済む話じゃないかと担当者に言ったら，システムのつぎはぎの繰り返しで出来上がった膨大な本数のプログラムの修正なんて簡単に出来ないんだよと言い返された．
Re:改修って… (スコア:3, 参考になる)
ちょっと違うな。
新規開発当時は、後のことを考えて余分を入れておくのがセオリー。
COBOLでいうところのFILLERってやつだな。
もちろん記憶容量の節約はするが、最初からギチギチにはしない。
そしてつぎはぎ改修のときに、その部分に追加されたデータを格納するようにするわけだ。
今まで使っていなかった部分にどんなデータが入ろうと、既存部分には影響が出ない「はず」だからね。
そしてその余分を使い切って、どうにもならなくなったときが、システムの寿命…
１０年 (スコア:3, 興味深い)
システムの切替えの時期だったと考えれば１０年前のシステムだと言われてもそんなにおかしな話ではないです。
ただし、システム運用上、現在のシステムの能力のピークと（日々増えて行く） 要求されている能力を見て増強するか、システムの切替えするかを判断しなければ ならないので、のほほんとかまえていたってのは事実でしょうね。
もしくは、いきなり取り引きが膨れ上がるって事を想定していなかったのか、 そもそも、（正常に動いていればオッケー程度で）システムの運用ってのを 知らなかった可能性もありますが、
ちなみに、携帯電話のシステムなんざ、１０年見越して作ったシステムが ５年でパンクしたってのがあります。
当然、パンクする前に次機種の開発がスターとしたんですがね。
当時は競争が激しかったので現行機種はどんどん機能追加をしていたので、 新システムの設計に加えて現行機種の機能追加にも対応という要求が、、、 （以下、自主規制）
Re:１０年 (スコア:3, 興味深い)
正確に言うと、構築を引き受けた某社がしくじったもので、仕方なくそれまでのシステムを使い回すことになったと。
まあ、この業界ではよくある話ですよね。
デジタル土方を粗末にした結果 (スコア:3, おもしろおかしい)
という声が、あちらこちらから。
（あ、私だけ？）
そーいえば1999年まで手サイン使ってたね (スコア:2, 興味深い)
懐かしい。
しかしこのままいけば (スコア:2, おもしろおかしい)
え？そのためのライブドアショックじゃなかったの？
Re:約定件数 (スコア:3, 興味深い)
システム増強といっても、単にハードディスクの容量を増やして、それに対応してプログラムの配列の上限チェックを変更しているぐらいと想像しますが、それで2倍程度にしか増えない、ということにまた驚きます。技術的進歩を考えれば、100倍ぐらい、楽々増やせるはず。
素人考えですが、500万件の売買記録にどれぐらいの記憶容量が必要かと勘定してみると、銘柄コード、取引時刻、売り手コード、買い手コード、株数、取引価格という6つのlong int で済むとすると 48 byte * 5M = 240 MByte ですか。
売り手、買い手をコード化せずにすべて１００字ずつぐらい使って、さらにいろいろな付加情報をつけて、データベースのインデックスつけたりして、この20倍、一件あたり 1 kByte 使っても、5 GB で足りますね。10年前の汎用機で5GB HDD というのは極端に小さいものではなかったかも知れません。
しかし、現在なら、その10倍の50 GBに拡張しても今のノートPCにも入るぐらいの容量です。
こう数えてみると、東証のシステムは、現代においてコンピュータを日常的に使う者の想像を絶した貧弱なものと思われます。
Re:約定件数 (スコア:5, 参考になる)
これには二つの理由があります
一つは、東証の現行の市場業務系システムが構築された90年代後半は、証券自由化前後で取引がまだ立会い取引が残っていた時代で、不況で取引が低迷していた頃にシステム企画がなされたという点です。オンライン取引が普及していない頃の話で、取引量も現在のように多くなく、札幌や福岡など他市場のシステムを東証のシステムと共同化することが大きな目的の一つでした。従って、企画の時点で、取引が(立会いなど)物理的に制限される取引が前提で行われたので、一日の総取引件数がシステム要件とされたのでしょう
もう一つは、今回の記事で問題になっているのは、取引の約定処理を行う市場業務系システムではなく、約定した取引を決済機関(証券保管振替機構とみずほコーポレート銀行兜町証券営業部など清算銀行5行)で決済処理を行うための、清算指図(DVP)を作成処理するためのシステムです。従って、処理はオンライン処理ではなく、バッチ処理が大半です。また正確に言えば、この清算システムを運用しているのは、東京、大阪、名古屋、福岡、札幌の各取引所とJASDAQが共同出資して作った株式会社日本クリアリング機構が運用するシステムです
ハードディスクの容量 (スコア:3, 参考になる)
確かにそうなんだけど、昔のコンピュータに最新式のHD
は付かないんじゃないかな。
OSが管理できる最大サイズ、とかハード的なインタ
フェースの問題とか。
たとえば、10年前のPCに、最新式の、500GのHDは繋がら
ない(認識しない)でしょ。BIOSの制限とかで。
それと同じで、拡張しようにも出来なかったのでは
ないかなあ。
Re:約定件数 (スコア:2, 興味深い)
IDにしても英数字を入れるから絶対にCHARだと言い張る人が多くて頭が痛いです。
DBのマニュアルには数値型を使ったほうが速いと書いてあるのですが、なぜ容量が余計に必要なCHARにしたがるのかよくわかりませんが、そのような傾向があるようです。
＃少なくとも某社の人たちは。
Re:約定件数 (スコア:2, 興味深い)
でも、集計や計算の必要のない識別子はchar(n)でよいと思いますけど。なんでもかんでもvarchar(n)は、行連鎖を引き起こす危険性があるので好きではないですが。速いからといって、ビット型で構成されたデータベースを使いたいとは思いませんし、適材適所でしょう。
# という判断を標準で殺している場合がある、というのは同意。
## そして、現場に任せたらそれ以上にひどいことになる、というのも同意。
## フラグの判定を半角スペースとNullでやるのはやめて……。
Re:約定件数 (スコア:2, おもしろおかしい)
うわぁ…逆に凄い。
Re:この１０年 (スコア:5, 参考になる)
そして10年保証で10年以内にリプレースしてくれる客はそう多くないのが実情。
で、部品がなくなり保守打ち切りを通知すると怒り出す…。
結局のところ買う側の意識が「少なくとも10年モノ」で、リプレース時期の予算や経済状態に左右されるのでどうしようもありません。
売る側も売る側ですが、発注側の意識も変わらないといけませんね。
ASPなど、基幹部分をメーカのIDCなどに任せて、必要な端末だけをレンタルするソリューションが主流になりつつある分野もありますが、勘定系システムなどは難しいでしょうね。
Re:この１０年 (スコア:3, 興味深い)
現存のシステムがコアメモリを使っているもので、
更改後がエントリーレベルのエンタープライズサーバ
クラスのマシンが数台を‥
これが数年前ですから‥
いやこれでも業務には支障はなかったようで‥
＃性能設計はきちんとしてマージンも3倍は取りましたし
増強すればその3倍まではいけるという目論見も‥
＃更改前はほんまもののバグを見れたかもしれないのに‥
Re:この１０年 (スコア:3, 興味深い)
東証自身も株式会社ですし、そもそも大規模システムの代表選手の一つでもある金融系システムの親玉みたいなものですから。
たとえば、UFJ銀行や野村證券のシステムは、Javaなどそれなりに新しい技術(UFJは情報系だったと思いますが)も使い、非常に大規模な構成のシステムを構築した上で適宜ハードウェアの更新は行っています。年間の投資も当然100億単位です。
単純に規模で比較することは出来ませんが、東証のシステムはがその安定性や堅牢さ、応答性能においてこれらに見劣りするようではまずいでしょう。
Re:HDD容量が足らなければ買ってくればいいじゃないの (スコア:3, 参考になる)
その記憶装置がどのくらいの大きさと値段なもんか、ちっとくらい「想像するなり」「ググるなり」すれば、調子はずれなコメントも減るんじゃないか・・と
多分１５年前に情報処理試験受験してた様な人たちには常識なんだが・・・
Re:動いているものには触れてはいけない (スコア:3, おもしろおかしい)
ことがありました。コンソールの配線だったので、ランプが
つかなくなっただけで助かりましたが、、
しばらく時間がとまりました