【お詫び】３月２２日に発生した弊社の国内線システム不具合について
１．発生原因（弊社の国内旅客システムの構成図（概要）はこちら をご覧ください）
弊社国内旅客システムは、４台のデータベースサーバーで運用していますが、このデータベースサーバー間の同期処理を中継するネットワーク中継機の故障が原因であることが判明しました。
具体的には、ネットワーク中継機で２点の故障が発生しておりました。
(１)中継機能の故障
データベースサーバー間の同期処理が正常に完了せず、データの整合性が保たれなくなる為、データベースサーバーを自動的に停止する機能が働きました。
(２)「故障シグナル」の発信機能の故障
本来であれば、ネットワーク中継機が故障すると「故障シグナル」を発信し、予備機に自動的に切り替わる設計になっておりますが、今回は故障しているにも関わらず「故障シグナル」を発信せず、予備機に自動的に切り替わりませんでした。
２．再発防止策
(１)同一事象の検知
同一事象が再発し、ネットワーク中継機が「故障シグナル」を出さない場合でも、データベースサーバーからネットワーク中継機の故障を検知できる改善を実施しました。（2016年3月24日に実施しました）
(２)メーカーによる改善策
不具合のあった機器は、製造メーカーにおいて解析を実施し、故障個所が判明しております。
現在、製造メーカーにて改善策を検討中です。
(３)信頼性向上プロジェクトチームの設置
今回の発生原因に留まらず国内旅客システムを総点検するとともに、お客様対応の改善点を洗い出し、信頼性を向上させるべく外部の知見も活用したプロジェクトチームを設置します。（2016年4月に設置を予定しております）
同期処理に障害
ANAによると、日本ユニシス（8056）が構築した国内線旅客システムのうち、故障したのはネットワーク中継機として使用していた、米シスコシステムズ製イーサネットスイッチ「Catalyst 4948E」。一般的に、有線LANによるネットワーク上の機器などを接続するために使用するもので、障害が発生したシステムでは、4台あるDBサーバー同士を接続するのに使われていた。ネットワーク用語では、「スイッチ」と略されることが多い。
スイッチが故障したことで、DBサーバー間のデーターの整合性が保てなくなるため、自動的にサーバーを停止する機能が作動。本来であれば、スイッチが故障すると「故障シグナル」を発信し、自動的に予備機に切り替わる設計になっていたが、今回はシグナルが発信されず、予備機に切り替わらなかった。
障害発生を受け、スイッチがシグナルを出さない状況でも、DBサーバーからスイッチの故障を検知できるよう、24日にシステムを改修。不具合が発生したスイッチは、製造したシスコが解析して故障箇所が判明したため、シスコが改善策を検討しているという。
ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
ANAでは2013年2月に国内線旅客システムをメインフレームからオープンシステムに再構築して以来、初めての大きなトラブルとなる。実は旧システム時代の2007年5月に発生した大規模なシステム障害時もシスコのスイッチ不具合が原因だった
Catalyst 4948ありましたね。。
うむ、応急処置以外に、個人的にこの辺の再発防止策も考えられるではないでしょうか。
1 HWの故障が前にもあったわけですから、監視とアラートは内部と外部双方からやらないと。snmptrap(agent->manager)だけでは不十分ということがよくわかりましたね。
HW障害について、自分でも何回間接的に経験したことがあります。前々職では、97年頃東京証券取引所のシステムでCPUが壊れてサーバダウンしたというのを調査対応に行った上司の課長からききました。前職では2000年2月にplaystation.comを立ち上げ時にHUBがPS2発売オンライン予約のアクセスに耐えずに落ちました。現職は隣のPJがストレージ障害で数百万メールがぶっ飛んだのが記憶あたらしいです。
HW障害ありきでシステム設計しないといけないからね。結局HW自身のアラート機能以外の手段が絶対必要ですね。
2 そもそもアーキテクチャー的にはBCPになってるのか？データセンター一つしかないから、今回はCiscoのスイッチ、今度地震でデータセンターがやられたら結局全滅ですよね？
DBの分散によって地域間の同期遅延も課題になりますが、経験上数百msecのdelayがあります。ただトレードオフして、可用性を重視すべきではないでしょうか？
3 DBのSPOF問題、やはりDBを分割と階層化にしたほうがいいと思いますね。これは前にも書いたけど。
ここはもし事前にちゃんとやったら、ニュースのタイトルが「Ciscoの世界初バグを克服、ANAのシステムの強さ」になり、ブランドイメージ向上につながるはずですね。
4 「データの整合性が保たれなくなる為、データベースサーバーを自動的に停止する機能」があるので、そもそも停止しない方法がありますか？
情報セキュリティの完全性については、自動停止という処理がどうかなと思います。もちろんオラクルやネットワーク機器を一つのブラックボックスとして使うなら、ベンダーに依存し、障害したら損害賠償を求めるのは普通かもしれません。だた、壊れたデータをスギップして、業務を継続しながらアラートを送信して、おかしいデータを別システムに送り、リカバリーできないでしょうか？
5 4台DBサーバはrealtimeでデータ同期をとらないといけない構成ですから、当然ローカルLAN内のトラフィックが増えて、新しいネットワーク機器（バグのリスクを負う）でカバーしようとしていますね。でもそもそもスケール的には2台だけで十分だということですから、トラッフィクを減らし、hot standby 2機として別ネットワークで、少し遅れてもいいから同期取ればいいじゃないでしょうか。
とは言っても全日空の対応は感心しました。不祥事に対して隠蔽せず堂々とシステム構成を公開して、業界関係者や一般技術者にしても参考になるシステム設計運用のノウハウになるので大変ありがたいことです。
Comments