金融機関を中継する「統合ATM」でトラブルが続発した。1月11日,日本IBMの「接続ソフト」のバグが原因で,一部の銀行で取引遅延などが発生。同26日は統合ATMの不具合が表面化し,取引が一部できない障害が全国に広がった。十分にテストしたはずだったが――“想定外”の火種がくすぶっていた。

図1●“経路”不足で処理遅延が発生
銀行間の取引を仲介する「統合ATM」は,他行向けのリクエストを受けた際,該当銀行向けの“経路”を確保した上で電文を転送する。1月26日,ある銀行(この図ではB銀行)向けに処理が集中したことで,その銀行向けの経路が激減。これが引き金となり,経路管理プログラムの処理遅延が発生し,それ以外の銀行もトラブルに巻き込まれた。その結果,日本全国でATMやCDがタイムアウトなどに見舞われた
図2●処理遅延の原因は排他ロック
経路管理プログラムは,管理テーブルから経路の「空き」を探索する。ある銀行向けに処理が集中したことで,その銀行用の「空き」経路がひっ迫。排他ロックを用いて探索していたため,経路管理プログラムの処理遅延を引き起こした。プログラムは1月27日のオンライン開始までに修正を実施。排他ロックをかけずに「空き」経路を探索するようにした
図3●IBM製の接続ソフトに不具合
1月11日,IBM製の「統合ATM接続ソフト」を利用する銀行において,統合ATMとのやり取りでタイムアウトが多発するトラブルが起きた。「時刻のズレを調整する機能」の実装ロジックにミスがあったことが原因。4桁の符号付整数同士を足したところ,計算結果がマイナスになってしまった。この結果からタイムアウト値を算出したことで,20~30%の確率で,送信した電文がタイムアウトと誤認された
図4●統合ATMとの開局処理に失敗
統合ATMの稼働初日である1月4日,島根銀行は統合ATMとの開局処理に失敗した。受信した電文をファイルに書き込む処理で,ファイル・ステータスが「書き込み不可」になっていたことが原因。1月1日のテストでは問題なかった。なぜステータスが変わったのか,現在も調査中である
 統合ATMは,金融機関のATM(現金自動預け払い機)やCD(現金支払機)間を中継するサービス。従来のMICSなどに代わり,今年1月4日に運用開始した。開発を取りまとめたのはNTTデータである。

 これまでに明らかになったトラブルは主に3つ。(1)稼働開始した1月4日に島根銀行などが統合ATMへの接続に失敗,(2)東京三菱銀行など,IBM製の接続ソフトを使う銀行で同11日に取引のタイムアウトが多発,(3)同26日,処理負荷の高まりから,統合ATMを利用する取引の一部に遅延などが生じた。

 なぜトラブルは起きたのか。「1月1日のテストでは問題なかった」(島根銀行 事務システムグループ 部長 岩成泰男氏)と,いずれのケースも事前にテストは行っている。しかも「過去の実績から想定されるピーク以上の負荷をかけた」(NTTデータ ビジネス開発事業本部 副事業本部長 山田英司氏)など,テスト条件は厳しい。

 しかしトラブルは起きた。日本IBMの岩崎明氏(金融システム事業部 インダストリー・ソリューション担当 統括部長)は,「あるプロジェクトに閉じて開発していると,どうしても“思い込み”が入る」ことを反省点に挙げる。「こんなケースは多分ない」とテスト・シナリオが甘くなり,トラブルにつけこまれた。

特定の銀行へアクセスが集中

 3つのトラブルのうち最も影響が大きかったのは,1月26日に発生したものだ。ATM/CDから他行カードを使った取引の一部が行えなくなった。統合ATM自体の障害だったため,都市銀行や地方銀行,第二地方銀行など,日本全国の金融機関に影響が及んだ。

 統合ATMは,他行向け残高照会などのリクエストを受けると,“経路”を確保した上で電文を転送する(図1[拡大表示])。ここで言う経路とは,各銀行向けの論理的な転送チャネルであり,「電文量に応じ,多い銀行で100~200本用意してある」(NTTデータの山田氏)。

 経路管理プログラムは「空き」経路を探索し,それをリザーブする。26日は,ある銀行への取引が集中。その銀行向けの「空き」経路がひっ迫し,経路探索の処理時間が長くなった。その結果,経路管理プログラムが実行待ちのキューに滞留。処理が遅い,タイムアウトでエラーになるといったトラブルが全国のATM/CDに波及した。

 経路管理プログラムを同時にいくつ実行できるかは,「ピークとなる5月の連休明けの実績を基に,かなり余裕を持たせて設定した」(同氏)。それでも乗り切れなかった理由は2つ。「すべてのテスト・パターンを洗い出したつもりだったが漏れた」というように,特定の銀行に負荷が集中した際の影響を見通せなかった。もう一つは,経路管理プログラムに実装した探索方法の不備である。

