全銀ネット障害、会見で「逆に謎深まる」…桁あふれ？某ベンダのバグ？考察合戦
https://biz-journal.jp/2023/10/post_360737.html

　※　今日は、こんな所で…。

　※　『全銀ネットはシステムの詳細を明かしていないため推測になりますが、』…。

　※　ということで、「どういうシステムを使っているのか」「どの言語を使っているのか」などの情報は、開示されていない…。

　※　よって、結局のところ、外部の人間で、「どういうシステムなのか」「どういう改修をしようとしていたのか」を、正確に把握できている人は、存在しない…、ということになる（この点で、前に、やや揶揄的な言動をしてしまったことを、反省しておく）。

　※　そういうことで、「推測合戦」「憶測合戦」になってしまっているようだ…。

　※　それでも、だいぶ分かってきて、参考になる情報も出てきている…。

　※　『原因は前述のとおり「インデックステーブル」の破損だ。』

　※　『テーブルはRC内のディスクで構築され、それを同じRC内の主記憶にコピーして展開しているが、今回はディスク内へのテーブル展開処理自体は正常終了していたものの、そのディスク内のテーブルが破損しており、そのまま主記憶にコピーされてしまったという。』
　
　※　『＜メモリ破壊云々の件、用意していたテーブルのデータ長が誤っており、ロードした際にRCのテーブルを破壊して、結果的にRCのテーブルが破壊され不正となった、のかと想像した。

環境構築時に作成したデータが間違いだけでRCの機能が立ち行かなくなるほどのエラーにはならない気がする＞』

　※　『＜もし「電文長エラー」なら最有力は「桁あふれ」じゃないかな。

単純に設定した金額が大きかった、Javaのコンパイルバージョンが変わって暗黙変換の仕様が変わって悪さをしたとか＞』

　※　『「全銀ネットはシステムの詳細を明かしていないため推測になりますが、データベースへの問い合わせを多用するシステムでは、データを使いやすい形でディスクに書き出し、あらかじめメモリ上に展開しておくことで高速化を図る場合があります。

今回の障害は、そのディスクに書き出したテーブル自体が破損していたと説明されています。』

　※　『今回『謎が深まった』のは2点あり、1つはなぜテーブルが破損していたのか、もう1つはなぜそれを事前に検出できなかったのかという点です。』

　※　「テーブル」が「破損」と聞くと、すぐさま、「データ長」の「設定間違い」が思い浮かぶ…。

　※　しかし、「初期のC言語」じゃあるまいし、最近の言語はみんな、「自動で対応」してくれる仕様になってるハズなんだが…。

　※　デニス・リッチーが「天国」で、にっこり微笑んでいるのか…。

　※　それとも、ニタニタ（悪魔的に）笑って、「それだから、コンピューターって、恐ろしいのよ。」とでも語りかけているか…。

　※　まあ、彼は、「C言語」は、「アセンブラ」に替わる「”とりあえず”使えるもの」として開発しただけで、それほどみんなが使うものになるとは、「夢にも、思っていなかった。」らしいが…。

『10～12日に発生した銀行間送金システム「全国銀行データ通信システム（全銀システム）」の障害について、運営する全国銀行資金決済ネットワーク（全銀ネット）は18日に記者会見を実施。

同システムと各金融機関のシステムを接続するリレーコンピュータ（RC）で不具合が生じた原因について、内国為替制度運営費（旧銀行間手数料）を計算する際に参照する金融機関名テーブルである「インデックステーブル」が破損していたためだと説明したが、なぜテーブルが破損したのかなど、根本的な原因は不明だとした。

現在も銀行間手数料の入力欄に一律0円を入力するという暫定対応のまま運用されており、会見を受けSNS上では「逆に謎深まる」「説明を聞けば聞くほど不穏な空気が漂ってきた」という声とともに、その原因をめぐりさまざまな考察が飛び交う事態となっている。
　10金融機関で計506万件の他行宛て振込処理などに影響が出た今回の障害は、RCの更改作業に起因する。

全銀ネットの説明によれば、これまで各金融機関側に設置されていた「RC17シリーズ」から、全銀センターに集約して運用する「RC23シリーズ」へ移行する作業を行い、9日までに行ったテストでは不具合は発生しなかったが、10日朝に通信が開始されるとRCで電文の送受信ができないという事象が発生したという。

各銀行ごとにリレーコンピュータは2系統（東京の全銀システム接続分と大阪の同システム接続分）あり、障害時に備えて相互に補完し合う設計になっていたものの、ハード面ではなくソフト面の不具合だったため、両方で不具合が発生した。

　原因は前述のとおり「インデックステーブル」の破損だ。銀行が顧客から振込などの依頼を受け、振込先の銀行に支払う手数料の金額を入力する方法には、

・金融機関側で電文に金額を入力してRCに送信する
・RCが保有するテーブルを読み込んでRCが電文に金額を入力する

という2つがあり、後者を採用する金融機関で障害が起きた。

テーブルはRC内のディスクで構築され、それを同じRC内の主記憶にコピーして展開しているが、今回はディスク内へのテーブル展開処理自体は正常終了していたものの、そのディスク内のテーブルが破損しており、そのまま主記憶にコピーされてしまったという。

　ただ、インデックステーブルの読み込みだけが障害の原因かは現段階では不明であり、一部で原因として報じられているメモリ不足についても因果関係は不明だという。

また、障害発生を受けてコンピュータを更新前の状態に戻すフォールバックを実施しなかったことに疑問が出ている点については、全銀ネットは会見で「実行しようとすると全金融機関の処理を終了する必要があり、時間も掛かる。今回の状況では取れない選択肢だった」と説明している。

