@Aviation_Wire
Aviation Wire
RSS
日本航空（JAL/JL、9201）は4月6日、機体の重量や重心などを計算する「重量管理システム」で1日に起きた障害について、プログラムの不具合が原因だったと発表した。
障害が起きたのは、貨物搭載量や乗客が座る席の位置などの搭載計画や、機体の重量や重心計算などを行う重量管理システム「Netline Load」。ルフトハンザ ドイツ航空（DLH/LH）の子会社ルフトハンザシステム製で、2014年1月に導入した。
—記事の概要—
・デッドロックが発生
・バックアップ環境強化へ
デッドロックが発生
システム障害が復旧し振替手続きなどで混雑する羽田空港のJALカウンター＝16年4月1日10時21分 PHOTO: Tadayuki YOSHIKAWA/Aviation Wire
今回の障害は1日午前7時48分ごろ、今年3月23日に変更された重量管理システムのプログラムの不具合により発生。機体の重心を考慮し、貨物コンテナを貨物室のどの位置に搭載するかなどを指示する「搭載計画書」をJALの搭載管理者が作成時に、重量管理システムが稼働するアプリケーション（AP）サーバーで、異なる2つの処理が同時に行われた際に起きた。
APサーバー内で参照頻度の高いデータを置くメモリー領域である読み込み用キャッシュ上で、同時進行していた2つの処理が正常に行えなくなった影響で、ほかの処理も進まなくなった。その後、サーバーの再起動などを実施し、午前9時40分ごろ復旧した。
JALによると、問題が起きたAPサーバー上のキャッシュは、3月23日のプログラム変更前は、処理の進捗に応じてデータを上書きしたり出来るようになっており、一つの処理がデータを占有することはなかったという。
今回の障害発生時は、先に始まった処理がキャッシュ上のデータを占有してしまい、ほかの処理が同じデータにアクセスできない「デッドロック」状態になっていたという。JALはルフトハンザシステムに対し、こうした処理方法の変更は依頼していなかった。また、障害発生時は便数や乗客数が目立って多かったわけではないという。
バックアップ環境強化へ
JALのシステム障害復旧と欠航や遅延を伝える羽田空港の出発案内＝16年4月1日10時20分 PHOTO: Tadayuki YOSHIKAWA/Aviation Wire
ルフトハンザシステムによる不具合プログラムの改修は、月内にも実施予定。改修を終えるまでは障害が起きやすいデータ処理を避けるほか、サーバーがプログラムの稼働状況を監視し、デッドロックを検知した際は回復措置を講じるようにした。
重量管理システムはAPサーバー2台と、搭載指示書や重心位置データが入ったデータベース（DB）サーバー2台の計4台を中心に構成。各サーバーを2台ずつで構成にしたことにより、冗長性を確保した。
APサーバーには出発機が搭載する燃料の量や乗客のチェックイン状況、搭載する貨物のデータなどが社内システムから集まり、空港にいる搭載管理者はイントラネット上に6台ある社内向けウェブサーバーを経由して使用する。
重量管理システムを使用する搭載管理者は羽田と成田、新千歳、中部、伊丹、関西、福岡、鹿児島、那覇の国内9空港におり、その他の空港は羽田などで業務を担当している。
今回の障害発生時に切り替えたバックアップのシステムは通常とは別系統のもので、サーバーの台数など物理的なシステム構成は同一なものの、処理能力は通常使用するものと比べて7-8割程度だった。
システム障害発生時も運航出来ていた便もあったが、JALグループ全体で50便が欠航し、約7000人に影響が及んだことから、バックアップ環境の処理能力を強化する。また、システム障害以外が原因だった可能性がある便も含めると、JALグループ全体で最大137便に遅れが発生し、約1万7000人に影響が出た。
JALの重量管理システムでは、導入直後の2014年6月5日にもプログラムの不具合による障害が発生。JALによると、今回とは不具合の発生箇所が異なるという。
国内の航空会社では、全日本空輸（ANA/NH）で3月22日に国内線旅客システム「エイブル」でも障害が発生。4台あるDBサーバー間を接続する「イーサネットスイッチ」の故障が原因だった。
関連リンク
日本航空
Lufthansa Systems
16年4月1日のシステム障害
JALのシステム障害復旧、国内線欠航46便 6670人影響、2日は通常通り（16年4月1日）
14年6月5日のシステム障害
・JALのシステム障害、原因はプログラム不具合（14年6月10日）
ANAでも16年3月22日にシステム障害
・ANAのシステム障害、イーサネットスイッチが故障 篠辺社長ら減給（16年3月30日）