パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

UFJ銀行が基幹システムにLinux導入」記事へのコメント

  • 皆さん勘定系に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が未だに残っているわけで。

      つか、勘定系ではなく基幹系に導入では?
      勘定系と基幹系は全然別物だと思うけど…。
      親コメント
      • HA構成で一台で捌ける程度なら、ハナからRACなんて使わないと思いますが。
        • >HA構成で一台で捌ける程度なら、ハナからRACなんて使わないと思いますが。
          いやいやそうでなくて。
          RACだと1ノード障害=縮退 とならざるを得ないから、結局トランザクション集中で連鎖障害になっちまうんでねーの?という話かと。
          それよりn:1とかn:nのHA構成にして1ノードコケても処理能力は変わらないようにした方がいいですよね。
          スタンバイノードは常時は遊んじゃうけど仕方がない。
          --
          -- sun burst.
          親コメント
          • RACだと1ノード障害=縮退 とならざるを得ないから、結局トランザクション集中で連鎖障害になっちまうんでねーの?という話かと。
            そんな余裕のない編成でRACを組むであろう根拠は?いくら何でも、数台の余裕を見越しての編成ぐらいは期待して良いと思いますね。
            親コメント
            • >そんな余裕のない編成でRACを組むであろう根拠は?
              いや、そんな設計では組まないでしょうな普通。

              >いくら何でも、数台の余裕を見越しての編成ぐらいは期待して良いと思いますね。
              そう信じたいところです。
              最低限、(余裕率を見越した必要台数+1台)でRAC組めばいい話なんで。

              で #368388 のAC氏の
              >そして、障害時に性能がダウン(2台稼動なら50%)することがネック。
              に対する #368404 のAC氏
              >HA構成で一台で捌ける程度なら、ハナからRACなんて使わないと思いますが。
              というふうに2台を1:1のHAで使うのでなくて、コストかかるけどもう1台導入して2:1のHAにすれば、2台のRACに比べて障害時の性能ダウンがない、という話かと。

              RACの信頼性は誰か識者の方お願い…。
              --
              -- sun burst.
              親コメント
              • >RACの信頼性は誰か識者の方お願い…。
                一応、検証やってる、おっちゃんが
                「やっと、お客に自身をもって勧められる」
                とは言ってたよ。

                ・・って、アンタ、パラレルサーバの提案書いっつも書いてたじゃん。って思ったけど。

                ちゃんとスケールもするみたいだし、割とまともみたいね。
              • RAC導入システム経験者だけど(Solaris版だけどね)。

                要するに、何を期待してRACを導入するかで効果が全然違う。
                (個人的な)RACの最大の利点は「セッションを引き継げる」ところ。
                HAだとダウンしたサーバに繋がっていたセッションは当然落とされるが、
                RACの場合はそのセッションをそのままもう1台が引き継いでくれる。
                つまり、アプリケーション側で障害時のセッション切れを意識しなくても、
                障害時の切り替えがスムーズに行くってことやね。

                逆にセッションが切れても良いなら普通にHAで組んだ方が
              • >何をその機能に求めているのか、その機能で何を実現したいのか、
                >これがハッキリしないとベンダに面白いように騙されますな。(w
                わかんなかったら、一番高いオプションを勧められますね。ひひひ。

                なんでもできる、魔法のプロダクトなんて無いことは
                冷静になったらわかるんですけどね・・・
          • つか、RACで1ノードこけて縮退運用になったくらいでアップアップになるシステムってのは、
            それ自体が既にどうかという気もするのですが。

            RACってHAで言うところの待機系のノードを用意することはできないんでしょうか?

            まさかそんなことはないと思うのですが。。

            要するに、障害時に待機系からリソースを回せればいいわけでしょ?
    • ORACLE の JDBC ドライバはバギーで いやなんですが。

Stay hungry, Stay foolish. -- Steven Paul Jobs

処理中...