全3427文字

 全国銀行資金決済ネットワーク(全銀ネット)とNTTデータが「全国銀行データ通信システム(全銀システム)」のシステム障害に関して2023年12月1日に共同会見を開催した。ここではシステム開発の観点で2つの重要な事実が新たに判明した。

 1つは、各金融機関から他行宛ての送金時に中継コンピューター(RC)が参照する「金融機関名テーブル」やそのテーブルの参照を高速化する3種類の「インデックステーブル」がメモリーへの展開時、所定の作業領域からオーバーフローして破損したこと。もう1つは、詳細設計書では4種類のテーブルを同時に展開できるだけの作業領域を確保することを求めていたが、プログラマーやレビュアーなどの関係者がいずれもその記述を見落とし、これが上述のオーバーフローを招いたという痛恨のミスだ。

 全銀ネットとNTTデータは会見で原因の詳細とともに、開発工程における課題と再発防止策を発表した。果たしてこれにより、同種の問題の再発を有効に防げるのだろうか。

 今回の障害の直接的な原因は「金融機関名テーブル」を生成するプログラムが必要な作業領域を確保できていなかったことだ。

 全銀ネットは10月7日から9日にかけて、14の金融機関でRCを「RC17シリーズ」から「RC23シリーズ」へ更改した。RC23では、OSを従来の32ビットから64ビットに変更した。さらにNTTデータは会見で、RCのOSがLinux系であること、生成プログラムの開発言語がC言語であること、金融機関名テーブルがlong型の属性値を保有していたことを明らかにした。

 一般にLinux環境の場合、long型には32ビット版では4バイト、64ビット版では8バイトのメモリーが必要であり、この分のメモリー増が必要となったとみられる。NTTデータは金融機関名テーブルのサイズ拡張については認識しており、拡張後の金融機関名テーブルが確保したメモリー内に収まることを確認していた。

 生成プログラムは、金融機関名テーブルと同時に3種類のインデックステーブルを展開する仕様だった。インデックステーブルは、1132の金融機関が記載されている金融機関名テーブルの参照を高速化するためのものであり、金融機関名テーブルと同時に展開されていなければ意味をなさない。

 しかし担当者らはこれを1つずつ展開するものと誤認。結果、確保したメモリーを超えた領域に展開されたデータが他のプログラムから上書きされ、異常値が紛れ込んだ。4つのテーブルを同時に展開する設計については詳細設計書には記載されていたものの、製造工程で見落とされ、コーディングでもレビューでもすり抜けた。

障害の直接的な原因
障害の直接的な原因
(出所:全国銀行資金決済ネットワーク・NTTデータ)
[画像のクリックで拡大表示]