すごくでか~いシステム 23
ストーリー by kazekiri
保有データならOSDNも張り合えるな 部門より
保有データならOSDNも張り合えるな 部門より
tooBig 曰く,"今日(8月10日)届いた
日経コンピュータ
の記事が面白いです。題して「日本の巨大システム」。「トランザクション処理」、「Webアクセス」、「保有データ」、「パッケージを利用したシステム」の4分野で、国内最大規模の情報システムを記事にしてあります。
「トランザクション処理」では郵便貯金オンラインシステム(3300件/秒のトランザクション)、「Webアクセス」ではヤフー(1億9000万ページビュー/日)、「保有データ」では社会保険庁(保有データ18テラバイト、マスター2億8000万件)、「パッケージを利用したシステム」では第一生命保険(ノーツドミノ利用者数6万5000人)、日本たばこ産業(R/3で100万トランザクション/日)などなどが取材してあります。
どの記事もすんごい数字が並んでいて、ひゃ~って感じですよ。正直「ほら話」のような面白さです。"
そのうち二つは (スコア:2)
動いているのが不思議でしょうがない。
Re:問題はストレージ (スコア:2, 参考になる)
銀行系では,例えば東京と大阪,というように設置場所でも冗長性を持たせてるようです. いつぞやのケーブル火災で懲りたようで…
大規模システムはプロセッサ速度だけではない (スコア:2, 参考になる)
ただ、このようなシステムの場合、顧客の情報を紛失することは絶対に避けなければなりません。そのためアプリケーション設計だけではなく、運用面も考慮しなければなりません。これは計算機資源の木目細かい設定や冗長性はもちろん、計算機自体をどの場所(どの計算機センター)に置くかなど、非常に多岐に渡ります。また、システムをどの運用担当者でも運用できるようなマニュアルも整備しなければなりません。
良いシステムというのは、アプリケーションの速度がすばらしいことが第1に挙げられがちですが、実際に運用する側から見ると、アプリケーション速度よりも障害がまったく発生しないことが一番望ましいです。
アプリケーション開発者から見ると、アプリケーションが速くてなんぼ、かもしれません。しかし、実運用段階に入ったときに、テスト不十分によるバグが見つかった場合には、これは「障害」です。そして、ひとたび「障害」が発生すると、何人もの運用担当の人間が駆けずり回る羽目になります。
そこで、中~大規模クラスのシステムに携わるアプリケーション開発者に一言。少なくともテストだけは十分に行ってください。さもないと、運用担当者の睡眠時間がどんどん削られてしまいます……(;_;)
MIYAZAKI Yasushi
Re:そんなに凄い数字じゃないような気も. (スコア:2, 参考になる)
途中にもちゃんとTPモニタが入って,ほんでクライアントも動いている
とゆう普通に云うところのトランザクションシステムでもっともボトルネックになるのはI/Oでございます.
なーぜメインフレームが最近まで(場所によっては最近でも)使い倒されているかという理由の1つにI/Oが強い,
ということが上げられます(チャネルさいこー).
で,ここんところはCPUのクロックが向上したから自然に性能UPする訳ではないので,そこんとこ誤解無きよう.
ちなみに10年ほど前にぼくが某国産TPモニタの開発チームの末席を汚していたときの
話を思い出すと,やっぱ3000トランザクション/秒とゆうのは
すんごい数字だと素直に思いますよ.
Re:そんなに凄い数字じゃないような気も. (スコア:2)
Re:携帯電話は (スコア:2, 参考になる)
少なくともCPUよりはI/Oの方がネックになるのは上のスレッドで書かれていますけど、OODBの場合はデータを物理メモリ上に展開すればそこそこの速度が出るのですが、ディスクI/Oが入った途端に極端な速度低下が起こります。何故かというとOODBのツリー構造はディスク上に物理構造としてシーケンシャルに記録するのが難しく、つまりはシークが発生しまくりで遅くなる。ということ。キャッシュをたくさん積んだストレージとか、メモリディスクとか使えばいいんでしょうけど。それなら普通のRDBだって速くなるし。
私の知っている某携帯電話会社さんでは、個人情報を格納するRDBをユーザーアカウント毎に分けることによって、負荷の分散と障害の局所化を図っているようです。これからのDBはその観点からも、ビックサーバよりはミドルレンジサーバでの分散構成が主流になるんじゃないでしょうか。
--rena
そんなに凄い数字じゃないような気も. (スコア:1)
数100MHzのプロセッサやDSPを駆使すればたいした数字じゃないと思いますね。
依然、とあるシステム設計していたことがあるんですが、サーバのスピードはそこそこなのに、
何でこんなにトランザクションが流れないんだ!!と思ったことがあります。
結局はシステムのコア部分の作りが悪いとか、テーブルの設計が悪いなどの理由だったのですが、
私は本来のプロセッサの性能を生かせていない気がしてなりません。
話題はそれますが、昔のPC8801やPC9801,MSXのゲームの頃には数M~10数MHzのCPUをフル活用したソフトがたくさんあったのに...
OSもそのくらいの処理件数ならリアルタイムOSを使ったほうが効率的だったりして...
大掛かりなシステムほど、コードが無駄があるのではと思ってなりません。既にソートされてるのにまたソートしたりとか(汗)
Re:そんなに凄い数字じゃないような気も. (スコア:1)
を考えると、毎秒3000トランザクションってのは、結構、
凄い数字だと思ふ。
MSのデータベースでは、どうやっても裁けないだろう。(笑)
Re:M$でおおきいのは (スコア:1)
パルマ-のおなかもキてたけど、会社の態度もね。
まぁ、どこの会社も、図体がでかくなると 多かれ少なかれ態度も大きくなるか。
問題はストレージ (スコア:1)
数十台単位のディスク装置とバックアップ装置、それを結ぶ網の目の様な線図が目に浮かぶようです。
Re:そんなに凄い数字じゃないような気も. (スコア:1)
-- LightSpeed-J
Re:M$でおおきいのは (スコア:1)
まぁ機能的には面白いけど、手数料が高いし、システムがよく落ちるって話を聞くので、アレですが
ところで、金融系情報システムってRDB使うんでしょうか?
いや、こことか、オーラ来るを基幹系に使ってるって話を聞きますし、CRM系とかで使ってる銀行も結構あるんですが、実際郵貯オンライン系とかで使っているとは思えないです。IMSみたいなの使ってるのかな?
Re:M$でおおきいのは (スコア:1)
でもバリバリできるっていうひとはいなかった。SELECT文が判れば、プログラム組める程度でした。
トリガーって何?みたいな部署でした(汗)
Re:M$でおおきいのは (スコア:1)
自分の会社がかかわっているところは、使っていないらしいです。
Re:そんなに凄い数字じゃないような気も. (スコア:1)
Re:そんなに凄い数字じゃないような気も. (スコア:1)
Re:問題はストレージ (スコア:1)
--rena
Re:そんなに凄い数字じゃないような気も. (スコア:1)
メインフレームに関しては愛憎相半ばするのですが,このようなマッシブな
システムの話のときにはやっぱ避けて通れないタームですよね.
記事を読んだ (スコア:1)
はっきり言って化け物ですな。
データのバックアップに一週間。利子の処理でも一週間。よって、利子計算が完了していない口
座にアクセスされた場合は、その時に計算させるという芸当までさせてます。
こりゃあ、まともに動いているのは奇跡かもしれなひ。
M$でおおきいのは (スコア:0)
M$は会社の図体とGates氏の保有株がおっきいくらいで、システムはおおきいのは苦手です。
あ、あと、バルマーのおなかもおおきかった。
Re:M$でおおきいのは (スコア:0)
RDB使ってます。(特に、オーラ来るをバリバリと音が出るくらい)
というかRDB使ってないシステムってないと思います。
ただ、ATMや勘定系などのホントに落ちたらヤバイシステムにオーさんは使ってないと思いますが。
携帯電話は (スコア:0)
処理量というか速度というかが
世界でも稀なヘビーなOODBシステムだった、のだとか。
すれ違い相対速度500km/hを上回って(新幹線)も平然とObjectを書き換えてくれる、
世界最速(意味が違うぞ)のOODBだ、とか言っていました。
Re:携帯電話は (スコア:0)