記者の眼 判明 ANA システム障害の真相 2016/04/12 井上英明 = 経コンピュータ 型のシステム障害の詳細が えてきた 全 本空輸 (ANA) が 2016 年 3 22 に起こした国内線旅客システム ANACore( エーエヌエーコア ) のシステム障害では全国 49 の空港で搭乗 続きができなくなり ANA と提携航空会社 5 社の合計で 719 便 7 万 2100 以上に影響を及ぼした インターネットや予約センターでの予約などもできなかった 搭乗 続きなどでごった返す全 本空輸のカウンター (3 22 午前 11 時 40 分ころ 新千歳空港 ) [ 画像のクリックで拡 表 ] 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 便だった
空港ではその後 航便が相次いだ ANA 広報は 航の判断については ( 空港など ) 代替交通機関を利 しやすい ( 空港にいる ) お客様に対して早めに情報を提供し お客様の時間ロスを最 限にするという点も考慮している と話す ただ 航を判断する際の主目的は 最初は機材繰りによってダイヤの乱れが 引くのを防ぐためであり その後は空港にお客様が滞留するのを防ぐためにやむを得ず決定する と話す 不具合発 と対処の経緯 全 本空輸の資料を基に編集部が作成 [ 画像のクリックで拡 表 ] DB サーバーの停 は 2 パターンあって 両 とも仕様通り と ANA は取材で答えた まず最初の 3 台が停 したのは RAC の管理通信がタイムアウトで異常終了した (ANA) ためだ データの同期処理が正常に進んでいないと判断して DB サーバーを 動停 する機能が働いた 最後の 1 台が停 したのは Oracle DB を監視しており タイムアウトが発 した ( 同 ) ため これも Oracle DB が正常に動作していないとして 動停 機能が働いたという ANACore は冗 化を徹底 さらに HPE のクラスタリングソフト HP Serviceguard で RAC のクラスタリングを監視 構成し 製作所の運 管理ソフト JP1/Integrated Management でシステム全体の機器を監視していたようだ 今回の障害時 具体的にどのソフトでどういったアラートが出ていたかは明らかではない 4 台停 から約 40 分後の午前 8 時 59 分 ANA は DB サーバーを 1 台再起動した だが複数台起動すると不安定になる状態が変わらなかった そこで ANA は 4 台停 から約 1 時間後の午前 9 時 27 分 DB サーバー 1 台での縮退運転を決めた ANACore はもともと 1 台の DB サーバーでシステムの全機能を使える設計にしてあったという ただし動かす機能を搭乗 続きに絞り ご迷惑をお掛けしているお客様への対応を最優先にした (ANA 広報 ) 予約や販売 Web サービス 他社連携といった各種機能は起動させなかった 縮退運転後 動チェックイン機や係員が使う端末が少ない 規模空港では搭乗 続き機能がすぐに復活したという 空港など端末台数の多い空港でも端末の再起動を順次進めた カウンターでの混乱は続いていたが 午前 11 時 30 分にシステム的には搭乗 続きが復旧した
1 でシステム復旧 2 で再発防 縮退運転後 ANA は原因の特定を急いだ 監視システムのログなどから DB サーバー アプリケーションサーバーと順に障害を疑い 異常がないと判断した 残ったのがインターコネクトのスイッチ Catalyst 4948E だった 本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ 不具合が再現した (ANA 広報 ) スイッチも冗 構成を採っていた 本来は スイッチが故障すると 故障シグナル を発信し 予備機に 動的に切り替わる設計だった (ANA) だが 今回は故障しているにも関わらず 故障シグナルを発信しなかった 故障シグナルとは ANA によれば SNMP(Simple Network Management Protocol) によるメッセージ通知 という これを運 監視システムで受け取っていた 故障内容は厄介だった 完全に停 したわけでなく 動作が不安定になった (ANA 広報 ) という 半死 の状態だったのだ 稼働開始から約 3 年 スイッチが故障により 動的に切り替わったことは 度もないという スイッチの故障が分かった時点で ANA はすぐにシスコに連絡 代替機を取り寄せた 故障機と予備機 代替機は 同 型番 同 ファームウエア (ANA) だったという 代替機を取り寄せた理由を ANA は 念のためスイッチの健全性を確認するため と説明する 予備機はオンライン状態で稼働しており 事前 ( の健全性の ) 確認ができない状況だった (ANA) 午後 0 時 46 分には予約発券業務を 午後 8 時 10 分には Web 予約や Web サービスを復旧させつつ 並 して代替機の健全性を確認し 翌 3 23 午前 1 時 14 分に故障機と代替機を交換 午前 3 時 5 分には DB サーバーを 4 台構成に戻し 午前 4 時 14 分には他社接続など全サービスを復旧した 障害検知から全復旧まで 24 時間 30 分で済ませただけでなく その翌 3 24 には再発防 策を打つ スイッチが故障シグナルを出さない場合でも DB サーバーからスイッチ故障を検知できるよう改善した (ANA) 1 年に及ぶ製品のバグ出しテストをすり抜ける ANACore で使っていた Catalyst 4948E はなぜ 故障シグナル を発信しなかったのか ANA 広報によれば 4 11 時点でもシスコで検証中という 世界初の事象であり 機器固有の問題である可能性が いという報告を受けている と明かす 同スイッチは 2010 年 6 の発売開始以降 世界で 4 万 3000 台 うち 本で 8700 台を販売しているという
今回の障害は 2013 年 2 に ANACore を稼働して以来 初めての きなトラブル ANACore の開発ベンダーは 本ユニシスである ANA は国内旅客システムを 1978 年稼働の RESANA 1988 年稼働の able-d と ユニシスのメインフレーム上で Fortran で構築したシステムで稼働させ 本ユニシスが構築を担当してきた ANACore の構築プロジェクトが始まったのは 10 年前 2006 年 4 のこと オープンシステムプラットフォームの環境でメインフレームと同等のサービスレベルを実現すること ( 本ユニシス ) をゴールとした ANACore のプロジェクトが始まった翌年の 2007 年と翌々年の 2008 年 規模なシステム障害が起こる 2007 年 5 には約 7 万 9300 に 2008 年 9 には約 6 万 8000 に影響が及んだ 2007 年 5 に発 した 規模なシステム障害時もシスコのスイッチ不具合が原因だった ( 関連記事 : 会 詳報 ANA 障害の原因判明 世界 4 例のスイッチ故障がきっかけ 対応も遅れた ) 本来のゴールと発 した障害を踏まえ ANA と 本ユニシスは ANACore 構築に当たり 製品に潜む不具合のたたき出しに注 していた インフラ部分の製品テストを 1 年にわたって実施し 複数製品から 30 個以上の潜在的な不具合を発 したという ANA によればこの製品テスト時には今回故障した Catalyst 4948E を使っており スイッチは 15 項目にわたってテストした という さらに Catalyst 4948E の保守サポートは 2018 年に終わることもあり 既に機器の更新計画も てていた 実は Catalyst 4948E は当初想定の機器では無かった 設計時は Catalyst 4948E と同じく 1000Mbps の処理性能を持つ下位機の Catalyst 2960 を使う予定だった 本ユニシスはベンチマークでインターコネクトのトラフィックが最 で数百 Mbps になると分かったため これを最 100Mbps に抑えるよう 便名や操作端末などによって処理する DB サーバーを事前に指定する 夫を施していた だが 事前テストで DB サーバーの起動時に遅延する事象が られたという そこで Catalyst 2960 に加え Catalyst 3750 と Catalyst 4948E で DB サーバーの台数を増やしながら性能テストした結果 Catalyst 2960 は DB サーバーが 3 台以上になるとインターコネクトで使う UDP パケットの処理能 が極端に低下することが分かった これにより ANACore で使うスイッチを Catalyst 4948E に決めた 単位時間のパケット処理能 はメーカーが公表していない 機器選定の検証段階で確認する重要性が分かった ( 本ユニシス ) ANA は よくやった のか ANA ホールディングスの 野坂真哉社 は 2016 年 4 1 ANA グループの 社式でこう話した 全ての関係する役職員が全 で
対応と復旧にあたりましたが 多くのお客様にご迷惑をおかけし 厳しいお叱りをたくさん頂戴しました 原因を究明し 再発防 策をとりましたが お客様の揺らいだ信頼を回復するため 引き続き全 を挙げていきます 野 は今回のシステムトラブルで 1 カ 20% の報酬を 主返上している 今回のトラブルで ANA は 3 億 6000 万円の逸失収 が発 した (ANA 広報 ) 本ユニシスに対し 損害賠償請求を検討している ( 関連記事 :ANA システム障害で 本ユニシスへの損害賠償検討 ) ANACore の瑕疵担保責任期間は 稼働後 1 年であり 既に期間は過ぎている とした上で ANA 広報は 4 11 時点で 損害賠償の根拠は 本ユニシスとの契約に基づくものであり 結論を出す時期も含めて現在検討中 と話す 3 20 に ANA が障害原因を公表したニュースには多くの反響があった 記者には ANA の障害対応は称賛に値する という識者からのメールが届き ニュースに対するソーシャルメディアの反応を ても障害の原因究明の早さや復旧までの早さに驚き 称賛する声が多かったように思えた スイッチの 世界初のバグ を 踏み抜いた ANA の不運に同情する声や 作業で搭乗券を発 できる訓練を積んでいるという BCP ( 事業継続計画 ) の出来の良さを褒める声もあった 年 1 回の e ラーニングや着任時の座学などを通して 全空港の旅客係員全員がシステムを使わずに対応する訓練を最低 1 回は受講することを義務付けている (ANA 広報 ) 記者も障害当 に取材しながら復旧の早さに驚き 原因公表が早かったことにも驚いた ANACore のプロジェクトはコスト で決して順風満帆ではなかった 記者は過去に 本ユニシス幹部に聞いたことがあるものの 現場ではミッションクリティカルなシステムを運営する責任をステークホルダーが 分認識し かつ過去の障害を踏まえて 障害対応 順を 分整備していたことがうかがえた で 信頼システムとしては仕組みが りない と指摘するアーキテクトもいた 本有数のミッションクリティカルシステムをいくつも 掛けてきたこのアーキテクトは ネットワーク機器の間 故障は確かに厄介で頭が痛い と認めつつ 規模システムであれば何度か経験する問題であり 信頼性を追求するのであれば 複数 段での検知や切り替え 段 場合によっては 動での切り替え 順を持つべきだ とした ミッションクリティカルであれば製品の潜在バグを つけるテストを当然実施すべきだし いくら製品を 叩い ても 故障シグナル の機能だけに死活監視を依存する限り その機能 体が SPOF (Single Point of Failure: 単 障害点 ) になる 今回 DB サーバーからの監視を加えた再発防 策は 複数経路での監視に当たる
とこのアーキテクトは話す 間 障害の検知には 業務部門の利 者と同じ経路 同じ操作でシステムの稼働状況を常時監視するような仕組みも有効と指摘している 障害対策 障害復旧で ANA はよくやったのかそうでないのか どの程度のコストを掛けて どの程度の信頼性を どういったアーキテクチャーで実現するのか 同じケースは つとしてないが 分の現場だったらどう振る舞えるのか 読者の皆さんはどう考えるだろうか