全銀システム障害とは何だったのか

東京の大手町にある銀行会館に入る全国銀行協会

全国銀行資金決済ネットワーク(全銀ネット)とNTTデータは12月1日、東京の大手町にある銀行会館において10月10日から11日にかけての2日間にわたって発生した全銀システムの障害について記者会見を行なった。

これは10月13日に金融庁から資金決済に関する法律第80条第1項に基づく報告徴求命令を受領し、その報告が前日の11月30日に行われたのを受けてのもの。全銀ネットが同件について会見を行なうのはこれが4回目で(正確には1回目は“記者レク”という名目の説明会となっている)、全銀システム構築を受注した中心ベンダーであるNTTデータの関係者が同席するのは初となる。

過去3回の会見では不明だった障害原因が判明し、今後の対策などの説明が行なわれたが、本稿ではその概要について説明しつつ、誤解を受けそうなポイント、なぜ障害原因となった「RC」のリプレイスが行なわれ、将来的に何を目指しているのかに触れたい。

全銀ネットにとっては4回目にあたる全銀システム障害の記者会見。今回はベンダーも交えたフルメンバーが揃っている。左から全銀ネット企画部長の千葉勇一氏、同事務局長兼業務部長の小林健一氏、同理事長の辻松雄氏、NTTデータ代表取締役社長の佐々木裕氏、同取締役副社長執行役員の鈴木正範氏の計5名

全銀システム障害では、結局何が起きていたのか

システム障害の詳細は過去の連載記事に記してあるが、簡単に概要を紹介する。

全国の銀行など金融機関が接続して「電文」と呼ばれる取引情報を仲介するシステムである「全国銀行データ通信システム(全銀システム)」では、2027年からの稼働が見込まれる第8次システムへの移行の前段階として、各金融機関の基幹システムと全銀システムの仲介を行う「RC(Relay Computer：リレーコンピュータ)」の交換作業を進めていた(全銀ネットではこれを「レベルアップ」と呼んでいる)。

現行で利用されているRCが「RC17」で、次期システムに向けてリプレイスが進んでいるのが「RC23」だ。このRC23への最初のリプレイス作業が10月7日から9日にかけての3連休をかけて10行を対象に実施されたが、「コアタイム」と呼ばれる平日日中の営業時間帯が10日にスタートすると、RC23が異常終了して動作しなくなる現象が発生し、前述の一連のシステム障害へとつながった。

システム障害の概要

実際に、RCの内部でどのような問題が起きていたのか。10月18日の会見では、問題箇所への言及が行なわれた。RCでは電文を処理する際に、「内国為替手数料」と呼ばれる銀行間取引での手数料を挿入する機能があり、このプログラムが正常に動作していないことは10月10日に障害が発生したタイミングですでに判明していた。

内国為替手数料はRCの機能で電文に挿入するほか、銀行の基幹システムがRCに電文を送る際にあらかじめ手数料の情報を挿入する方法の2種類が存在する。今回RC23へのリプレイスを行なった金融機関のうち、後者を選択した場合にはRCでの障害が発生していなかったからだ。

内国為替手数料を電文に挿入する機能では、対象金融機関の情報がまとめられた“テーブル”を用いて挿入作業を行なっているが、この“テーブル”を参照するチェックプログラムに問題があり、その修正を10日夜から11日朝にかけての時間帯で試みたものの間に合わず(日中は取引があるため夜間帯の作業しか行なえない)、11日夜に改めて一時的な対策として「RCで挿入する手数料をすべて0円にする」というプログラムへ差し替し、12日以降の取引が問題なく行なえるようにしている。

18日の会見ではさらに踏み込んで、「テーブルの生成プログラム」そのものに問題があったことが示唆されている。このプログラムそのものはRC17時代のものをそのまま流用しているが、RCの再起動時などにこのプログラムが呼び出されてテーブルを生成した後、実際に電文への手数料を挿入する機能がチェックプログラムを介してテーブル参照するために、そのメモリ領域へと事前に作成しておいたテーブル情報をコピーしてくる。RCが異常終了したのは、このテーブルに不正なデータが含まれており、それを検出したからであり、これはいずれかのタイミングでテーブルのデータが壊れていたことを意味する。18日の会見で分かったのは、「コピー前のテーブルのデータがすでに壊れていた」という情報だ。

障害の発生原因とRCの内部で起きていたこと

