【IT】メインフレームから全面移行--楽天カードのクレジットカード業務 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
楽天カードは、メインフレームで稼働していたクレジットカード業務の基幹システムを、オラクルのプラットフォーム上へと全面刷新し、本格稼動を開始したと発表した。事業の拡大スピードに合わせた柔軟な運用と、長期的に会員が安心してクレジットカードを利用できる環境を整えた。
従来は月に数時間、楽天カード会員専用オンラインサービス「楽天e-NAVI」で一時的なサービスの利用制限が発生していたが、刷新により定期メンテナンスが不要となった。
新基幹システムでは、従来のメインフレームでは難しかった複数人による同時のプログラム編集が可能になった。周辺システムも含め、プラットフォームやアーキテクチャ、開発言語を統一することで、生産性を飛躍的に高められたという。
今回、楽天カードは自社管理のデータセンター内に「Oracle Cloud」環境を配置するサービス「Oracle Cloud at Customer」を採用。特定の処理を実施する際の一時的な負荷増大時にも柔軟な対応が可能となり、急増する楽天カードの会員数と取引件数に対する処理能力を強化し、会員と加盟店に、長期的により安定した取引環境を提供する。
楽天カードは、楽天グループ企業としてクレジットカード事業を開始した2005年以降、基幹システムをメインフレーム上で運用していた。基幹システムの全面刷新プロジェクトは2014年から始まり、今回の本格稼動に至った。
機器の持つ性能面の限界から、あらゆる負荷への迅速な対応が困難になりつつあるという課題を抱えていた。また、長年の運用に伴うプログラムの複雑化とCOBOLの技術者不足により、開発面と保守面での制約があったという。
これらの課題を解決するため、技術基盤として「Oracle Exalogic Elastic Cloud」と「Oracle Exadata Database Machine」を新たに導入した。
また、Javaベースのアプリケーションへの移行を決めた。このアプリケーションの変換には、ジェイ・クリエイションの移行サービス「VENUSR」を活用。Javaによるシステム開発の標準仕様「Java Platform, Enterprise Edition」を採用している。
さらに、急な変更を繰り返す状況においてもプロダクトの品質を確保するため、自動テスト環境を整備。処理性能を落とさない工夫として、Clouderaの支援を受け「Apache Spark」を導入し、バッチの分散処理を平易に実現できるようにしたとのこと。
結果として、バッチ処理の平均速度を従来よりも2倍以上速めることができるようになり、持続性の高い基幹システムの運用が可能になったと強調している。
https://japan.zdnet.com/article/35104289/ わざわざ自前のデータセンターとかどんだけ脳みそコンクリートなの
awｓじゃあだめなんですか AWSは年に2回程度の大規模障害起こしてるから駄目。 EC事業やってる会社が同じEC事業やってるアマゾンのクラウド使うのは流石にダメだろ…
自社のネットインフラはアマゾンより劣ってますって言うようなもんじゃん… 楽天つーても古くからある会社を買収してるからメインフレームくらい使っててもおかしくない
鹿児島信販(1963創業)
↓
国内信販(新)←国内信販(旧)
↓
楽天KC→楽天カード(カード事業を楽天に売却)
↓
KCカード→YJカード(カード事業をソフトバンクに売却)
↓
Jトラストカード COBOLとか馬鹿にしてたけど、メインフレームに載ったときの安定性は流石たったな。
COBOLが廃れた理由が技術者の高齢化ってのが時代を感じさせるね。
若い技術者、新しい環境で前と同じ安定性は出せるのだろうか。 お金数えるのにメインフレーム使わない方がこわいよ、お前、シロートだろ、知ったかみっともない メインフレームって３６０ってやつ？？？
ＡＲＭでスパコン作ろうって言ってる時代にそんなのに執着してる
すべての理由は古いプログラムの流用が必要だったから？？？
そもそもなんでコボルなの？他の言語に比べて金融用の命令？があったとか？ リボ払い専用カード。
カード破綻予備軍が持つカード。
移行言うても、プログラムの分岐とか画面遷移をそのままジャバでコーディングするという糞プロジェクトも多いぞ
言語が代わっても負の遺産としてはそのまま
発注者や元請けがバカすぎて付き合えん >>41
少なくともコボルでプログラム組んだことない奴が何も知らずに批判してるのは滑稽だと思うぞ COBOLとメインフレームの組みあわせやりたい若い奴いたら教えて欲しいわ
爺の戯言に付き合ってる場合じゃない
本当にずっと続くものなら20代入ってくる、こないのはそういう事だから老害はいい加減諦めろ IBMでも今はバッチをJAVAでやるって聞いたけど。
メインフレームの良いところは、安定性と単純なスペックでは無いトータルとしての性能。 > COBOLの技術者不足により、
ごろごろ居るはずだが
みんな業界から卒業しちまったか… Oracleて、、、
がっちりベンダーロックインされてますやん。 楽天カード入会して７０００ポイント貰い
目一杯ポイント使った後にカードは放置！ >>51
COBOL技術者の大半は管理職の年齢となり、現役とはほど遠い
もう、COBOLが担っている基幹業務プログラムを改修するだけの技術も度胸も無いよ じゃあアダルトサイトの「抜き天市場」もメインフレームから移行したの？ >>10
でも未だにコボラー募集多いんだよな
ボロ儲けできなくてもニッチなジャンルになってる >>35
AWSはインスタンス消失、回復失敗のイベントが恐ろしすぎるｗ >>1
反日ワイドショーはすべて同じ会社が作ってた！！ 泉放送制作
TBS
サンデーモーニング
あさチャン！
ビビット
ひるおび!
フジ
とくダネ!
直撃liveグッディ
ノンストップ！
朝日
モーニングショー
スーパーJチャンネル
http://www.izumitvp.co.jp/broadcast
ほとんどのワイドショーをこの会社が制作
TV局をまたいで横断的に
民進のナントカ議員が言っていた
『世論はワイドショーが作るんだ』
その原因がこの会社
サンデーモーニングのプロデューサー名
金富隆 >>54
度胸が原因なら楽だなあ
業務命令書でもう一度思い出させてやればいい
猫も杓子もわけのわからない理不尽ジャングルに率先して飛び込んで行ってた時の事を COBOLエンジニアはたくさんいるよ
むしろ行き場がない >>63
プログラムに集中して家族を捨てる度胸も必要だよ 何をしても楽天は日本のガン！！
破産にしなければならない!！！ 今まで居抜き物件で商売していたが
設備更新の時期になったってこと。 >>64
COBOLプログラムを改修する必要性はあるはずだが、発注側が改修から逃げているでしょ 楽天は日立のメインフレームだったか？日立のメインフレーム開発の撤退に合わせたのかな？
スクリプト言語信者界隈ではJavaは衰退するとか言う人がいたと思うけど、まだまだ繁栄しそうだな
弱小からオープン化するんだろうな。
COBOL技術者はメガバン業務に持ってかれちまうんだろ。
だがオープン化は簡単じゃないぞ、
どこが請け負うか知らんが、いい加減な派遣をあてがっとくと、
どこをどう触って直したらいいかわからんような屑コードの山が積もりあがるｗ
もしかしてWindows？
新生銀行はそれで成功したんだよな。
勘定系のメインフレームは、存外、COBOL技術者不足がとどめを刺すかもな。
>>70
そりゃ信者の戯言なわけでべき論や理想論であったとしても現実論ではないわな みずほ銀行下っ端「いままでのトラブル収拾の努力は何だったんだ・・・」 >>72
>どこをどう触って直したらいいかわからんような屑コードの山が積もりあがるｗ
この一行を読んだだけで、心底ぞっとしましたｗ メインフレームの方が良さそうか気がするけど…
ORA-600 ■真相深入り！◆虎ノ門ニュース■
7/17(月) 青山繁晴・居島一平
https://youtu.be/g1O1faarpE4
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
毎週月〜金 朝８時から生放送！ LIVE放送終了後も動画で見れます♪
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
※ニコ生、フレッシュでも放送中 >>5
熟練さん、ちゃんとドキュメント残しておいて下さいよ
頭に入ってるって言われた時、かち割って中身を見てやろうかと思ってしまったじゃないか >>7
既存の実績のある業務パッケージ使ったんだろうね。
気持ちは判るよ。初めてカード業に参入するのに基幹システムも実績無しではリスクが高すぎる。 >>84
さすがに人が引退すれば滅ぶと思う。後、10年ぐらいかな。 >>7
あおぞらのシステムじゃなかったか。楽天が一から立ち上げたシステムじゃないから、その批判はちと見当違い。 >>85
俺は20代だけど銀行系の対応に駆り出されてCOBOL覚えた
チームリーダーは30代でJava世代
こうやってCOBOLの技術は延命されてるんだなと思った >>88
既存プログラムのメンテを一手に引き受けさせられると、たぶん辞めたくなるだろね >>72
Garbage in, garbage out. （クズを入れたら、クズがでてくる）の原則な >>56
IT業界のサグラダファミリアなんだからあと100年もすれば完成するよw 今、新人にCOBOLやRPG覚えさせてるよ。
オープン系はどこの誰でも知ってるけど
汎用系は教えなければならない。 同じ処理を３つのプロセッサーで処理して多数決で結果を決める
これが熱いんだよ！胸アツ メインフレームとか汎用マシンはロマンだよ。あんなもんなかなかお目にかかれない。データセンターPowerのロゴ見る度に何か嬉しくなる メインフレーム的なプログラムを入れ替えるのは大変だったろうに 迷惑メルマガの次はリボ払いの売り込みメッセージ連打の予感 メインフレームって糞ハイスペなのになんで速くなるんだ？
これDBの設計悪いだけじゃねーの >>60
そりゃ若手こないけどまだ残ってるから人は必要だろ
10代20代30代が嫌がる言語に未来などあるわけがない
COBOLだけずっとやれって言われたら大半がやめるだろう >99
「現行踏襲」ってお題目で、すべてのifとLoopをCOBOL踏襲したJavaで書いたときは、
この銀行もう終わってんなって思ったもんだわ。
例えばCOBOLおなじみの
・データの追加削除なんかは、一旦メイン画面を経由して「処理モード」なるもんを追加や削除、更新に切り替えてからじゃないと
変更できない
・画面に一覧がでねぇから、印刷され済みの「処理番号」を手元でキーにして入力する
みたいなのは、Javaアプリで なぜかそのまま完全踏襲してる糞さ。
銀行内の他のシステムではフツーにJava標準開発してて、通常のソフトウェア資産がある中で、
こんな仕組みを残す発注側の銀行内SEとその完全IT子会社、一次請けの大手ベンダーはマジで糞だった。 >>103
おまえなんのこと言ってんだ？
COBOLのことも全然わかってなさそう >>102
そこそこ大きい会社だと辞めないよ。
そんなことですぐやめるのは社会人失格だと思う。
偽装請負やってる会社とかじゃないし。
逆にお前みたいに変な志あって辞める人は
その後偽装請負やってるブラック企業へ行き着いて
後悔するんだよ、辞めたことを。 いつどこの支店のATMで通帳記帳しても、あっという間に情報を印字してくれる
メガバンクの顧客数や取引数を考えると、なんて速くて容量の大きいデータ貯蔵装置を
銀行は使ってるんだろうと素人目には感じる >>103
仕方ないと思う。
仕様書が完全じゃないから現有ソースでやるしかないから。
COBOLって変数がグローバルしかない？感じ？のところはどうしたの？
俺は半年だけCOBOL手伝ったとき「これは書き換えすげぇきつい」と思ったのが変数
あっちこっちで参照してるからグローバル変数にしないとうまく動かない。 >>108
あのさ、銀行の取引件数なんてクレジットカード会社の取引件数からしたらチリだよ >>105
昔みたいに終身雇用じゃないのにそんな事いうほうが無茶じゃない
系列の頂点で出向先があるならともかく、それ以外は自分の将来かかってるからな
1つの会社に滅私奉公する考え方をITで求めるとか狂ってるわ
COBOLやメインフレームしか触ってなくて使い場所がなくなり
中高年でいきなり営業に回されたりする奴が山ほどいるのにだ メインフレームが速いなんてもはや神話だよ
たかが文字と数字を扱う20年前に実装された
基幹処理なんてゲーミングPCの方がよっぽど速い >>113
CPU速度では、とっくに抜かされてるのなんて、誰だって知ってる
オープン系では適わないのは、周辺処理装置の充実と駆動能力、そして信頼性
目にも止まらぬ速さで出力した用紙が飛んでくレーザープリンタなんて見たことあるか？ >>81
ドキュメント残さないのはCOBOLもJavaも変わらないだろう。職場の規律の問題だよ。 >>85
俺は45歳コボラーだ。あと20年位は保守やれるぞ。
でも、三菱東京UFJ銀行がAWSとか言い始めたから、10年後にはCOBOL案件なくなってるかもね。 >>103
だって要件が誰も分からず、ソースしか残って無いんだから仕方ない。
他にやりよう有るなら教えてプリーズ。 >>116
AWSでCOBOL動かすんじゃないの？ メインフレームより後から出てきた、オフコン、ミニコン等は絶滅したけど、メインフレームは現在も使われているよね
パソコンが絶滅しても使われていたりしてｗ >>122
メインフレームって主にどこに生息してるの？？
船堀のデータセンターとかにいるの？？ 現行アプリを、AWS上のOpenCOBOLに移植します！ >>123
古い企業なら、メインフレームを設置出来る自前のマシンルームがあるだろ。 >>103
その銀行のSEは賢い
それがオープン系に移行する、たった一つの冴えたやり方だ
勘定系の仕様を一から洗いなおしてフルスクラッチ、なんてことしたら、そのプロジェクトはみずほへの道だ おおぞらオリの大昔のシステムをそのまんま使用していただけ ■ このスレッドは過去ログ倉庫に格納されています
