waneの日記： 容量が足りないんだってさ 16
日記 by
wane
全銀ネットの不具合は「必要な容量が確保できない取引が発生した」らしい。
何の容量か書かれてないけどHDDじゃないよねきっと。
OSが32ビットから64ビットに変更されたっていうから、C言語で組まれたソースをコンパイルするときに設定しくじったんだろな。しらんけど。
自分が更改を担当したシステムでは単体テストから始まって結合テストやら負荷テストやら一通りやった。その時別端末からメモリのモニタリングもしてメモリリークとかメモリ容量が足りなくなったりしないよねって確認もしてた。
20年以上前に書かれたソースをコンパイルし直して最新とは言わないけど互換チェックをした上での新しいOSと新しいハードに載せるんだから、流れてくるはずの全パターンのデータを流して負荷テストなんてのもやってた。
当時は「そこまで要るの？」と思ってたけど、今回の障害を見てなるほどなと腑に落ちた。
機器の老朽化に対する更改だけなら全く同じバージョンのOSやらアプリやらミドルやらで、ハードも同等品をもってくればいいんだろうけどそれでも一通りテストしておかないとどこかの些細な設定ミスであっけなくコケるんだろな。
そもそも基幹アプリが書かれた当時のハードウェアからすると今の最小構成のサーバでも性能もメモリもHDDも当時を大きく上回る構成にしかできないのに、そこで何が足りなくなるのかというと、やっぱり32ビットから64ビットに変えたトコなんだろうなーと。
11月末までには原因分析やらが出てくるらしいのでそれ見てみたい。
まーもう二度と金融の仕事はしないんだけれども、単なる興味で。
■追記
接続図が載ってたのでメモがてら追記。
意外に (スコア:1)
現場の堪忍袋の容量だったりして
Re: (スコア:0)
カンニングすればOK
OSは何だろう (スコア:1)
OSを32ビット版から64ビット版に移行したらしいけど、現時点で32ビット版のサポートがあるOSは何だろう。
Windows Server 2008のESUは(Azure以外の場合)終わっているので、RHEL6(ESL付)だろうか。
JAVA VMの設定ミスとか？ (スコア:0)
OSとアプリ変えたときに、セットアップマニュアルからJAVA VMのメモリ周りの設定変更(容量拡大)が抜け落ちてて、
最初期バージョンのメモリ容量のまま動かしたとか……
「原因：セットアップマニュアルを適時更新していなかった。」みたいな。
Re: (スコア:0)
全銀ってJavaなんて使ってるの？
Re: (スコア:0)
うん。
既に使ってるかは不明だけど、移行予定。
全銀ネットが全銀システムのオープン化を表明、開発言語はCOBOLからJavaに [nikkei.com]
Re: (スコア:0)
でもそれって勘定系の話しでは？
RCとかは違うのかなと。
Re: (スコア:0)
RCはオープン系(次期全銀システム基本方針 図表3 [zengin-net.jp](リンク元 [zengin-net.jp]))で、
周辺システムから順次移行してくのは良くあるパターンかと。
という事でJavaを使ってる可能性はとても高いと推察はしてた。
昨日の記者会見でCとJavaって開示された。 [youtu.be]
日経XTECHに詳報があった (スコア:0)
全銀システム障害の原因判明、メモリー不足でインデックステーブルが不正確な状態に [nikkei.com]
メモリー不足に起因し、金融機関名などを格納したインデックステーブルに不正な値が紛れ込んだ。
インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になったという。
ディスク上のデータからインデックステーブルを作成する処理中に、
ワークメモリかスタックか何か不明だけど、メモリ不足で強制終了したから、
インデックステーブルが不完全な状態で展開されてシステムが止まったと。
このインデックステーブルに手数料計算用のパーセンテージとかも含まれていて、
その辺の計算をするときにうっかり空間計算量がO(n^2)みたいなロジックで極端に膨れたか、
実は再帰で余計なものも一緒に積んでスタック不足でコケたとかですかね。
Re:日経XTECHに詳報があった (スコア:2)
あくまで予想なのだけど
OSが32bitから64bitへ変更
→コンパイラも当然64bit版になる
→古いCのソースを64bit版でコンパイルして使用
→int型やchar型のバイト数が変わってメモリの領域を確保するのに計算が狂って確保した領域からメモリがあふれた・・・
テストの時はギリあふれない程度の小さいデータでテストしてた・・・
とかじゃないかなーとか思ったりする。
しらんけど。
どんなレポートが出てくるのか楽しみ←不謹慎かも
Re: (スコア:0)
テストでそれなりのサイズにしていても、日本信号の自動改札機が死んだ [wikipedia.org]みたいなパターンだと特定の倍数で起きるから。
mallocが8バイト単位にそろえるのでアクセス違反してても余計に領域を確保してる範囲に収まれば死なない。
けど、特定倍の時にはみ出てメモリアクセス違反で死亡とかね。
Re: (スコア:0)
sizeof(*uint32_t)をsizeof(uint32_t)としてたみたいな奴か……
容量が足りないと言うと (スコア:0)
8月のトヨタ自動車の生産指示システム障害、原因はディスク容量不足 [hardware.srad.jp]を
思い出すけど今回の話はディスク容量ではないのね。
構造体内でポインタサイズが変わっているのに固定値で
参照していたところでもあったのかな?
# まあCで書いてたわけではないだろうが…
Re:容量が足りないと言うと (スコア:2)
「金融関係で無印Ｃで書いたプログラムなんて使ってるわけねーだろ」
・・・そう考えてた時期が私にもありました・・・（遠い目）
3連休明けの五十日で (スコア:0)
たまりにたまったものを一斉に処理したので想定以上のトランザクションが発生したってことなのかな。
わざわざ不運が重なるようなリリースをしてしまったのだ！