一般社団法人全国銀行資金決済ネットワーク（全銀ネット）とNTTデータは2023年12月1日、共同会見を行い、同年10月10日に全国銀行データ通信システム（全銀システム）で発生したシステム障害について経緯、原因、再発防止策を報告した。原因については詳細を明らかにした。システムが32ビット環境から64ビット環境に変わったことで金融機関名テーブルのサイズが増えたが、確保するメモリー領域のサイズを変更していなかった。
全国銀行資金決済ネットワーク（全銀ネット）とNTTデータは、2023年10月10日に全国銀行データ通信システム（全銀システム）で発生したシステム障害について共同会見を行い、経緯、原因、再発防止策を報告した（写真1、関連記事：全銀ネットのシステム障害、発生から1日経過も復旧の目途立たず／全銀ネットのシステム障害が復旧、他行宛の振込取引が通常利用可能に）。
原因については、全銀ネットが障害発生から8日後の10月18日に「システム障害に係る対応状況について」を公表して、推定される原因と対応策を報告した（関連記事：脱メインフレーム大作戦、最初の一歩でつまずいた全銀システム）。
続いて、NTTデータが11月6日に会見を開き、金融機関名テーブルを生成するプログラムに不具合があったことと、旧環境（32ビットOS）から新環境（64ビットOS）への移行が影響したことを報告していた（関連記事：全銀システム障害の原因はテーブル生成プログラムの不具合、新旧稼働環境の違いを吸収できず─NTTデータ）。
今回、全銀ネットとNTTデータは原因の詳細を説明した。システムが32ビット環境から64ビット環境に変わったことで、C言語のデータ型のサイズの違いから、テーブル生成プログラムが生成する金融機関名テーブルのサイズが増えた。しかし、テーブル生成プログラムがテーブルの生成のために確保するメモリー領域のサイズについては変更していなかった（図1）。
図1：障害の発生原因。32ビット環境から64ビット環境に変わったことで生成するテーブルのサイズが増えた結果、確保したメモリー領域に収まりきらなくなった（出典：全国銀行資金決済ネットワーク、NTTデータ）拡大画像表示
この結果、金融機関名テーブル自体は確保領域に収まるが、金融機関名テーブルと共に作成する3つのインデックステーブルの一部が確保済みのメモリー領域に収まりきらない状態になった。このため、確保していないメモリー領域に書きこんだインデックステーブルの一部が、他のアプリケーションによって上書きされた。
インデックスの参照先として、本来アクセスしてはいけないメモリー領域を示すことになったことからアプリケーションが異常終了した。今回のケースでは、特定の一部のカナで始まる金融機関名のインデックスが壊れた。壊れたインデックスは全体の2%にあたる（図2）。
図2：障害が発生した、システム上のプロセス（出典：全国銀行資金決済ネットワーク、NTTデータ）拡大画像表示
テーブル生成プログラムは、C言語で開発したプログラムである。これまで32ビット環境でコンパイルして動かしていたコードを変更することなく、そのまま64ビット環境で再コンパイルして使っている。全銀システムのOS環境では、金融機関名テーブルで使っているデータ型（long型）のサイズが32ビット環境と64ビット環境で異なることから、生成するテーブルのサイズが増えた。なお、インデックステーブルで使っているデータ型のサイズは32ビット環境と64ビット環境で同じであり、テーブルのサイズにも変化はない。
●Next：開発・テスト工程のそれぞれで抱えていた課題、今後の方針
会員登録（無料）が必要です
- 1
- 2
- 次へ ＞
