全3569文字

冗長化の仕組みが誤作動

 ダウンした飛行計画情報の処理系サーバーは、「0系」と呼ぶ本番系と「1系」と呼ぶ待機系のアクティブ・スタンバイ構成になっている。0系がダウンすると自動的に1系がアクティブに切り替わる冗長構成だ。

 障害の通知を受けたシステム管理者が現地で確認すると、0系と1系の両方がアクティブ状態になったことがサーバーダウンの理由だと分かった。両系がアクティブになると双方で処理が走り出し、どちらの処理結果がデータの正当性を担保できているか判断できない。こうした情報を管制官に与えるのは避けなければならず、両方を強制終了する仕様となっていた。

 日本には東京のほか、札幌と神戸、福岡に航空交通管制部がある。ダウンした処理系サーバーは、東京と札幌の管制部が利用していた。東京と札幌は通常運用ではメインサーバーを共有するが、ダウンに備えてバックアップサーバーを個別に用意している。東京と札幌のそれぞれで手動によるバックアップへの切り替えに着手。札幌は午前7時26分に切り替えを終えて運用を再開した。一方、東京は午前7時26分にメインサーバーの再起動が完了したため、バックアップへの切り替えを中止してメインサーバーへ切り戻した。その後、札幌も午前7時43分にメインサーバーへ切り戻し、この時間をもって両管制部ともメインサーバーによる通常運用へと復旧した。

 なぜ0系と1系の両方のサーバーがアクティブ状態になったのか。復旧後に調査を進めた結果、システム冗長化の仕組みが誤作動したことが明らかになった。サーバーの稼働ログを解析したところ、0系サーバーに搭載されているネットワークインターフェースカード(NIC)の1つが故障していた。0系と1系が互いに死活監視の信号を送受信するためのNICだ。

図 2020年12月14日に起こった航空管制システムの障害の概要
図 2020年12月14日に起こった航空管制システムの障害の概要
死活監視用NICの故障と回線切り替えプログラムの不具合が原因だった(出所:国土交通省の資料を基に日経コンピュータ作成)
[画像のクリックで拡大表示]

 0系の飛行計画情報などを処理するアプリケーション自体は正常に動作していたが、NICが故障したことで死活監視の信号が途絶え、1系が「0系はダウンした」と見なしてアクティブに切り替わっていた。

死活監視にも不具合

 もっとも、死活監視の通信回線は2重化しており、メインの回線がつながらなかった際にバックアップ回線に切り替わる仕組みを備える。システムが本来の仕様通りに動作すれば、この仕組みで両方のサーバーがアクティブになる事態を防げるはずだった。仕様では、回線の切り替えが瞬時に実行されることになっていたからだ。ところが回線はすぐに切り替わらず、その間に0系のダウンを誤検知した1系がアクティブになってしまった。

 調査をさらに進めた結果、死活監視の通信回線を切り替えるプログラムに不具合があることが明らかになった。システムのOSやミドルウエア、アプリケーションなどで、ある特定の条件が重なると、回線の切り替えに数秒かかる不具合だ。

 今回ダウンしたのは約1年半前に運用を開始したサーバーだが、ハードウエア自体は4年近く前に製造されたものだった。経年劣化で故障が起こるリスクは避けられないにせよ、死活監視の回線切り替えが正しく動作していれば避けられたトラブルだった。江藤課長補佐も「異常系のテストシナリオをすべて網羅するのは難しいとはいえ、結果的に言えば(導入前の)テスト不足だった」と認める。

 サーバーダウンの原因が明らかになった後、国交省では他管制部のシステムについても再点検を実施。故障したNICと同じ製造ロットが使われていないかなどを確認した。死活監視の仕組みも調べたところ、福岡の飛行計画情報の処理系サーバーに同じ不具合があることが明らかになった。死活監視の回線切り替えプログラムの改修は2021年3月に完了しており、東京および福岡の処理系サーバーへの適用を2021年5月に計画している。

 改修を終えるまでに同様の障害が発生するのを避けるため、新たな仕組みも設けた。0系と1系の間を死活監視とは別系統の通信回線で接続。1系がアクティブに切り替わる際に、同回線を通じて0系に強制終了のコマンドを送る仕組みだ。当初は暫定的な措置として導入したが、改修後も万が一の事態に備えて使い続けることにした。

テスト不足の障害は過去にも

 国交省は、2008年度から航空管制を支援する各種システムの全面刷新プロジェクトを進めてきた。同プロジェクトが終わるのは2021年度の予定だ。この全面刷新が持ち上がったきっかけも、システム障害だった。2003年3月1日に発生したシステム障害は欠航205便、遅延1462便につながり、航空機の運航に多大な影響を及ぼした。

 このシステム障害を契機に、増え続ける航空便にも対応すべく既存システムの入れ替えを始めたが、航空管制システムを刷新した直後の2018年10月にもトラブルが相次いだ。システム上で運航間隔を確認できなくなったほか、今回の障害が起こったTEPSでも一部動作が不安定になる問題が発生した。当時はTEPSの復旧に2時間を要し、85便に30分以上の遅延が生じた。実はこのTEPSの問題もベンダーが本番データによるテストを実施していなかったというテスト不足が原因だった。

 TEPSを含めた現在の航空管制システムは、オープン系のサーバーやOS、ミドルウエアなどの上で稼働している。メインフレームなどの上で動いていた、かつてのシステムに比べると「まだ枯れていない」(江藤課長補佐)という。とはいえ、航空交通の安全を確保するには万全の安定運用が求められる。江藤課長補佐は「冗長構成も含めて今後も改善していかなければいけない」と話す。