「説明を聞けば聞くほど不穏な空気が漂ってきたよ」全銀ネットの障害、原因説明の会見で謎がさらに深まった模様

そうは、い観世音菩薩＠GPT @iruka3

おおよそ、メモリー不足とはかけ離れた内容だな。 twitter.com/j17sf/status/1…

J @j17sf

今回の全銀システムの原因ですが、赤丸のインデックスが毎日RCが立ち上がるたびに作成されるわけですが、今回はメインメモリにコピーされる前の段階、つまりテーブル作成段階でデータがすでに壊れていたという話 pic.twitter.com/yygLy007du

2023-10-18 18:27:57

ｍａｓａ @strike_masa

メモリ破壊云々の件、用意していたテーブルのデータ長が誤っており、ロードした際にRCのテーブルを破壊して、結果的にRCのテーブルが破壊され不正となった、のかと想像した。 環境構築時に作成したデータが間違いだけでRCの機能が立ち行かなくなるほどのエラーにはならない気がする。 twitter.com/j17sf/status/1…

Lyiase @lyiase

全銀の障害、これだけだと最終的に何のエラーが発生したかが分からないから外部からの推定は出来ないけど、もし「電文長エラー」なら最有力は「桁あふれ」じゃないかな。 単純に設定した金額が大きかった、Javaのコンパイルバージョンが変わって暗黙変換の仕様が変わって悪さをしたとか。 twitter.com/j17sf/status/1…

晴姫(はるひ)_🍊公式技術垢 @Haruhi40_tech

なんでこんなアーキテクチャーになってるのか問い詰めたい気持ち。 赤丸が毎回立ち上がるのではなくて、赤丸が編集可能なマスターでこれをRCにデプロイして使っていると。 RC起動時に赤丸を読み込んでRCの当該テーブルが作成されるが何らかの理由でデータに異常があった。ということであれば、 赤丸を不用意に人がいじって壊したから。が原因じゃないの？

犬 @toshi_miura

テーブル全体が壊れるってどういうデータ構造なんだろう、、特定のレコードが壊れる、一部の電文がエラーになるっていうならイメージできるが、 それでその方式とってるやつが全面的にこけるっていまいちイメージしにくい。 twitter.com/j17sf/status/1…

裏技君 @urawazakun

あー…ガチガチなテーブル参照処理で構築してたらテーブルのメモリが32bitから64bitに改変されてーって感じかな… twitter.com/j17sf/status/1…

テン @Hak0K

テーブル作成のプログラムがちゃんと動いてるならどうなってるんだろう。 テストデータは小さくて負荷が測りきれなかった？でもみずほがやらかしたみたいに今までの処理をみてメモリは決めてるだろうしなあ twitter.com/j17sf/status/1…

そのち @Sonoti21

50年で初の大規模障害って、てっきりメインフレームかと思ったら中継機なんだね あれの信頼度ってやっぱ凄いんだな…… twitter.com/j17sf/status/1…

あかなめ @super_akaname

「テーブル作成段階でデータがすでに壊れていた」……まさか、Excelで元データを管理？　……まさか、そんなことはないよね……。 twitter.com/j17sf/status/1…

明浦@あきほん♪ @PrograMaroon

こうやって図示されてると単純に見えても、その大元になるデータ量がデカいシステムだと凄い大変なんだなってなる。 …っても、人間の記憶というか認知の仕組みだってOSI参照モデルに喩えるとしたら滅茶苦茶に複雑な訳だし、規模が大きいほど原因特定も直すのも難しいよな感ある。 twitter.com/j17sf/status/1…

Kinya Usuda @usuda

全銀システム、謎深まる

J @j17sf

ポルナレフの気分を味わった会見でした twitter.com/usuda/status/1…

SKMT/坂本英樹 @sakamotoh

全銀システムでインデックステーブル作成段階で壊れてたとなると、不正なデータの処理に問題がありテストが漏れたんでしょうか？ twitter.com/j17sf/status/1…

J @j17sf

異常終了の理由はテーブルが壊れていたからということですが、テーブル自体が壊れていた点については実はテストから漏れていた可能性が指摘されています twitter.com/sakamotoh/stat…

TSUMOTO Akihiro @Hir00mi

@j17sf 会見を見聞きした印象だとRDB使っていない雰囲気もありましたね

J @j17sf

@Hir00mi あそこでRDBと明言するとベンダーと製品が特定できるので、口を濁したのだと思います。誘導尋問的に聞いてみましたが、ちゃんと回答を避けていた印象です

TSUMOTO Akihiro @Hir00mi

@j17sf RCは2035に終了予定とのことなので某UNIXなのだと想像していますが、 2〜30年前のミニコンやUNIX上のCアプリだと、RDB使わずフラットファイルやインデックス付き固定or可変長ファイルを共有メモリ展開するのは、普通の設計でした。 過去の設計を踏襲しているとDBMSを使っていない可能性もあるかなと

J @j17sf

@Hir00mi Sの可能性もありますが、32bitの話が出ていたのでLというかRというかなのかなと考えています。自分も明言を避けますが、当該ベンダーの某ミドルウェアのバグなんじゃないかという話が某所であって、だとすると原因特定が難航しているのも頷ける…というのが現時点での自分の考えです

TSUMOTO Akihiro @Hir00mi

@j17sf はい、もちろんそれもあり得ると思います。 ちなみに S でも 2017 サービスイン(選定が2014くらい？)だと32bitを選択した可能性もあります。 少なくともJavaは32bit版の可能性が高いです

J @j17sf

@Hir00mi 2010年代前半だとSでも32bitの可能性あったわけですね。今回のまとめはいったん事実中心にして、原因究明後の報告を待つしかないのかな…という気がしています。テーブル作成のプログラム自体は17と23で一緒らしいので、再現から各種テストで原因割り出すしかなさそうなので

TSUMOTO Akihiro @Hir00mi

@kis はい、そのようでした。 不正データ自体でエラーになったか、コードか単価か率かフラグが違う値になっていて計算結果間違いでチェックエラーかは曖昧でしたが。 給料振込などのバルク処理との発言もあったので、一部被仕向先金融機関がだめても取引全体でフェイルするんだろうなと

Daisuke Iizuka @diizuka

@j17sf メインフレームだとKVSとしてISAM(アイサム)を使う事があります。RCでもKVSを使う可能性はあると思います。 で、ISAMを使ったアプリ側で排他処理にバグがあって同時書込みするとindexが壊れる事があります。これかもしれません。 ただし、書き込みは成功してるようなので見当違いかもしれません。

J @j17sf

@diizuka 当該テーブル部分自体はそれほど複雑な仕組みではないような気がするんですよね。しかも17と23でプログラム自体は一緒とのことで、差分は動作するプラットフォームの部分でしかない。なので、再現と原因究明はかなり時間かかる事案だと考えています（おそらくロジックではない大元部分のバグ）

J @j17sf

いま書いている記事ではベンダー名に触れていませんが、もともとベンダーを叩く意図はなくて、シンプルに「原因究明の難しさ」「判断は妥当だったか」の部分に焦点があると考えているので、今回はそのあたりで短めにまとめます

ゆきうさぎ＠フリーのシステム屋 @__snow_rabbit__

全銀の会見をある程度みたので感想 メモリ不足ときいていたが 電文を処理が参照テーブルってインメモリデータベース（だと思うけど）そこのコピー元のマスタテーブルに問題があった 全パターンの電文を網羅出来ればバグは防げただろうがサンプリングして行っていたためテストケースが漏れた