パスワードを忘れた? アカウント作成
780 story

すごくでか~いシステム 23

ストーリー by kazekiri
保有データならOSDNも張り合えるな 部門より
tooBig 曰く,"今日(8月10日)届いた 日経コンピュータ の記事が面白いです。題して「日本の巨大システム」。「トランザクション処理」、「Webアクセス」、「保有データ」、「パッケージを利用したシステム」の4分野で、国内最大規模の情報システムを記事にしてあります。 「トランザクション処理」では郵便貯金オンラインシステム(3300件/秒のトランザクション)、「Webアクセス」ではヤフー(1億9000万ページビュー/日)、「保有データ」では社会保険庁(保有データ18テラバイト、マスター2億8000万件)、「パッケージを利用したシステム」では第一生命保険(ノーツドミノ利用者数6万5000人)、日本たばこ産業(R/3で100万トランザクション/日)などなどが取材してあります。 どの記事もすんごい数字が並んでいて、ひゃ~って感じですよ。正直「ほら話」のような面白さです。"
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • あの会社か。
    動いているのが不思議でしょうがない。
  • さらにフェイルセーフの為に多重化していたりして…

    銀行系では,例えば東京と大阪,というように設置場所でも冗長性を持たせてるようです. いつぞやのケーブル火災で懲りたようで…

  • プロセッサの速度がGHzオーダーになったのは最近になってから。確かに今作ればもっとパフォーマンスが向上するかもしれませんが、これらのシステムは既に長期間稼動しているものが多いです(計画中のものは除く)。そのため、これらのシステムで使用されているプロセッサ速度単体だけ考えた場合には確かに劣っているかもしれません。

    ただ、このようなシステムの場合、顧客の情報を紛失することは絶対に避けなければなりません。そのためアプリケーション設計だけではなく、運用面も考慮しなければなりません。これは計算機資源の木目細かい設定や冗長性はもちろん、計算機自体をどの場所(どの計算機センター)に置くかなど、非常に多岐に渡ります。また、システムをどの運用担当者でも運用できるようなマニュアルも整備しなければなりません。

    良いシステムというのは、アプリケーションの速度がすばらしいことが第1に挙げられがちですが、実際に運用する側から見ると、アプリケーション速度よりも障害がまったく発生しないことが一番望ましいです。

    アプリケーション開発者から見ると、アプリケーションが速くてなんぼ、かもしれません。しかし、実運用段階に入ったときに、テスト不十分によるバグが見つかった場合には、これは「障害」です。そして、ひとたび「障害」が発生すると、何人もの運用担当の人間が駆けずり回る羽目になります。
    そこで、中~大規模クラスのシステムに携わるアプリケーション開発者に一言。少なくともテストだけは十分に行ってください。さもないと、運用担当者の睡眠時間がどんどん削られてしまいます……(;_;)

    --
    MIYAZAKI Yasushi
  • by jvm16 (1311) on 2001年08月11日 15時14分 (#12987)
    むー,たとえばまともなDB動かして(とゆうとリカバリのためのログも取り,ジャーナルバッチリで),
    途中にもちゃんとTPモニタが入って,ほんでクライアントも動いている
    とゆう普通に云うところのトランザクションシステムでもっともボトルネックになるのはI/Oでございます.
    なーぜメインフレームが最近まで(場所によっては最近でも)使い倒されているかという理由の1つにI/Oが強い,
    ということが上げられます(チャネルさいこー).

    で,ここんところはCPUのクロックが向上したから自然に性能UPする訳ではないので,そこんとこ誤解無きよう.

    ちなみに10年ほど前にぼくが某国産TPモニタの開発チームの末席を汚していたときの
    話を思い出すと,やっぱ3000トランザクション/秒とゆうのは
    すんごい数字だと素直に思いますよ.
  • 大掛かりなシステムほど、コードが無駄があるのではと思ってなりません。既にソートされてるのにまたソートしたりとか(汗)
    実際、大規模システムではまさにその通りなんですよね。 だけど、こういうシステムっていくつものサブシステムに分割されていて、そのすべてのサブシステムにセンスのあるマネージャ、設計者、プログラマを揃えるのは現状では難しい。
    確かに毎秒3000トランザクションという数字は桁違いだとは思うが、現在の 数100MHzのプロセッサやDSPを駆使すればたいした数字じゃないと思いますね。
    そう思うなら、ぜひそういうプロジェクトに参加してみて欲しい。
  • Re:携帯電話は (スコア:2, 参考になる)

    by renaissa (4104) on 2001年08月13日 12時56分 (#13209)
    私の知っている某がどの某なのかわかりませんが。。。

    少なくともCPUよりはI/Oの方がネックになるのは上のスレッドで書かれていますけど、OODBの場合はデータを物理メモリ上に展開すればそこそこの速度が出るのですが、ディスクI/Oが入った途端に極端な速度低下が起こります。何故かというとOODBのツリー構造はディスク上に物理構造としてシーケンシャルに記録するのが難しく、つまりはシークが発生しまくりで遅くなる。ということ。キャッシュをたくさん積んだストレージとか、メモリディスクとか使えばいいんでしょうけど。それなら普通のRDBだって速くなるし。

    私の知っている某携帯電話会社さんでは、個人情報を格納するRDBをユーザーアカウント毎に分けることによって、負荷の分散と障害の局所化を図っているようです。これからのDBはその観点からも、ビックサーバよりはミドルレンジサーバでの分散構成が主流になるんじゃないでしょうか。
    --
    --rena
  • 確かに毎秒3000トランザクションという数字は桁違いだとは思うが、現在の
    数100MHzのプロセッサやDSPを駆使すればたいした数字じゃないと思いますね。
    依然、とあるシステム設計していたことがあるんですが、サーバのスピードはそこそこなのに、
    何でこんなにトランザクションが流れないんだ!!と思ったことがあります。
    結局はシステムのコア部分の作りが悪いとか、テーブルの設計が悪いなどの理由だったのですが、
    私は本来のプロセッサの性能を生かせていない気がしてなりません。
    話題はそれますが、昔のPC8801やPC9801,MSXのゲームの頃には数M~10数MHzのCPUをフル活用したソフトがたくさんあったのに...
    OSもそのくらいの処理件数ならリアルタイムOSを使ったほうが効率的だったりして...
    大掛かりなシステムほど、コードが無駄があるのではと思ってなりません。既にソートされてるのにまたソートしたりとか(汗)
  • 郵便貯金の利用者の数と、それらの履歴、郵便局の数
    を考えると、毎秒3000トランザクションってのは、結構、
    凄い数字だと思ふ。

    MSのデータベースでは、どうやっても裁けないだろう。(笑)
  • by fgd (2415) on 2001年08月11日 1時04分 (#12932) 日記

    パルマ-のおなかもキてたけど、会社の態度もね。

    まぁ、どこの会社も、図体がでかくなると 多かれ少なかれ態度も大きくなるか。

  • by tsubone (3599) on 2001年08月11日 1時26分 (#12933) 日記
    花形じゃないけど、ディスク装置とバックアップ取るのが大変そうだなーと。高速化のためにボリューム単位で別々のバックアップ装置に書き込んでいて、さらにフェイルセーフの為に多重化していたりして…

    数十台単位のディスク装置とバックアップ装置、それを結ぶ網の目の様な線図が目に浮かぶようです。

  • こういう規模のシステムをスクラッチから起こすようなことは現実ではありえないんじゃあないでしょうか?こういう話は規模が小さいときだけに当てはまるような気がしますけど。あとは、コンピュータシステムはコンピュータと「むろん」同義ではなく、上位概念だというのも心にとめておきたいものです。
    --
    -- LightSpeed-J
  • この証券会社なんですけど、なにやら金融証券系システムを すべてMS製品で固めている のがご自慢だそうで、ボクのようなリスク許容度の低い人間には、恐れ多くて使ったことないです ハイ(w

    まぁ機能的には面白いけど、手数料が高いし、システムがよく落ちるって話を聞くので、アレですが

    ところで、金融系情報システムってRDB使うんでしょうか?
    いや、こことか、オーラ来るを基幹系に使ってるって話を聞きますし、CRM系とかで使ってる銀行も結構あるんですが、実際郵貯オンライン系とかで使っているとは思えないです。IMSみたいなの使ってるのかな?
  • by 0.1uF (3815) on 2001年08月12日 0時22分 (#13028) 日記
    私の前勤めてたトコでは使ってましたヨ。
    でもバリバリできるっていうひとはいなかった。SELECT文が判れば、プログラム組める程度でした。
    トリガーって何?みたいな部署でした(汗)
  • by nobichan (4085) on 2001年08月12日 12時41分 (#13091) 日記
    >ところで、金融系情報システムってRDB使うんでしょうか?
    自分の会社がかかわっているところは、使っていないらしいです。
  • I/Oの中には当然プリンターも含まれますよね。利用者に通知する際には郵便を使うわけで、並みのプリンタでは、あて先印刷だけでも気が遠くなる時間が必要です。ここらあたりの分野では、まだまだ大型機(ホスト機)が幅を利かせているように思います。
  • 現在の TPC-C の上位に SQL-Server がすでに結構出ていますから、捌けるかというだけなら捌ける、というべきでしょうね。性能に関してはほかのデータベースに大負け、ということはないでしょう。 安定性などの実用面はまた別な話でしょうけど。
  • by renaissa (4104) on 2001年08月13日 13時01分 (#13213)
    ふつーはミラー化したディスクを切り離して、ずるずるとテープライブラリに吸い取るようですよ。そして取り終わったらまた繋いで、syncをかけると。
    --
    --rena
  • もちろんプリンタI/Oも含みます.

    メインフレームに関しては愛憎相半ばするのですが,このようなマッシブな
    システムの話のときにはやっぱ避けて通れないタームですよね.
  • by WindKnight (1253) on 2001年08月25日 20時57分 (#16926) 日記
    郵貯のシステムで、秒あたり3300トランザクション、端末数7万、口座数6億2500万、総データ量32Tバイト。

    はっきり言って化け物ですな。

    データのバックアップに一週間。利子の処理でも一週間。よって、利子計算が完了していない口
    座にアクセスされた場合は、その時に計算させるという芸当までさせてます。

    こりゃあ、まともに動いているのは奇跡かもしれなひ。
  • by Anonymous Coward on 2001年08月10日 23時22分 (#12920)

    M$は会社の図体とGates氏の保有株がおっきいくらいで、システムはおおきいのは苦手です。

    あ、あと、バルマーのおなかもおおきかった。

  • by Anonymous Coward on 2001年08月12日 2時46分 (#13045)
    実際に某銀行の情報系システムを担当していますが、
    RDB使ってます。(特に、オーラ来るをバリバリと音が出るくらい)
     というかRDB使ってないシステムってないと思います。
     ただ、ATMや勘定系などのホントに落ちたらヤバイシステムにオーさんは使ってないと思いますが。

  • by Anonymous Coward on 2001年08月12日 4時47分 (#13048)
    何年も前に聞いた話だけど、某携帯電話会社は、
    処理量というか速度というかが
    世界でも稀なヘビーなOODBシステムだった、のだとか。

    すれ違い相対速度500km/hを上回って(新幹線)も平然とObjectを書き換えてくれる、
    世界最速(意味が違うぞ)のOODBだ、とか言っていました。
  • by Anonymous Coward on 2001年08月14日 19時29分 (#13622)
    超ミッションクリティカルな物は,障害率が上がってしまうので,処理の分散は避けつづけるかもしれないですね。
typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...