18日の全銀ネットの報告を受けた記事では、筆者の予想として「ミドルウェアやOSの隠れた不具合を踏んでいたので原因究明に時間がかかっているのでは?」といったことを挙げていたが、12月1日の記者会見でようやく全貌が見えた。

シンプルにいえば、「ワークメモリの必要量を見誤っており、領域確保が不十分ではみ出たデータが破壊されていた」というもの。下図が詳しいが、このテーブル生成プログラムそのものはRC17からRC23でそのまま引き継がれており、同じ機能を提供する。ただし、RC17では32bitのOS上で動作していたものが、RC23では64bitのOSへと変更されており、それに合わせてプログラムの“リコンパイル”が発生している。

システム障害の原因はOS変更によるワークメモリの領域確保の見積もりを誤ったこと

32bitから64bitへのOSが変更されたことで、テーブルで利用される単位レコードあたりのデータ長が変化するため、金融機関名が記されたテーブルのサイズもOSの変更に伴って増大する。生成したテーブルを展開するメモリ領域は、テーブル生成を行うC言語のプログラムによってあらかじめ必要分が宣言で確保されているが、64bit化によって変更されたデータ長でもテーブルそのものはRC17時代に宣言されていた領域に収まっていたため、特に変更されることなくRC23にもそのまま持ち込まれた。

ただ、この銀行名テーブルは読み仮名や金融機関コードでも素早くテーブル内の情報を参照できるように別途3種類のインデックスが用意されており、RC17において1つのテーブルと3つのインデックスが一体化した形で生成されていたが、RC23においてはテーブル＋インデックス×3を生成した場合にわずかながら事前に確保されていたメモリ領域をオーバーしてしまう(NTTデータによれば全体の2％程度だという)。

本来作業を行なうワークエリア外の領域のメモリはシステムによって保護されないため、ここに書き込まれたデータは他のプログラムなどが起動することで破壊されてしまう。テーブル生成プログラムそのものの単体テストでは問題なくても、本番環境においてRC内で複数のプログラムが動作した場合にメモリ領域を破壊するケースがあり、これが障害へとつながった。

当初、今回の問題は10月18日の会見前に日本経済新聞などによって報じられた「メモリ不足」というキーワードが先行したため、「コスト削減のために必要な搭載メモリ容量をケチった」といった言説が広まっていたりした。現在もなお「メモリ不足」といった表現が見受けられるが、これは正確ではない。RC17は全銀システムに接続するすべての金融機関に対してアプライアンス形式で提供されるもので、参加行分の装置とモアタイム対応、多重化による台数増を合わせて4-5桁に及ぶ台数の装置が拡散する形で存在していた。RC23では全銀システムのセンター側に装置が集約され、かつ仮想化によって複数台の装置が束ねられる形になり、RCの機能は仮想環境における“インスタンス”として提供される。メモリを含む必要なリソースは適時リソースプールから割り当てが行なわれるため、物理メモリやインスタンス上のメモリが不足する可能性は低い。シンプルに「メモリ領域割り当ての際のパラメータを間違えた」という方がしっくりくる。

なお、RC23で仮想化方式を採用したのは「コスト削減」の考え方が根幹にあるのは間違いないが、管理対象のデバイスを集約することで銀行と全銀ネットともに管理負担が軽減されるということが挙げられる。

今後の課題について

全銀ネットからは今回の総括として、影響範囲と補償についての中間報告が上がっている。下表は10月10日と11日に発生した障害の対象取引件数だが(単位は万)、銀行などへのヒアリングを行なって影響範囲を再確認し、最終的に2日間での対象取引件数は566万件で、以前の報告より60万件ほど増加している。

また補償や責任問題についてまだ方針がまとまっていないが、銀行間取引で直接の損害を受けた顧客の補償について、11月17日時点で約8,000件、約800万円ほどの数字が見込まれるという。あくまで途中経過なので今後もさらに増加するとみられる。また「0円プログラム」により本来対象行が得られるはずだった内国為替手数料が処理されていない状態にあるが、10月分の手数料については12月中の間もなくのタイミングで精算が行なわれるようだ。

システム障害によって影響を受けた取引の最終件数

