PR

　LANスイッチのバグが、サーバーOSの隠れた障害を引き起こした─。日本銀行と大手金融機関が紙幣を授受する発券センターで、3月初めに発生したシステム障害の原因が明らかになった。古いOSの問題が表面化したためで、同様の問題は一般企業にもありそうだ。

　障害は埼玉県戸田市にある日銀の発券センター内で、3月6日月曜日の午前に発生した。引き金は、構内ネットワーク（LAN）の更新だった。もともとは 10Mビット/秒（bps）のイーサネット・スイッチ（SW）でLANを構築していたが、そのSWは今春にサポートが終了する。このため昨秋から、センター内にある数十台のSWを、100Mbpsの製品に段階的に取り替えてきた。3月4～5日の週末に最後の6台を交換し、全面刷新を終えたはずだった。6 台は、紙幣の出し入れを制御するアプリケーションが動くUNIXサーバーの周辺に位置するSWである。

　SWの交換後は当然、pingコマンドを使ってクライアント機からサーバーへのアクセスを確認するなどして、LANが正常に動いていることを確かめた。ところが翌月曜日、制御システムを起動して1時間30分ほどした午前9時30分ごろから処理の遅延が出始めた。紙幣の入出庫を指示しても、アプリケーションがなかなか応答しなくなったのだ。「その1～2時間後には、ほとんど応答しなくなった。ホットスタンバイのバックアップ機も同様の状態だった」（穂苅裕久発券局審議役）。

　後日調べたところ、原因はサーバー上で、アプリケーションが利用できるメモリーが極端に少なくなっていたことだった。LANから受信したパケットをためておく「受信バッファ」と呼ぶ領域がメモリーの多くを使った結果である。受信バッファは、大量のパケットを受け取るなどすると、その領域を拡大するようになっていた。

　実は、週末に設置した新SWのうち数台に不具合があった。ネットワーク内でループが構成されるのを防ぐ「スパニング・ツリー」機能にバグがあり、LAN に不要なパケットを大量に流していた。これがUNIXサーバーにも到達。「100Mに高速化したことも、サーバーが瞬間的に受け取るパケットが増えた原因になった」（穂苅審議役）。その結果、使えるメインメモリーが減ってしまったのだ。

　疑問なのが、受信バッファの領域には上限がなかったのかということ。日銀はシステムに関する詳細は公開していない。分かっているのは、OSが「HP- UX 11.0」であることと、「システムのトランザクション量が少ないため、搭載メモリーも多くない」（穂苅審議役）こと。日本ヒューレット・パッカードによれば、HP-UX11.0は1997年の投入当初、受信バッファの領域に上限がなかった。その後パッチを提供し、受信バッファの上限を設定できるようにした。SolarisやAIXなど他のUNIXも現バージョンを見る限り、この機能を備えている。

　日銀は発券センターのサーバーにパッチを適用していなかった模様だ。ベンダーとともに実施した再現テストでは、大量のパケットをサーバーに送りつけると、受信バッファの領域がメモリーいっぱいになることを確認できたという。

　発券センターが授受している紙幣は、1日数百億円と言われる。日銀は障害が発生した6日午後から7日の営業終了まで、東京・日本橋本店での人手による取り引きに切り替え、何とか乗り切った。穂苅審議役は「金融機関にはご迷惑をおかけしたが、（人手の）バックアップ体制で混乱はなかった」と胸をなでおろす。ただし、UNIXサーバーのOSには一切手を入れない考えだ。「システムが制御している機械設備などに影響があることさけるため」（同）である。

　今回のトラブルは、旧バージョンのシステムにも思わぬリスクが内在していることを示している。現時点で問題なく稼働していても、何らかのきっかけでリスクは顕在化する。常にパッチなどの情報収集に努め、都度、対処する必要性を再確認すべきだ。