排他のオーバーヘッドが露呈

 26日に取引が集中した“ある銀行”とは,りそなホールディングスの傘下銀行とみられる。前日の25日,りそな銀行はシステムセンターで電源設備の定期点検を実施。その過程で,電源の供給断が発生した。システムを再起動したが,手順のミスなどで他行取引が正常に行えない状態に陥り,その影響は26日まで尾を引いた。

 26日の午前中,りそな向けに取引が集中したために,その経路がひっ迫。しかも,りそな側から応答が返りにくい状況だったために,経路の占有時間が延びた。

 さらに,経路管理プログラムの探索方法の不備が,性能低下に拍車をかけた。経路管理プログラムは,経路管理テーブルからレコードを順番に読み込んで「空き」を探すが,その際,レコードごとに排他ロックをかけていたのだ(図2[拡大表示]の左)。「空き」が少ない状況で,読み込むべきレコード数が増大し,“排他”によるオーバーヘッドが性能を著しく低下させた。

 その結果,りそな向けの送信要求を受けた経路管理プログラムが,ズラリ並んだことは想像に難くない。そのあおりで,他行向けの処理も待たされてしまった。NTTデータには,午前中から金融機関の問い合わせや障害報告が殺到。処理量の自然減から午後3時40分に「安全宣言」を出したが,夜にかけて再び負荷が高まり,取引遅延などが断続的に発生した。

 NTTデータは午後9時以降,テスト系で再現性をチェック。トラブルが再現したことで,排他処理に原因があることを特定し,「空き」が見つかるまでは排他ロックをかけずに読み込むようプログラムを修正した(図2[拡大表示]の右)。

タイムアウト値が異常に

 このトラブルに先立つ1月11日,東京三菱銀行など20行を超える銀行において,統合ATM向けの取引でタイムアウトが多発した。原因は日本IBMが開発した統合ATM接続ソフト「FINEACE/6000 NCS-UDP/IPフィーチャー」のバグ。「時刻のズレを調整する機能」に不具合があった(図3[拡大表示])。

 この機能は,銀行側と統合ATMの時間差を埋めるためのもの。簡単に言えば,両者のタイムスタンプを足して2で割る。「どのように実装するかは,統合ATM接続ソフトを開発する各ベンダーが判断する」(NTTデータの山田氏)が,日本IBMは4バイトの符号付整数で時刻を表現。桁数が不足したために加算結果がマイナスとなり,タイムアウトの判定に異常をきたした。

 一般に,C言語/UNIXではグリニッジ標準時(GMT)の1970年1月1日0時0分0秒を起点とした積算の秒数で時刻を表す。多くの場合,4バイトの符号付整数で定義される。この時刻が,日本時間の2004年1月10日22時37分04秒に,16進数で「3FFFFFFF」から 「40000000」へと変わった。これ以降,銀行側と統合ATMのタイムスタンプを加えると,先頭バイトが「40」+ 「40」=「80」となる可能性が生じた。

 「80」は先頭ビットに「1」が立ち,これが符号付整数ではマイナスと解釈される。そのためタイムアウト値が異常な値となり,正常な電文が破棄された。ただし,「発生確率は20~30%で,すべての電文で異常が発生したわけではない」(日本IBM 金融システム事業部 第二ソリューション営業部 ソリューション・マーケティング担当営業部部長 堀井康司氏)。これは電文の送信タイミングによるもので,タイムアウト後にやり直せば,正常終了することがあったという。

 1月11日は午前9時から,このようなタイムアウトが散発した。日本IBMは,サーバー機のメッセージから,タイムアウト値の異常を特定。当初は統合ATMの問題も疑ったが,IBM製品を使う銀行にトラブルが集中していることが判明し,ソフトのバグに気づいた。データ長を4バイトから8バイトに拡張して対処した。

開発者以外のチェックが必要

 統合ATM接続ソフトのリリースに先立ち,日本IBMは約8カ月をかけ,大和研究所でテストを行った。しかし,バグは発見できなかった。「金額計算なら桁あふれを考慮して大きな数字でテストする。しかし今回はタイマーなので,そのようなケースを入れなかった」(岩崎氏)。“実際よりも先”の日付でテストすればバグが発見できた可能性はある。この反省から,「研究所内に,テスト・ケースなどをレビューする専門部隊を設置した」(同氏)。

 時刻のズレを調整する機能は,統合ATM側にもあるが,問題は発生していない。その実装方法は公開されていないが,データ長が8バイトだったなどが考えられる。IBM以外の製品を使う銀行でもトラブルはほとんど起きていない。あるメーカーは「自社で開発せず,NTTデータが提供する装置を使った」と明かす。

 ほかにも,統合ATMへの切り替えに際してトラブルはあった。例えば島根銀行は,1月4日の午前9時,統合ATMとの開局処理に失敗した(図4[拡大表示])。電文をファイルに書き込む際にプログラムが強制終了した。「どのステップで失敗したかはすぐに分かったが,なぜ書き込めないかが分からなかった」(事務システムグループ 副長 土江康之氏)。原因は,ファイル・ステータスが“書き込み不可”となっていたからだ。1月1日のテストでは問題なく書き込めた。なぜステータスが変わったのか,現在も調査を継続している。

(森山 徹=tmoriyam@nikkeibp.co.jp)