このスレッドはアーカイブ化された過去ログです。

全銀ネット障害、難航する原因究明 「メモリー不足とは言い切れない」...考えられる原因を書いてくアーカイブ

1.
ユーザー
2WVZM
現在、記者会見等の報道発表で分かっているのは下記の通り。


10月18日、全銀システムを運営する全銀ネットが、障害発生後として初となる対面での記者会見を開いた。

その会見内容から今、見えてきた全銀ネット障害の裏側を5つのポイントでまとめる。

1. 何が原因だったのか
全銀システムは、サーバーなどの耐用年数を踏まえて設備の更新をしている。今回は中継コンピューター「RC」が更新予定で、「RC17」(2017年更改)から「RC23」にアップデートする予定となっていた。

10月7~9日の3連休にシステムの更改を実施し、連休明けの10日の午前8時30分から稼働をはじめたところ、刷新したRCが電文を送受信しなくなった。2日間にわたる復旧作業を経て、苦肉の策でプログラムの一部を簡易版で作り直し、どうにか暫定復旧させた ── というのが、先週のトラブルのあらましだ。

記者会見2日前の10月16日には「メモリー不足が原因」とする報道が一部メディアで報じられ始めた。記者会見では、この「メモリー問題」も含めて、ようやく原因に迫る情報が少しずつ見えてきた。

現時点で判明しているのは、「内国為替制度運営費(いわゆる銀行間手数料)」を処理するプログラムに問題があったというものだ。

内国為替制度運営費は、振込などの種目によって異なるため、送受信される電文にはこの手数料も記載される。手法として「金融機関があらかじめ電文に金額を入力して送信する」方法と、「あらかじめRCに設定されたテーブルを参照してRCが電文に金額を入力する」という方法の2種類がある。

今回の障害では、後者のRCに設定されたテーブルを参照する方法を選択していた10金融機関で問題が発生した。

RCがテーブルを参照する処理でエラーが発生してRCが異常終了するという状態に陥った。

ただ、なぜエラーが発生するようになったか、最終的な原因は現時点でも調査中で、問題の核心は判然としない。

RCで内国為替制度運営費を入力・チェックするプログラムは、事前に用意された「金融機関名テーブル」とそれを読み出すための「インデックステーブル」を記憶領域上に展開して読み込むが、この2つのテーブルのうち、インデックステーブルの方で破損が生じていたことまでは、全銀ネット側は突き止めたという。

これによって読み込みでエラーが発生したが、「なぜインデックスファイルが破損したか」がわからない、と全銀ネットは説明する。

このファイル自体は、RC内でプログラムによって事前に作成される仕組みだ。毎朝午前4時ごろにRCを立ち上げる際に、都度展開して読み込んでいる。つまり、この「事前に作成する」段階に不具合が潜んでいた可能性がある。

基本的にRC17とRC23で作成するプログラムや手順は変わっていないというが、OSの64ビット化、仮想化といったRC自体の仕組みに変更があり、そうした部分で不具合が生じた可能性が考えられる。

前出のとおり、一部報道では「メモリー不足」が原因だと指摘されていた。

だが、今回の会見で全銀ネット側は肯定も否定もせず、「メモリー自体が不足していたかは検証の重要なポイントだが、現時点で確定的なことは言えない」(事務局長兼業務部長・小林健一氏)と述べるにとどまっている。


これらの情報をもとに原因を推察してみよう。
11
すべて
|
最新の50件
2.
ユーザー
EHQNs
やっぱりバカジャップにITは早すぎたみたいだね(笑)
3.
ユーザー
2WVZM
記者の書いてある内容が正しいのだと仮定すると、おそらくこんな感じ?

「RC」=リレーコンピュータの主記憶装置に銀行名、銀行間手数料等の情報のファイルがある。
それをプログラムで高速に処理する為にメモリーに呼び出す。=配列に格納処理する?

この格納する時に上手くいかず、つまづいて配列に取り込めなかった?
その上手く出来上がってない配列に参照をかけてしまったのでエラーが起きたということなのだろうか。
4.
ユーザー
2WVZM
ではなぜ失敗したのか。言語はJavaだと言うのは記者会見の中でも出ていた。

Javaについては専門では無いのでよく知らんので、ここからは推察だけど。

原因として考えられそうなのはやはり、32bitから64bit化したことの影響と考えられる。
その中でも影響でそうなのは、数値型の取り扱いかなと思われる。

つまり、銀行間手数料の部分は小数点が含まれる数値だったとして、それならfloat型で定義してたのかなと推察。
32bitだと float a=1.0
64bitだと float a=1.0f

javaはこの違いあるの?あるとするならここの違いの可能性?
64bitで小数点扱うならdouble型に変更してるかも知れんけど。


5.
ユーザー
2WVZM
Javaの専門家の意見求む。
6.
ユーザー
2WVZM
>>2
それは否定出来ないかも知れない。
それこそ20年前までパソコン使える人=バソコンオタクって軽蔑する文化があったくらいだから。
今となってはパソコンも使えないってなると逆に「仕事に支障が」ってなるらしい。
7.
ユーザー
gC7SS
暫定版で凌いでるって、またすぐに停止しそう
8.
ユーザー
EY4Kc
電源コードは確認した?
9.
ユーザー
2WVZM
>>8
しまった!そうだな!!w
本体叩けば当日には良くなってたかも知れないww
10.
ユーザー
fhvmW
>>5
Javaとか以前の問題っで
金融系ならデシマル型で扱うので
そもそも前提が違う
11.
ユーザー
WhE6n
>>10
デシマル型はここ最近だろ
このスレッドはアーカイブ化された過去ログです。