ANAのシステム障害から考える「安心・安全・安定したシステム」の構築に必要なこと

ANAは4月3日に発生した同社の国内線システム不具合について、記者向けにオンラインでの説明会を開催。あらためてシステム不具合の原因や再発防止策について発表がありました。

今回のシステム不具合が発生したのは、予約・販売・搭乗手続き・顧客への情報配信につながっている国内旅客システムを支援する「予約管理支援システム」です。国内旅客システムは同じ機能の2つの系統(A系・B系)を構築していて、A系とB系は定期的に入れ替えて稼働させているほか、片方にトラブルがあった際に、もう片方へと切り替えられる仕組みになっています。

▲国内旅客システムは同じ機能のものを2系統用意し、定期的に入れ替えて稼働させている

A系・B系にはそれぞれ2つのデータベースを有していて、データ抽出を行っているのですが、今回のシステム不具合は、このデータベース上で起こったもの。ANAの説明では、データベースサーバーで行っていたパラレルクエリ(並列処理)に際して、予期せぬエラーが発生したとのことです。

予約管理支援システムとデータベースは30分おきに最新のデータを抽出。さらにデータベース1とデータベース2も同期を取っている状態です。これに複数のデータを短時間で抽出できるよう、並列処理をしていたわけです。

今回、動作していたA系のデータベース1で「予期せぬエラー」が発生し、データベース1がフリーズ状態となってしまいました。そのため監視プログラムが異常を検知し、データベース1に対して停止を指示。データベース2は処理待ち状態となったのですが、データベース1がフリーズのため停止処理にも時間がかかり、データベース2も処理待ち件数が増加してしまったため高負荷状態に。

▲予約管理支援システムの並列処理に予期せぬエラーが発生し、フリーズ状態に

その結果、監視プログラムはデータベース2にもプログラム停止を指示。データベース1、データベース2ともに自動停止となり、A系はシステムとして稼働しない状態になってしまったため、B系へと切り替わりシステムとしては稼働し始め、徐々に予約・販売・搭乗手続きシステムも復旧し始めています。

▲今回の2つのデータベースが同時に停止した経緯

時系列的には、データベース1の異常発生が4月3日の14時頃。14時16分にA系のデータベース1・2ともに同時に停止し、B系への切り替えが完了したのが15時11分となっています。15時11分の段階では原因の判明には至っていませんが、予約管理支援システムへのデータ抽出処理に問題がある可能性があったため、当該処理を18時45分に停止しているとのことです。

今回のシステム不具合では、データベースサーバーで行っていた並列処理に問題があることが判明したため、ANAは2つの再発防止策をたてています。

ひとつは並列処理をやめて、直列処理を行うこと。並列処理のほうが、多数の処理を同時に行えるため処理時間は短くなりますが、今回問題があったシステムはあくまで「支援システム」ということで、そこまでレスポンスが必要ではないため、直列処理への変更で対応するとのこと。

▲ひとつめの再発防止対策として、並列処理をやめ直列処理に

もうひとつはデータベースサーバーの監視プログラム設定を変更すること。システム障害以前は「データベースの停止時間が長い」、「データベースの処理待ち時間が超過」を監視条件にしていましたが、これを変更して「2台が同時停止をしないように」にするそうです。これにより、なにかトラブルがあってもA系からB系へ(またはその逆)の切り替えを早い段階で行うようになり、安定したシステム稼働ができるわけです。

▲もうひとつの再発対策は、監視プログラムの設定を変更

この対策で、今後は今回発生した「予期せぬエラー」は回避できるようになったわけですが、気になるポイントも。記者からの質問で明らかになったのですが、今回の予期せぬエラーは、既知のマイナーバグとして登録されており、すでにパッチも配布されているそうです。

今回のシステムは2018年から導入・稼働していますが、パッチが配布されたのも2018年とのこと。ANAはパッチをあてて対応していなかった事に対して「既知のマイナーバグとして認識はしていたが、クラスター構成を組んでいて、このエラーが発生したときに基本的にはサーバー1台がダウンしても、もう1台で運用できると判断していた。パッチを当てる場合、国内旅客システムも含めてすべて影響がないか試験も必要だった」と、エラーが起きても運用面でカバーできると考えていたようです。

またパッチ自体は今回のシステム不具合でもすぐにはあてず、直列処理で対応し「原因を引き起こさないような対策をしたほうがいいだろう」と判断しているとのこと。

実際問題として、巨大システムを稼働させながら改修するというのは、非常に難しいこと。そのため今回のANAのように「運用でなんとか対応する」というのは、わからなくもありません。ANAに限らず、こういった判断をしている企業は多いのではないかと思います。

とはいえ現代社会では自社のシステム同士はもとより、社外も含めて様々なシステムが複雑に絡み合ってサービスを提供しています。そのため、ひとつのシステム障害がまったく別のシステムが提供するサービスに影響を及ぼすという状況です。それこそMaaSは、いろいろなシステムやサービスをつなげて、快適なモビリティを提供しようというものです。

その巨大かつ複雑に絡み合ったシステムを運用面でカバーするというのは、短期的には乗り越えられるかもしれませんが、長期的にはやはり問題があります。既知のバグとして登録されているようなケースでは、運用面での対応は短期的な対処と考え、やはり根本的にシステムを改修するような対処もすすめ、常に安心・安全・安定したシステムを構築し続けていく必要がありそうです。

  • この記事を書いた人
  • 最新記事

中山 智/Satoru NAKAYAMA

海外取材の合間に世界を旅しながら記事執筆を続けるノマド系テクニカルライター。雑誌・週刊アスキーの編集記者を経て独立。IT、特に通信業界やスマートフォンなどのモバイル系のテクノロジーを中心に取材・執筆活動を続けている。

-MaaS, 中山智『旅ゆけばMaaS』
-