UFJ銀行が基幹システムにLinux導入 172
ストーリー by wakatono
適材適所が加速される 部門より
適材適所が加速される 部門より
Futaro 曰く、 " 毎日のこの記事 によりますと、UFJ銀行が基幹システムにRedHat Linuxを採用した、ということです。いよいよ日本の銀行もこういう時代になってきたのですね。しかしながら、メインフレームで余った人たちはこれからどうするんでしょうか?"
構成は、Egenera + Redhat + Oracle9i RAC というもの。EgeneraのプレスリリースとCTCのプレスリリースが出ている。なお、稼動開始は今年の9月だとか。
今頃? (スコア:5, 興味深い)
既に30社はLinuxでシステム組んで納品してますよ、
小規模なのは、LANのみで20クライアント程度のシステムから
うちの中で比較的大きいシステムは、250支店でとか色々ですけど。
特に問題も無く、以前はACOS2で数億円かけていたシステムが
Linuxを使う事で 数千万円で、しかも、今までのシステムよりも
高速になったとウケは抜群でした。
意識としてはLinuxが基幹業務に!ってのは既に当然の話であって
むしろ、Windows2003Serverで!って方が衝撃的だよね。(笑)
Re:今頃? (スコア:2)
でも今回のはACOS6かケチってもACOS4の上位クラスを使うような規模では?
ACOS2の代替なら「Linux当然」とは思いますが。
(IDL2,COBOL/S,RIQS,ADBS,VSAS,CPL,HPL...今となっては忘却の彼方)
Re:今頃? (スコア:1)
意図するところが良く分かりませんが、まだリリースされて間も
ないWindows 2003 Serverだから衝撃的という意味なんでしょうか。
一般的にLinuxよりもWindowsの方が衝撃的という意味なら、それは
逆ではありませんか? Windowsだったら先例もあるわけだし、ここ
まで話題になるとは思えません。この間の政府の給与管理システム
の件も同様でしょう。
Re:今頃? (スコア:1)
なんて、リソースの面から言えばどうでもいいような小さな問題
だと思います。それにIAサーバの最上位機になると、むしろ
LinuxよりもWindowsの方がうまくCPUのリソース(SMP)を扱えて
いて、Linuxの方がCPUパワーを無駄にしていると言えなくもない。
今までのシステムよりも 高速になった (スコア:1)
Linuxもだけど (スコア:2, 参考になる)
大規模Javaは甘くない・UFJ銀行 目指すは1日1000万件のバッチ処理
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030703/1/ [nikkeibp.co.jp]
え~、Javaで~?マジで~?と問い詰めたくなるような。
--------------------
/* SHADOWFIRE */
Re:Linuxもだけど (スコア:2, 参考になる)
データの処理としてのバッチ、それはそれで結構。
だがしかし、その前にデータを集める、送るという前段階、後処理について。
全銀協標準通信プロトコル(BASIC手順)の最大9600bpsよりはましになったとはいえ、それを元にした全銀協標準通信プロトコル(TCP/IP手順)では通信に時間がかかってしょうがない。しかも多くの銀行は64Kどころか9600bpsのまま。データ圧縮したとしてもたかが知れてる。そんなんだから大量データはカートリッジテープでやり取りをしつづけねばならない。その結果、必然的にカートリッジテープの運送にかかる時間、料金というコストが下がらない。これでは口座振替を利用する企業、ひては消費者へのサービスには繋がりにくい。全銀協ってダメダメといつも思う。
新たなプロトコルとか、通信環境の整備が必要かと。
とりあえず (スコア:1)
出てくるのは避けてもらいたいですね。
いや・・当然その辺りはBigDecimalのみを使うんだとは
思うけど、実はそれだと処理速度の問題で一部Doubleで・・
なんてのがあったりするかもなぁ・・と。
もちろんちゃんと仕様が明確になっていても意外に・・ってのが・・。
Re:Linuxもだけど (スコア:2, 参考になる)
別ACですが性能と安全性を天秤にかけてCOBOLですかね.
その特集記事に名前の上がっているシステムの一つの構築に携わりましたが, クライアントはVB+Java, オンライン系フロントエンドはJava, バッチ系はCOBOLで組んであります. Cによる勘定系開発にもかかわったのですが, かなりのスリルが味わえますよ.
Javaはハードの性能に余裕が有れば, ガーベージコレクションによるメモリ管理のおかげで低レベルのプログラマでも破滅的なコードを書きにくいという点で, 悪い選択では無いと思います. しかし逆にこのガーベージコレクションが原因で性能が極端に低下するとか, jdbcがネックとなって入出力性能が出ないとか(それを回避するために, やたら複雑なSQLを書いてDBサーバ側に処理を任せるとか)の罠があるので, 現時点では(特にエンタープライズ規模でのJavaシステム構築経験が無い場合には)大規模バッチ処理では使わない方が吉だと思います.
# 知っている人だと名前を特定されそうなのでAC
Re:Linuxもだけど (スコア:1)
#最近は自明な場合以外はわざわざ変な演算記号を使わなくていいじゃんと思ったりしますがID
それよりも (スコア:1)
COBOL on Linux (スコア:2, 興味深い)
そりゃもちろん、メインフレームのアプリをLinuxに移植する作業をさせられるんですよ。
Linux用のCOBOL開発環境 [microfocus.co.jp]だってあるんだしさ。
Re:COBOL on Linux (スコア:1)
生き延びそうですね・・・・・
しかしredhatか・・・・・
確かredhatのサポートって結構短いと聞いていますが
大丈夫なのかな・・・・・
# マイナーチェンジやバグパッチはともかく,
# メジャーバージョンアップはそう簡単には出来ないはずだけど・・・
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA
Re:COBOL on Linux (スコア:2, 参考になる)
こういった環境で
通常する必要があるのでしょうか?
もちろんセキュリティホール対策等のパッチは
当てると思いますが。
きちんと能力のあるSIとサポート契約すれば
別にバージョン古くともサポートしてくれる
と思いますよ。 それこそがLinuxのメリット
でしょう?
Re:COBOL on Linux (スコア:1)
アップデートはいいとして機能や実装の詳細が変化してしまう
ようなものはしないようにすると思います(その意味では独自にソースをいじれるLinuxを選んだのはとても正解な気が致します)。
仮にメジャーバージョンアップする事があるとして、それは今回の”次”の本格的なシステム構築時になるのでは無いでしょうか。
その時もLinuxが選ばれるかどうかは神のみぞ知る、ですね。
よーするにコストダウンなんでしょうけどシステム移植する人は
死ねますね。ご愁傷様です。あー。
Re:COBOL on Linux (スコア:1)
@大阪なヒト
うちにきたあまった人 (スコア:1, 興味深い)
最近、メインフレームであまった人と一緒に働いています。
Windowsの基本操作をバカにして覚えてくれず作業がのろのろで、
(ファイルの名前返るのに数分かかる、とか)
自分でつくったバグをみてまずコンパイラを疑う
テキストエディタの使い方がよく分かっていない
など非常に使い物になりません。
たまたまアレゲな人なのかもしれませんが
こんな人はあまらせてほしくないなぁと切に願います。
謙虚な心を忘れずにAC
異論有り (スコア:1)
--- (´-`)。oO(平和な日常は私を鈍くする) ---
リンク先 (スコア:2, 参考になる)
LinuxよりもRACのほうがポイント? (スコア:2, 興味深い)
個人的には、「少なくともOracle RACを勘定系で動かせる程度にはLinuxは安定している」というOracleの判断なのかな、と思います。ま、RedHatというよりOracleの手腕に期待かな。
Re:LinuxよりもRACのほうがポイント? (スコア:2, 興味深い)
あと、個人的にはJRockIt on Linuxで行く点に注目してます。サポートの観点からはベンダーを揃えるのは正解だと思います。しかし、実績という観点では、JRockItも買収前から考えれば結構長いですから安定しているのかもしれませんが、ユーザーベースから考えれば圧倒的にSunJDKの事例が多いので、果たしてJRockItが十分枯れているのかに興味があります。
#Sun JDK+Weblogicだと、未だにHotSpot Internal Errorに悩まされることがあるので...
でも、バッチ処理に、EJBを使う意義が今ひとつ見えてきませんよね。中間ファイルを残していれば、こけたときにそのステップから流せばいいんですから(懐かしい)、何もいちいちEJBでトランザクションを起こしてRDBMSにインサート、アップデートする必要があるとは思えません。それより、64bitVMでヒープを思いっきり大きくとり、メモリ上でソート、マージなど各種データ操作を極力行い、ディスクアクセスを減らすほうがよっぽど効果的だと思いますが。マスタのデータ長を500バイトだとしても、1000万件で5GBですよね。ソートの一時領域とか考えても、今の水準だったら、余裕でメモリ上に展開できるはずです。
Re:LinuxよりもRACのほうがポイント? (スコア:1, 参考になる)
RACは確かに投資に対して最大限の性能を出すかもしれないけど、
そもそも実績がまだまだ少ないこと、
そして、障害時に性能がダウン(2台稼動なら50%)することがネック。
勘定系のように稼働中のトランザクション数が常に多く、
かつ性能がダウンすることがイコールQueueが増加する(タイムアウトできない)システムの場合、
HAの方が投資は多くなるけど、障害時の安定稼動に繋がるんだけどね。
1台ダウン→もう1台にトランザクションが殺到→もう1台もそのままダウン
と言うシナリオを考えると、RACは怖くて使えないね。
HAならダウンしても同じ性能なので、
切り替えによるオーバーフローは考慮しなくて良いし、実績もある。
新技術だから優れているわけではなくて、
その技術を適材適所に配分することがSIerの腕の見せ所だと思うけど。
#だからこそCOBOLが未だに残っているわけで。
つか、勘定系ではなく基幹系に導入では?
勘定系と基幹系は全然別物だと思うけど…。
Re:LinuxよりもRACのほうがポイント? (スコア:1)
いやいやそうでなくて。
RACだと1ノード障害=縮退 とならざるを得ないから、結局トランザクション集中で連鎖障害になっちまうんでねーの?という話かと。
それよりn:1とかn:nのHA構成にして1ノードコケても処理能力は変わらないようにした方がいいですよね。
スタンバイノードは常時は遊んじゃうけど仕方がない。
-- sun burst.
Re:LinuxよりもRACのほうがポイント? (スコア:1)
ちょっと疑問に思う (スコア:1, すばらしい洞察)
はたしてLinuxを銀行の基幹システムに利用する事が適材適所なのかはどうかは「?」でしょう。それを管理する人材については、適材適所におかれることが望まれますが、Linuxを採用する事についてはとても実験的なことではないかと思います。
# こんなこと公表しちゃっていいのかしらぁん
Re:ちょっと疑問に思う (スコア:2, 興味深い)
>>エンタープライズIAサーバとWindows Serverの
>>組み合わせはかなり将来性のあるプラットフォーム
将来性のあるプラットフォームだとは思いますが
比較的ロングタームで運用することの多い勘定系において
数年でサポートがきられるようなOSを採用するのはちょっとねぇ
と思います。
Linuxの場合、SIや納入先の意志でアップデートでき
なおかつ障害発生時にもソースから追えるわけで
そういった意味でもミッションクリティカルな場所には
Windowsよりは向いているのではないでしょうか。
またハードが進歩していると言えど、まだまだメインフレーム
の領域には遥か及ばないと思います。
そういった意味ではIBMの戦略は当たってると思うんですけれどね。
#GUIが日常的に必要とされるシーンにこそWindowsの良さが
#生きてくるのだと思います。
Re:ちょっと疑問に思う (スコア:1)
アップデートしないという選択が自分の意志で出来ないのは困ります。
安定稼働してるのに「サポート切れたからバージョンアップしましょう」ってシステム作る側も使う側もあまりやりたくないです
>あっちは更に自分のデスクトップPCと同じ方法でアップデートできちゃうしなあ。
>#操作系統が同じと言うのは運用上でも強みだよ。
この規模のシステムでは特に強みでもなんでもないと思います。
ユーザが自分でオペレーションするわけでもなし、SEが運用するわけでもない。
オペレータが手順書に従って(手順書以外のことはいっさいやらない)運用するもんだと思いますが。
-- sun burst.
Re:ちょっと疑問に思う (スコア:1)
将来どうなるか分かりませんが、いま現在だと7年程度でディスコンされるOS・処理系で構築するのはこの手の業界には辛いような気がしますが・・・(稼働させるのに2~3年位かかる・・・ものもあるのでしょうし)
こちらはその通りなんでしょうけれども。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:ちょっと疑問に思う (スコア:1, 興味深い)
>組み合わせはかなり将来性のあるプラットフォームだと思いますよ。
でっかいあそことか大変なお祭りで死者続出なプロジェクトになっちゃった
の見てるから、ちょっと賛同し難い・・・
未来は良くなると・・・信じたいけど 。
死人の友達だからAC
ポイントは (スコア:1)
Linuxが動くハードウェアで勘定系が動かせるようになったのか?
egeneraのBladeFrameってどんなもんなんだろうなぁ・・・
2、
9月サービスインって間に合うの?
自己レス (スコア:1)
あ・・・
ここはIA系でってことでひとつ・・・
Re:自己レス (スコア:1)
IA64なら動くと思います. しかもLinuxが動くハードウェアで. ただしシステムはHP-UXの上で動きますが.
# 詭弁なのでID
評価されるのはシステム屋、けなされるのは銀行 (スコア:1)
よくみると、発注側のUFJはプレスリリースが出てないのであまり注目されていないようですね。株価を見ても、CTCは28日に80円上げたけどUFJはこの件については反応なし。
しかも、トラブった時にそれを発表して泥をかぶるのは銀行側... スプレッドのネタにした人はいるんかな?
Re:基幹系って (スコア:1, 参考になる)
Re:基幹系って (スコア:1)
よく「読めない」といわれるLiberdade
Re:基幹系って (スコア:1)
情報系もJavaで、
ホームページにFlashつかってませんね?
JavaAppletを使いませんか?
#ごめんなさいx3
やっぱり、世の中のシステム構築してるSEさんたちの考え方が、
落ちないシステムを作るより冗長構成のシステムを作る方向に
行っていると考えて良いんですかね?
<ナイスな返事をいただいた方を、スラドモに指定する方針でいこうかと…恐縮ですが>
Re:基幹系って (スコア:1)
99~99.5%のアベイラビリティで良いのだったら、非クラスタ化システムでもちゃんと設計すれば実現できると思うのだが。
SEが悪いと言うより、売り上げを上げたい営業がクラスタをがんばって 売ってるだけでは?「可用性を上げるためのカスタマイズに 10人月かかるので1000万円」というより「2重化するので 1000万」のほうが客が金を出しやすいように思う。
Re:基幹系って (スコア:1)
口座振替と一口に言っても自行振替と他行振替があるんで, 対外とは別と考えた方がいいと思います. もちろん他振については対外に回さないといけないわけですが.
Re:人柱? (スコア:1)
And now for something completely different...
Re:人柱? (スコア:1)
Re:typo? (スコア:1)
詳しくは、日本MySQLユーザー会 [mysql.gr.jp]などからどうぞ。
Linux+MSSQLはあり得ないと思う。
Re:typo? (スコア:2)
Re:新生銀行は (スコア:1, 参考になる)
新生銀行は、メインフレームじゃなくて Windows ベースにしたことでコストを削減でき、24時間 ATM を手数料無料で提供できたと言ってましたね。
ネタだとは思うけど... (スコア:1)
信頼性が重要なシステムに、Oracleが動作保証していないOSを使うわけないじゃん。
# 私はBSD好き/Linux嫌いな人ですが、この件でBSD使えとの主張はさすがにできません。
なんちゃってプログラマ?
いやいや (スコア:1)
(今まで汎用的なマシンでは沖とTANDEMでしか見たことがないけど)
Re:人あまり (スコア:1)
| そういう発想が結局自分を苦しめていることが良く分かるから。
うーん、この辺は読んでる本の違いなんでしょうかね。
あじゃいるの本なんかを読むと、
・少数精鋭の方が成功する
・ドキュメント化しすぎないで、情報はコミュニケーションで共有した方がいい
てな事がかかれてます。
Re:人あまり (スコア:1, すばらしい洞察)
個人の力に頼ることとブラックボックス化を関連付けるのは間違い。
一騎当千の個人って、情報共有が苦手とか他人に手の内を明かしたがらないという傾向は実際にあるが、
本来は別個の事象なんだから、それを結びつけて否定するようなマネジメントなんてしてたら失敗するにょ。
個人の力に頼る部分はしっかりと頼り、その分、極力ブラックボックス化を防がなきゃ。
Re:人あまり (スコア:2, 参考になる)
・少数精鋭の方が成功するは真です
ただ、実際に100人越えのプロジェクトなんてのが存在する訳で、ではどうしましょうか?と言う議論を真剣にやってるだけですね。
・ドキュメント化しすぎないで、情報はコミュニケーションで共有した方がよいと言うのも限りなく真に近い
でも、人数が多いとなかなかコミュニケーションもとれないので「~については○○というドキュメントを書きましょう」的なルールをみんなで守りましょうね、という事を実践していくだけですね。コミュニケーション手段としてドキュメントを利用するといった感じでしょうか?「ドキュメント」なんて言われると形式張っていて読んでも真相がよく分からないものって感じはするかも知れませんが、定型のドキュメントであればコミュニケーションの質も上がってきます。
あと「飲みニケーションはとても大事です」とプロジェクトマネージャ研修で教わりました。そう言う場で出てきたちょっとしたネタが実はプロジェクトにとって重要な場合もあるって。なのでドキュメントを大事にすることとコミュニケーションを軽視するのとは違います。何かあればまず上司に相談できるような雰囲気も大事というのも解説を受けました。
元コメントは「属人的」なシステムの問題を言ってるのであって、ドキュメントが少ないとか人数が多いとかそう言う問題では無いと思いますよ。適宜必要なレビュー等を行ってプロジェクト内の他の人間が分かる形で開発をしている事が大事と言うことでしょう。
職業としてのプログラマ
Re:これだけコメントがあるのに (スコア:1)
(GUIの画面作るの楽だから)
(´д`;)
Re:エミュレータを使うというコトじゃないの? (スコア:1)
wild wild computing