鈴木淳也のPay Attention
第197回
全銀システム障害、全銀ネットの対応で不足していたもの
2023年10月27日 11:40
全国銀行資金決済ネットワーク(全銀ネット)は10月18日、東京の丸の内にある銀行会館において、前週に発生した全国銀行データ通信システム(全銀システム)の障害に関する記者会見を実施した。会見は記者クラブ向けに10日夜に実施された“記者レク”と、11日夜に実施された“記者会見”に続いて、3度目の概要説明となる。
本稿では18日の会見を中心とした内容となるが、全銀システムの概要ならびに障害に至る経緯、将来的なプランなど、前提となる情報は13日に公開した記事にまとめてあるため、その差分を中心に解説していく。より詳しく知りたい方は、こちらの記事をあらかじめ参照いただきたい。
全銀システム障害対応のおさらい
前回の記事にもあるように、銀行など金融機関は「RC」と呼ばれる中継コンピュータ(Relay Computer)を介して全銀システムに接続している。今回の障害は、10月7日から9日までの3連休を使って金融機関14行のRCを旧世代(現行世代)の「RC17」から新世代の「RC23」へと置き換える過程で発生した。置き換えたRC23は10日の朝8時半(コアタイム)に合わせて動作を開始したが、14行のうちの10行で取引が正常に行なえていないことが判明し、これが障害の端緒となった。
銀行送金では送信指示である「仕向」と受信指示である「被仕向」という概念がある。ある銀行(A)から別の銀行(B)へと送金する場合、「A銀行からB銀行の口座への振込」という電子的な指示書が発行されることになる。これが「電文」で、この電文のやり取りを銀行間で行なうのが全銀システムの役割となる。
「仕向」は送金指示だが、逆に相手側銀行から自身の銀行口座への送金による“振込依頼”がやってくる場合もある。これが「被仕向」で、この両者が存在することで銀行送金が成り立っている。
ただ今回の障害では、RC23によって問題が発生した金融機関からの「仕向」および、対象金融機関向けの「被仕向」の電文の送受信ができなくなったことで、「送ったはずのお金が届いていない」「届いていても遅れたり、期日内に届かなかった」という事象につながった。
下図は全体概要をまとめたものだが、この資料は全銀ネット上でPDFファイル形式で公開されているので、興味ある方は参考にしてほしい。
RCを介さないとオンラインによるリアルタイムでの送金(都度送金)は行なえないのだが、イレギュラーな代替手段として本来は給与振込などまとめて送金指示を行なう場合に利用する「新ファイル転送(新F転)」や「物理媒体(LTOと呼ばれるテープ式の媒体)の全銀センターへの持ち込み」を活用して送金を行なう方法が用意されている。
これら手段を駆使して障害発生中も送金遅延が起きないようにしていたものの、データファイルや媒体をその日のうちに準備できなかったり、処理が間に合わずに翌日にまわったり着金に時間がかかるケースがあったりと、すべての処理残の解消には12日まで待たなければならなかった。以上の代替対応をまとめたのが次の資料となる。
現場で実際に何が起きていたのか
前回のレポートでも触れたが、障害発生2日目にあたる11日の会見の時点では「内国為替手数料のチェックプログラム」に問題があり、ここで行なわれている内国為替手数料の一覧が示されたテーブルを参照することなく、「すべて0円で処理」することでRCが動作しなくなる問題を回避し、12日の処理が正常に行なえるようにする方針が示されていた。
障害初日の10日の段階では、このチェックプログラムが正常動作するよう修正を施して夜間帯の「モアタイム」でのテストを2回実施したものの問題は解決せず、11日の業務開始時刻である朝8時半のコアタイムまでに対応が間に合わないと判断。いったん前日同様の体制で11日に突入した後に、緊急対応として、いわゆる「0円プログラム」を走らせることになったというわけだ。
11日の会見での説明を聞いた報道関係者は筆者を含め、「チェックプログラムの動作に問題があったのでは?」と考えていた。その後、日本経済新聞の「全銀ネット障害、メモリー不足が要因 事前テスト甘く」という報道もあり、RC17から移管されたRC23のシステムで充分なメモリが割り当てられず、このチェックプログラムの動作に支障をきたしたという意見が出るようになったと考えている。合わせて、RCの動作環境が32bitから64bitへと世代交代の過程で移行したという話もあり、「(64bitでは同じプログラムでも32bitよりも必要メモリが増加する傾向があり)このあたりの見積もりが甘かったのでは?」という話が出始め、実際に18日に行なわれた記者会見ではこのあたりの質問が頻繁に行なわれる状況となった。
ただ、18日の会見の2時間超に及ぶ質疑応答のなか、後半の方で「RCで使用される金融機関のインデックスが並べられた参照テーブルが“事前準備の段階から”壊れていた」という回答が出たことで、少し雲行きが怪しくなってきた。当初、問題はRCで動作するアプリケーション側にあると皆が考えていたのだが、実は参照元となるデータそのものがRCでの動作前にすでに“壊れていた”ということで、メモリ容量や64bit環境での動作といった問題ではない可能性が高くなったためだ。
このあたりについてもう少し詳しく説明していく。銀行間でやり取りされる送金の際の手数料である「内国為替制度運営費」の設定は、RC23においては下図のように「金融機関があらかじめ電文に金額を入力」「RCが事前に用意した“テーブル”を参照してRC自身が電文に金額を挿入」といういずれか2つの手段を選ぶことができる。
今回RC23へのリプレイスが行なわれた14行の金融機関のうち、障害が発生した10行については後者を、それ以外(JPモルガンチェース銀行を除く3行)については前者が選ばれており、ここが障害発生の分岐点となった。今回の障害は、この“テーブル”を参照するRC内のアプリケーションが、“テーブル”を参照した際にエラーが発生して異常終了することで起きたもので、前述のように当初の問題はこのアプリケーション側にあるような印象があったのだが、実際には参照先の“テーブル”そのものに問題があったというわけだ。
異常終了が問題となったアプリケーション(チェックプログラム)が参照する“テーブル”は、RCが再起動されたタイミングなどで(事前に)作成された“テーブル”をコピーする形で利用される。プログラムが動作するメモリ上に“テーブル”は展開されるが、この「コピー前の段階ですでに“テーブル”が壊れていた」というのが18日に新たに判明した事実だ。
上図の赤丸の部分がそれに該当するが、テーブルを作成するプログラムそのものはRC17時代から利用されていたもので、新環境(RC23)においても特に変更はなく、事前テストの段階でも問題は発見できなかった。だがRC23が10日のコアタイムに突入して本番稼働をしたとたんに“テーブル”生成から破壊が起きており、18日時点ではこの原因究明に比重が移ったと考えられる。
全銀ネット側では「メモリが原因かもしれないし、64bit環境への移行が原因といえばそうかもしれない」といった形での曖昧な回答をしていたが、これは“テーブル”が壊れた原因が同時点では判明していないことに由来するとみられる。
障害発生原因の考察と全銀ネットの対応で不足していたもの
RC17は“アプライアンス”形式で金融機関側に設置される中継装置であり、コアタイム用とモアタイム用の2つに加え、さらに多重化のための分岐が行なわれており、設置コストや管理負担が比較的大きかった。
一方でRC23は全銀システムのセンター側に配置される構造になっており、これまでアプライアンス装置として提供されていたハードウェアは仮想化によって1つの“サーバファーム”上に集約される形となった。管理負担の低減とコスト削減を両立させるための手法だが、これまでアプライアンスとして起動していた機能が“インスタンス”として呼び出される形に変化したことで、先ほどの日経新聞が伝えていたような「メモリ不足で動作しなかった」ということは考えづらく、少なくとも動作に必要なメモリが不足しているのであればインスタンスが必要とするメモリリソースを単純に多めに割り当てるだけでいい。
さらにいえば、前述の事前準備として“テーブル”を作成するプログラムについては、RC17時代からそのまま流用したもので、RC23で特に変更を加えたわけでもないという。ここは筆者の推測となるが、問題の発生原因となったプログラムはRC17とRC23で違いはなく、しかも本番以降前の事前テストはすべてパスしていたということで、「本番環境で諸条件が揃った場合のみに再現される特殊な障害」である可能性が高いのではないかとみている。つまり必要な手順はすべて踏んでおり、事前テストでも特に問題はなく、当初言われたようなケアレスミスに起因する可能性は低いという考えだ。重ねての推察となるが、各種のプログラムそのものには問題なく、RC23の環境で採用されているミドルウェアやOSなど、根本となるシステム自体が内包するバグや何らかの不具合、あるいは仕様で問題が発生してしまったのではないかと現時点では考えている。
今回18日の全銀ネットの会見で1つ感心したのは、問題の責はすべて全銀ネット側にあり、ベンダー名を公表したり、ベンダーへの責を問う姿勢を一切見せなかったことだ。ある意味で発注側としてあるべき姿勢だとも思う。
この姿勢を評価して筆者も今回のRC23を担当したベンダー名には触れないが(全体の受注はNTTデータだが、RCの担当はまた別のベンダー)、この担当ベンダーが提供するミドルウェアやシステムなどが問題を内包していた可能性を考えている。この世にバグのないシステムなどほぼ存在しないと考えているが、システム上で動作するプログラムに問題が発見できず、それでも本番環境では問題が発生するケースなど、システム側にバグがあった場合は問題の特定や発見が難しい。今回はそのケースに該当するのではというのが筆者の考えだ。
ただ全銀ネット側がまずかったと思われる対応もあり、例えば障害情報の告知などがそれに該当する。全銀ネットにとって直接の顧客に当たるのは銀行などの金融機関であり、こちらとは比較的密に連携を採っていたものと思われる。一方で、一般的な利用者は金融機関側のアナウンスで初めて障害状況を知るわけで、該当する金融機関によって対応がまちまちになってしまったのも事実だ。また、クレジットカード会社やその他信販会社など、締め日の取引に関わる金融機関は必要な情報をまったく提供しておらず、会社によってはサポート窓口が電話対応でパンクする事態に陥ってしまった。これは大規模障害を想定した対応ができていなかったことを意味する。おそらく、こうした際の告知方法や周知方法などについて、改めてルール整備や取り決めを作っておき、いざというときに利用者らを不安にさせないようにすることが重要と思われる。
いずれにせよ、1973年の第1次システム稼働から初とも呼べる全銀システムの大規模障害で、システム対応については準備できていても、広報手段がお粗末だった点は否めない。当面はRC23での障害の原因究明を進めつつ、今後のことを考えて、こうしたマニュアル整備が求められるだろう。