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

UFJ銀行が基幹システムにLinux導入 172

ストーリー by wakatono
適材適所が加速される 部門より

Futaro 曰く、 " 毎日のこの記事 によりますと、UFJ銀行が基幹システムにRedHat Linuxを採用した、ということです。いよいよ日本の銀行もこういう時代になってきたのですね。しかしながら、メインフレームで余った人たちはこれからどうするんでしょうか?"

構成は、Egenera + Redhat + Oracle9i RAC というもの。EgeneraのプレスリリースCTCのプレスリリースが出ている。なお、稼動開始は今年の9月だとか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 今頃? (スコア:5, 興味深い)

    by Anonymous Coward on 2003年07月29日 18時37分 (#368049)
    私は、地方でフリーのSEやってますけど、
    既に30社はLinuxでシステム組んで納品してますよ、
    小規模なのは、LANのみで20クライアント程度のシステムから
    うちの中で比較的大きいシステムは、250支店でとか色々ですけど。
    特に問題も無く、以前はACOS2で数億円かけていたシステムが
    Linuxを使う事で 数千万円で、しかも、今までのシステムよりも
    高速になったとウケは抜群でした。

    意識としてはLinuxが基幹業務に!ってのは既に当然の話であって
    むしろ、Windows2003Serverで!って方が衝撃的だよね。(笑)
    • by ncube2 (2864) on 2003年07月29日 18時45分 (#368057)
      >以前はACOS2で数億円かけていたシステムが

      でも今回のはACOS6かケチってもACOS4の上位クラスを使うような規模では?
      ACOS2の代替なら「Linux当然」とは思いますが。
      (IDL2,COBOL/S,RIQS,ADBS,VSAS,CPL,HPL...今となっては忘却の彼方)
      親コメント
    • by doripush (653) on 2003年07月29日 19時08分 (#368068)
      > むしろ、Windows2003Serverで!って方が衝撃的だよね。(笑)

      意図するところが良く分かりませんが、まだリリースされて間も
      ないWindows 2003 Serverだから衝撃的という意味なんでしょうか。
      一般的にLinuxよりもWindowsの方が衝撃的という意味なら、それは
      逆ではありませんか? Windowsだったら先例もあるわけだし、ここ
      まで話題になるとは思えません。この間の政府の給与管理システム
      の件も同様でしょう。
      親コメント
    • お話を否定するつもりは毛頭ございませんが、新しいハードウェアのほうが速いというのはある程度当たり前ではないでしょうか?4年前に数千万円で導入した某社ワークステーションよりも、2年前に5万円程度で購入できるマシンのほうが演算速度がはるかに速かったので、技術計算用途ではPCで十分でした。
      親コメント
  • Linuxもだけど (スコア:2, 参考になる)

    by shadowfire (6584) on 2003年07月29日 17時00分 (#367960) ホームページ
    こっちもなかなか挑戦的

    大規模Javaは甘くない・UFJ銀行 目指すは1日1000万件のバッチ処理
    http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030703/1/ [nikkeibp.co.jp]

    え~、Javaで~?マジで~?と問い詰めたくなるような。

    --
    --------------------
    /* SHADOWFIRE */
    • Re:Linuxもだけど (スコア:2, 参考になる)

      by patagon (1453) on 2003年07月29日 23時21分 (#368214) 日記
      > 1日1000万件のバッチ
      データの処理としてのバッチ、それはそれで結構。
      だがしかし、その前にデータを集める、送るという前段階、後処理について。
      全銀協標準通信プロトコル(BASIC手順)の最大9600bpsよりはましになったとはいえ、それを元にした全銀協標準通信プロトコル(TCP/IP手順)では通信に時間がかかってしょうがない。しかも多くの銀行は64Kどころか9600bpsのまま。データ圧縮したとしてもたかが知れてる。そんなんだから大量データはカートリッジテープでやり取りをしつづけねばならない。その結果、必然的にカートリッジテープの運送にかかる時間、料金というコストが下がらない。これでは口座振替を利用する企業、ひては消費者へのサービスには繋がりにくい。全銀協ってダメダメといつも思う。

      新たなプロトコルとか、通信環境の整備が必要かと。
      親コメント
    • 思わず Doubleを使ってしまって微妙に金利計算の誤差が
      出てくるのは避けてもらいたいですね。
      いや・・当然その辺りはBigDecimalのみを使うんだとは
      思うけど、実はそれだと処理速度の問題で一部Doubleで・・
      なんてのがあったりするかもなぁ・・と。
      もちろんちゃんと仕様が明確になっていても意外に・・ってのが・・。
      親コメント
  • COBOL on Linux (スコア:2, 興味深い)

    by zeissmania (3689) on 2003年07月29日 17時01分 (#367961)
    >メインフレームで余った人たちはこれからどうするんでしょうか?
    そりゃもちろん、メインフレームのアプリをLinuxに移植する作業をさせられるんですよ。
    Linux用のCOBOL開発環境 [microfocus.co.jp]だってあるんだしさ。
    • by znc (2768) on 2003年07月29日 17時06分 (#367968)
      まぁ,.NET対応のCOBOLもある様ですから,COBOLはこれからも
      生き延びそうですね・・・・・
      しかしredhatか・・・・・
      確かredhatのサポートって結構短いと聞いていますが
      大丈夫なのかな・・・・・
      # マイナーチェンジやバグパッチはともかく,
      # メジャーバージョンアップはそう簡単には出来ないはずだけど・・・
      --
      『今日の屈辱に耐え明日の為に生きるのが男だ』
      宇宙戦艦 ヤマト 艦長 沖田十三氏談
      2006/06/23 JPN 1 - 4 BRA
      親コメント
      • Re:COBOL on Linux (スコア:2, 参考になる)

        by raijin (7091) on 2003年07月30日 1時18分 (#368295)
        >>メジャーバージョンアップ
        こういった環境で
        通常する必要があるのでしょうか?
        もちろんセキュリティホール対策等のパッチは
        当てると思いますが。

        きちんと能力のあるSIとサポート契約すれば
        別にバージョン古くともサポートしてくれる
        と思いますよ。 それこそがLinuxのメリット
        でしょう?
        親コメント
        • by esumi (15966) on 2003年07月30日 4時06分 (#368354)
          無いですねえ。(というか、すると面倒な事に成りかねない)
          アップデートはいいとして機能や実装の詳細が変化してしまう
          ようなものはしないようにすると思います(その意味では独自にソースをいじれるLinuxを選んだのはとても正解な気が致します)。
          仮にメジャーバージョンアップする事があるとして、それは今回の”次”の本格的なシステム構築時になるのでは無いでしょうか。
          その時もLinuxが選ばれるかどうかは神のみぞ知る、ですね。

          よーするにコストダウンなんでしょうけどシステム移植する人は
          死ねますね。ご愁傷様です。あー。
          親コメント
      • by katsuwo (17163) on 2003年07月30日 5時04分 (#368360) 日記
        RHLよりオラ様のサポート切れのほうが心配でございます(TT)
        --
        @大阪なヒト
        親コメント
    • by Anonymous Coward on 2003年07月30日 3時14分 (#368345)
      Windowsの開発環境で組み込み系の開発しております。
      最近、メインフレームであまった人と一緒に働いています。

      Windowsの基本操作をバカにして覚えてくれず作業がのろのろで、
      (ファイルの名前返るのに数分かかる、とか)
      自分でつくったバグをみてまずコンパイラを疑う
      テキストエディタの使い方がよく分かっていない
      など非常に使い物になりません。
      たまたまアレゲな人なのかもしれませんが
      こんな人はあまらせてほしくないなぁと切に願います。

      謙虚な心を忘れずにAC
      親コメント
  • リンク先 (スコア:2, 参考になる)

    by hide2 (1062) on 2003年07月29日 20時57分 (#368136) ホームページ
    毎日新聞のリンク先は、todayではなくこちらのほうが良いのでは? http://www.mainichi.co.jp/digital/solution/archive/200307/28/2.html [mainichi.co.jp]
  • 皆さん勘定系にLinuxなんて、と言う意見が多いですが、tps+信頼性を稼いでくれるのはむしろOracle RACのほうでしょう。これは掛け値なしにとんでもないなぁ、と個人的に思っていますが。

    個人的には、「少なくともOracle RACを勘定系で動かせる程度にはLinuxは安定している」というOracleの判断なのかな、と思います。ま、RedHatというよりOracleの手腕に期待かな。

    • by k2n (9818) on 2003年07月30日 5時39分 (#368363) 日記
      RACの前にWeblogicが座っているわけですから、トランザクションのスループットと信頼性にはRACの上に、Weblogic8.1が大きく関わります。前出の日経の記事を読む限りでは、EntityBeansを使わずにSessionBeans+ORマッパーでSQLを発行しているように理解できますが、まさしくこのあたりが性能を出す肝になるでしょう。

      あと、個人的にはJRockIt on Linuxで行く点に注目してます。サポートの観点からはベンダーを揃えるのは正解だと思います。しかし、実績という観点では、JRockItも買収前から考えれば結構長いですから安定しているのかもしれませんが、ユーザーベースから考えれば圧倒的にSunJDKの事例が多いので、果たしてJRockItが十分枯れているのかに興味があります。

      #Sun JDK+Weblogicだと、未だにHotSpot Internal Errorに悩まされることがあるので...

      でも、バッチ処理に、EJBを使う意義が今ひとつ見えてきませんよね。中間ファイルを残していれば、こけたときにそのステップから流せばいいんですから(懐かしい)、何もいちいちEJBでトランザクションを起こしてRDBMSにインサート、アップデートする必要があるとは思えません。それより、64bitVMでヒープを思いっきり大きくとり、メモリ上でソート、マージなど各種データ操作を極力行い、ディスクアクセスを減らすほうがよっぽど効果的だと思いますが。マスタのデータ長を500バイトだとしても、1000万件で5GBですよね。ソートの一時領域とか考えても、今の水準だったら、余裕でメモリ上に展開できるはずです。

      親コメント
    • by Anonymous Coward on 2003年07月30日 7時57分 (#368388)
      うーん、勘定系にLinuxは元よりRACを使うのは危険すぎると思うけど。

      RACは確かに投資に対して最大限の性能を出すかもしれないけど、
      そもそも実績がまだまだ少ないこと、
      そして、障害時に性能がダウン(2台稼動なら50%)することがネック。
      勘定系のように稼働中のトランザクション数が常に多く、
      かつ性能がダウンすることがイコールQueueが増加する(タイムアウトできない)システムの場合、
      HAの方が投資は多くなるけど、障害時の安定稼動に繋がるんだけどね。

      1台ダウン→もう1台にトランザクションが殺到→もう1台もそのままダウン
      と言うシナリオを考えると、RACは怖くて使えないね。
      HAならダウンしても同じ性能なので、
      切り替えによるオーバーフローは考慮しなくて良いし、実績もある。
      新技術だから優れているわけではなくて、
      その技術を適材適所に配分することがSIerの腕の見せ所だと思うけど。
      #だからこそCOBOLが未だに残っているわけで。

      つか、勘定系ではなく基幹系に導入では?
      勘定系と基幹系は全然別物だと思うけど…。
      親コメント
  • ちょっと疑問に思う (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2003年07月29日 16時54分 (#367949)
    > 適材適所が加速される 部門より

    はたしてLinuxを銀行の基幹システムに利用する事が適材適所なのかはどうかは「?」でしょう。それを管理する人材については、適材適所におかれることが望まれますが、Linuxを採用する事についてはとても実験的なことではないかと思います。

    # こんなこと公表しちゃっていいのかしらぁん
  • by take0m (4948) on 2003年07月29日 22時49分 (#368199) 日記
    1、
    Linuxが動くハードウェアで勘定系が動かせるようになったのか?
    egeneraのBladeFrameってどんなもんなんだろうなぁ・・・

    2、
    9月サービスインって間に合うの?
  • よくみると、発注側のUFJはプレスリリースが出てないのであまり注目されていないようですね。株価を見ても、CTCは28日に80円上げたけどUFJはこの件については反応なし。

    しかも、トラブった時にそれを発表して泥をかぶるのは銀行側... スプレッドのネタにした人はいるんかな?

typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...