雪泥鴻爪--IT技術者の随筆

JALシステム障害、前週に追加の排他制御がデッドロックを誘発

日本航空（JAL）は2016年4月6日、4月1日に発生した重量管理システムの障害について公表した。開発元から適用されたパッチの中に、キャッシュの排他制御を追加する設計変更があり、もともと実装されていたディスクの排他制御との間でデッドロックが発生したことが引き金になった。

問題となった重量管理システムは、独航空大手Lufthansaの子会社である独Lufthansa Systems（LHS）製の「NetLine/Load」。乗客の人数や座席配置、貨物や燃料の量を基に重心を計算し、貨物の最適な搭載位置を算出して指示を出す役割を担う。JALのほか独LufthansaやカナダのAir Canadaなどが導入している。JALの場合、サーバーは東京都内のJAL拠点にあり、主要9空港からアクセスして業務に使っている。

処理Aがキャッシュへの排他制御を済ませディスクへアクセスしようとしたタイミングで、処理Bがディスクへの排他処理を掛けキャッシュを参照しようとした。このため処理Aと処理Bがお互いの完了待ちとなりデッドロックが発生。他のトランザクションも次々に処理が滞った。

NetLine/Loadを巡っては、導入直後の2014年6月5日にも障害を起こし、国内線178便が欠航、約1万4000人に影響が及んでいる。ただ、当時の障害と今回の障害は別の原因で起こったものだ。当時の障害の原因はアプリケーションサーバー内で稼働するプログラムのバグ。具体的には、便情報を更新するプログラムが不正なデータを生成することが原因だったといい、既にLHSによる改修も済ませている。

調べてみたら、JALはこのNetline Loadのローチカスタマーでもありますね。
Japan Airlines is launch customer for new load planning solution from Lufthansa Systems

Netline Loadの製品概要

この説明資料はJALのウェブサイトになかったので、もしかして報道関係者のみ公開されたものですかね。JALは被害者でこれからやれることもそんなに多くないですが、考えられるのは、

・パッチ当てる前にリリースノートを精査し、脆弱性対応など緊急度の高いもの以外の機能に対して、機能テスト結果リポートや他社利用実績を分析した上でステージング環境テストとプロダクト反映を行う。

・業務時間外に定期的にマシン再起動？

・ロックされるリソースを見える化にして、定期的監視する。一定的な時間以上にロックされた領域があったら、アラートを飛ばす。

・バックアップシステムの処理能力増強。

などですかね。。

キャッシュとDBの同期は本質の課題だと思いますが、業務フローに絡む話なのでなんとも言えません。いずれベンダーにしっかり設計してほしいところですね。