課題は今回の障害発生に至る一連の対応になるが、「ワーク領域の確保ミス」という原因についてNTTデータでは「単純な問題ではない」としているものの、テーブルとインデックス全体の容量の計算ミスはどちらかといえばケアレスミスであり、これが事前のレビューやテストをすべてすり抜けてしまった点が問題だ。発生原因分析と再発防止策のまとめのスライドでも触れられているが、おそらくは既存プログラムのOS変更に伴う改変において、現場の担当者のみで是非を判断してしまい、以後も単体テストや結合試験などでは問題なく動作したため、本番環境になるまで再現できずに発覚が遅れた流れとみられる。

ゆえに対策としては、今回のように基本的な変更事項のないプログラムにおいても詳細設計を行なった担当者をレビューに絡ませるほか、このあたりの問題に知見を持つプロフェッショナルを計画段階から参画させていくことが必要だとNTTデータでは述べている。また機能テストにあたってはさまざまな組み合わせを考慮したテストデータを流して動作確認を行なうが、今回の反省点として本番環境がスタートするまで問題が再現されなかったこともあり、総当たり方式のテストよりも、実取引に近いデータを流した方が効率と再現性の面で有利だという考えに至っている。

NTTデータによる原因分析と対策

またこれは割と致命的な印象も受けるが、復旧プランにおける優先順位付けについてNTTデータと全銀ネット側で合意が行なわれていなかったという点も問題だ。

2つポイントがあるが、1つは10月の3連休で行なわれたRC17からRC23へのリプレイス作業では旧環境へのロールバックも含めた切り戻し判断があったが、実際に本稼働してからの障害についてはおそらく想定外の事態だったと思われる。もう1つのポイントは、10月10日夜に行なわれた作業において、夜間帯の非常に限られた時間しか与えられていないにもかかわらず、作業が間に合わなかったために復旧をいったん中断し、障害を抱えたまま11日の取引がスタートしてしまった点だ。対策としてガイドラインの制定のほか、障害発生のシナリオを想定したブラインド訓練の実施などが盛り込まれており、「準備不足だった」という点は否めない。

復旧プロセスにおける課題

以上を踏まえて、今後年4回、6年間にわたって実施されるRC17からRC23へのリプレイス作業が実施されることになる。全銀ネット理事長の辻松雄氏によれば、今回の件を受けて2024年1月にやってくるリプレイス作業や第8次全銀システムへの移行計画に変更はないとしているが、来年1月に移行を予定していた金融機関3行のうち、1行が移行作業を延期、残り2行についても「0円プログラム」が残った状態の暫定対処版での移行作業になるという。また全体計画に変更はないとしているものの、現在第8次システムのコア開発にかかわる作業はすべて停止しており、障害対応を優先する旨が説明されている。来年第2四半期にやってくるRC23へのリプレイス作業以降での正常化を目指しつつ、来年10月のリプレイスでは今回問題となった“五十日”での作業が再びやってくることになるため、全体対策を進めて問題に臨む構えだ。

今後のリプレイス作業について

このほか全銀ネットから報告されたのは、情報担当責任者であるCIO 1名を新たに設置すること、そして今回たびたび指摘を受けたBCP(Business Continuity Plan：事業継続計画)が不十分だったことを反映し、日本国内に東京と大阪の2カ所に存在する全銀システムのセンターの両方でRC23へのリプレイスを同時に行なうのではなく、東阪両センターでのリプレイスのタイミングをずらして行なうことで同時障害発生を防ぐ方策が考えられているという。来年1月のタイミングには間に合わないものの、準備ができしだい対応していく意向だ。

障害を経てもなお、全銀ネットがRCのリプレイス計画ならびに第8次システムの計画を維持する理由の1つに、システムの保守期限の存在がある。先行してRC17を導入した金融機関から6年を経て順番にこの期限がやってくるため、移行タイミングを大きくずらすことが難しい。また第8次システムにおいては「オープン対応」「APIゲートウェイの設置」という大きなトピックがある。オープンシステムへの移行は2030年以降にやってくる現在のコアシステムの中核を担うメインフレームの製品提供と保守期限の終了を見据えてのもので、APIゲートウェイは将来的なRCの廃止により、銀行間での接続がAPIを経由した直接接続へと移行する際に必要となる。いずれにせよ、今後10年程度で全銀システムが大きく変化する狭間の時期にあり、今回の障害対応と合わせてこれら計画を滞りなく進めていく必要性に迫られている。

地下鉄から全銀会館へと通じる通路にて