サンプリングして行っていたためテストケースが漏れた？

　以上のとおり会見では明確な原因がいまだに特定されていないことが明らかになったわけだが、SNS上ではその障害の原因をめぐりさまざまな考察が飛び交ってる。

＜おおよそ、メモリー不足とはかけ離れた内容＞（原文ママ、以下同）

＜メモリ破壊云々の件、用意していたテーブルのデータ長が誤っており、ロードした際にRCのテーブルを破壊して、結果的にRCのテーブルが破壊され不正となった、のかと想像した。

環境構築時に作成したデータが間違いだけでRCの機能が立ち行かなくなるほどのエラーにはならない気がする＞

＜もし「電文長エラー」なら最有力は「桁あふれ」じゃないかな。

単純に設定した金額が大きかった、Javaのコンパイルバージョンが変わって暗黙変換の仕様が変わって悪さをしたとか＞

＜インデックステーブル作成段階で壊れてたとなると、不正なデータの処理に問題がありテストが漏れたんでしょうか＞

＜当該ベンダーの某ミドルウェアのバグなんじゃないかという話が某所であって、だとすると原因特定が難航しているのも頷ける＞

＜ISAMを使ったアプリ側で排他処理にバグがあって同時書込みするとindexが壊れる事があります。これかもしれません。

ただし、書き込みは成功してるようなので見当違いかもしれません＞

＜電文を処理が参照テーブルってインメモリデータベース（だと思うけど）そこのコピー元のマスタテーブルに問題があった　

全パターンの電文を網羅出来ればバグは防げただろうがサンプリングして行っていたためテストケースが漏れた＞

テストで想定外の事象を見つけるのは困難

　ITジャーナリストの山口健太氏はいう。

「全銀ネットはシステムの詳細を明かしていないため推測になりますが、データベースへの問い合わせを多用するシステムでは、データを使いやすい形でディスクに書き出し、あらかじめメモリ上に展開しておくことで高速化を図る場合があります。

今回の障害は、そのディスクに書き出したテーブル自体が破損していたと説明されています。

今回『謎が深まった』のは2点あり、1つはなぜテーブルが破損していたのか、もう1つはなぜそれを事前に検出できなかったのかという点です。

テーブルを書き出すプログラムの問題であれば比較的容易に見つかったと思われるため、まだ発見されていないOSやミドルウェアの障害を引き当てた可能性もあります。

　原因の特定が難しい事例としては、想定を上回る高い負荷が発生した場合があります。
しかし問題となったテーブルの書き出しは3連休中の事前準備で実施しており、そうした不確実性があったとは考えにくい状況です。

事前に準備したデータをしっかり確認していれば避けられた可能性はあるものの、一般にシステムのテストにおいては何をテストするかを事前に決め、それが通ればOKとするため、想定外の事象を見つけるのは困難です。

なぜ破損に気付くのが遅れたのかという点についても、原因究明が待たれるところです」
　大手ベンダSEはいう。

「参照・読み込み先のDBやテーブルなどのファイルが壊れていることによる障害というのは、ありがちな障害といえ、珍しくはない。

今回の件で不可解なのは、前日までのテストでは問題がなかったという点だ。

RC内部では主記憶に生成プログラムをロード・実行し、ディスク内にテーブルを生成し、それを主記憶にコピーしてRCに読み込ませているということだが、ハードの入れ替えで環境が変わったことで何らかのプログラム不具合が生じるというケースは普通にあるが、テストで拾えていたはず。

テストケースから漏れていた可能性もあるが、さすがにインデックステーブルがテスト項目から漏れていたとは考えにくい。

環境が変わればそれに乗っかるプログラムやテーブルのつくりも変えなければならず、それによって予想外の動作が生じることは避けられないが、テストで不具合を拾えなかったというのが一番の問題。

いずれにしても、事象の性格上、原因の特定には時間がかかるだろう」

次期全銀システムの開発スケジュールに影響も

　全銀システムは1133金融機関と接続され、1営業日あたりの平均処理件数は911万件、平均処理金額は14兆円で、顧客取引に影響が出る障害は1973年の稼働以来初めて。

障害により顧客が追加で負担した費用（追加的な手数料、延滞金、遅延損害金、貸出金利、貸越金利など）については、全銀ネットに加盟する各金融機関が補償することも発表されている。

また金融庁は13日、全銀ネットに対して原因や再発防止策などの報告を求める「報告徴求命令」を発令した。

　全銀の辻松雄理事長は会見で、「当法人の問題のみならず、我が国の決済システム全体の信頼性を揺るがす問題と認識している。

原因の究明と再発防止に向け鋭意検討していく」と説明した。

また、2027年に稼働予定の次期全銀システムの開発スケジュールに影響がおよぶ可能性があるとの見解も示した。

　影響がおよんだ10の金融機関は、三菱UFJ銀行、りそな銀行、埼玉りそな銀行、関西みらい銀行、山口銀行、北九州銀行、三菱UFJ信託銀行、日本カストディ銀行、もみじ銀行、商工組合中央金庫。

（文＝Business Journal編集部、協力＝山口健太／ITジャーナリスト）

山口健太／ITジャーナリスト

1979年生まれ。10年間のプログラマー経験を経て、フリーランスのITジャーナリストとして2012年に独立。主な執筆媒体は日経クロステック（xTECH）、ASCII.jpなど。取材を兼ねて欧州方面によく出かけます。

山口健太

Twitter:@yamaguc_k

ニュースサイトで読む: https://biz-journal.jp/2023/10/post_360737.html
Copyright © Business Journal All Rights Reserved.』