判明、ANAシステム障害の真相

搭乗手続きなどでごった返す全日本空輸のカウンター（3月22日午前11時40分ころ、新千歳空港）

[画像のクリックで拡大表示]

　大型のシステム障害の詳細が見えてきた。全日本空輸（ANA）が2016年3月22日に起こした国内線旅客システム「ANACore（エーエヌエーコア）」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。

　ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。

4台のSuperdomeをRACでクラスタリング

　今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース（DB）サーバーが停止したというもの（関連記事：ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン）。今回、弊誌の取材でシステム構成が明らかになった。

　DBサーバーは米ヒューレット・パッカード・エンタープライズ（HPE）のUNIX「HP-UX 11i B.11」を搭載する「HP Integrity Superdome」を使い、データベース管理システム（DBMS）は米オラクルの「Oracle Database 11g」を使っていた。ANAが使うSuperdomeは1.66GHzのItanium2を12個と、64Gバイトのメモリーを搭載する。

全日本空輸の国内線旅客システムの構成図

全日本空輸や日本ユニシスの資料を基に編集部が作成

[画像のクリックで拡大表示]

　4台のDBサーバーはオラクルの「Oracle RAC（Real Application Clusters）」を使ってクラスタリングして、可用性と性能を向上させていた。分散したDBサーバーが協調して処理を進める場合、ストレージ上のデータを共有する「シェアードエブリシング（共有ディスク、シェアードオールとも呼ぶことがある）」や、それぞれのDBサーバーにのみデータを持つ「シェアードナッシング」と呼ぶアーキテクチャーを採る。RACの場合は前者の「シェアードエブリシング」である。

　ANACoreではストレージは2台のミラー構成を使っている。4台のDBサーバーはそれぞれに同時に書き込む。この時、ストレージ上のデータが一貫性を保って参照・更新されるように、4台のDBサーバーは高速な専用ネットワーク（インターコネクト）を通して、メモリー上に展開したデータなどを転送し合う。今回、インターコネクトで使っていた米シスコのスイッチ「Catalyst 4948E」が故障し、最終的にDBサーバーの4台停止につながった。

1時間で縮退運転開始

　ANAが3月20日に公表した資料と取材の回答結果、日本ユニシスがANACore稼働後に公表した技術論文集「ユニシス技法」の通巻118号「特集：エアラインリザベーション」を基に、改めてシステムダウンと復旧の経緯を時系列でみていく。なおユニシス技法の内容はANAも確認済みで、システム構成も基本的には変わっていないが一部で機器を増設しているという。

　最初のDBサーバーが停止したのは3月22日の午前3時44分。ここから1台、また1台と停止し、約4時間40分後の午前8時22分には4台とも停止した。始発便はとうに出発している時間帯で、全国の空港で搭乗手続きに遅れが生じていた。最初に欠航したのは羽田空港を午前9時55分に出発する秋田空港行き403便だった。