事前検証試験の不足と障害への対策不足が露呈、Eメール障害についての説明会を開催(KDDI)

　KDDIは25日、先日発生したEメール障害についての説明会を開催。同社取締役執行役員専務技術統括本部長嶋谷吉治氏、理事プラットフォーム開発本部長住吉　浩次氏が出席し、障害の概要、原因と今後の対策について説明した。

　まず、今回の障害について。障害が発生したのは同社のiPhone、iPad、iPad miniでEメールリアルタイム送受信システムを利用していた一部のユーザー。2013年4月16日0時35分から4月19日2時54分までの間に3つの障害が発生し、Eメール送受信サービスが利用できなくなったり、しづらい状況になったほか、連絡先情報が表示できなくなったりした。影響は全国の地域で最大288万人に及んだが、嶋谷氏によれば、Eメールのロストは今のところ確認できていないという。また、MMS、IMAPやAndroidスマートフォン、フィーチャーフォンのメールについては障害は発生しなかった。

　今回の障害は、新機能を提供するためのバージョンアップの際に発生した。3つの障害は、「手順書記載ミスによるコマンド誤り」「ハードウェア障害と二重障害時の対策準備不足」「メールBOXサーバの再起動手順の考慮不足」によって発生。事前検証試験の不足と障害に対する対策不足が露呈した形となった。なお、iPhone契約者の増加やトラフィックの増大は直接の原因ではなかったとしている。

　バージョンアップ作業は、サービス断を発生させないよう、現行設備と同構成の新バージョン設備を事前に準備し、メールBOXサーバ・中継サーバなどの接続替えにより、実施することとなっていた。

■第1の障害

　4月16日0時35分、現行プロキシサーバと現行ユーザ認証サーバ(レプリカ)との間でユーザ認証エラーが発生。最大で200人のユーザがEメールサービスを利用できなくなった。これは手順書記載ミスによるコマンド誤りによって、本来接続されることのない現行ユーザ認証サーバ(レプリカ)と新ユーザ認証サーバ(マスタ)が接続されてしまったことが原因。この接続は想定外の接続で、事前の検証試験でも発見できなかったという。この接続によって現行ユーザ認証サーバ(レプリカ)上のユーザ情報データが一部欠損し、ユーザ認証エラーが発生、結果としてEメールサービスが利用できなくなった。この時点で影響があったのは最大200人と比較的小規模な障害だった。

　障害を解消するために、現行ユーザ認証サーバ(レプリカ)と新ユーザ認証サーバ(レプリカ)の切替を行い、1時41分には認証エラーは解消された。

■第2の障害

　同社は、第1の障害が解消されたため、バージョンアップ作業を続行。現行プロキシサーバから新プロキシサーバへの切替を順次実施していたが途中でタイムアウトエラーが発生。予期せぬエラーのため、現行設備への切戻しを決定。切戻し作業中、新ユーザ認証サーバ(レプリカ)2系のうち片系がハードウェア障害でダウン。4月16日8時8分、残っていた片系も過負荷でダウンし、最大288万人のユーザがEメールサービスを利用できなくなった。

　これについて嶋谷氏は「フェールセーフの考え方が足りなかった」と障害が起きた時の対策が甘かったことを認めた。4月16日13時29分、現行ユーザ認証サーバ(マスタ)への接続変更とメールBOXサーバの再起動を実施した。なお、最初のハードウェア障害の原因については分析中とのこと。

■第3の障害

　第2の障害解消後、中継サーバに滞留した受信メールにより、62台中24台のメールBOXサーバの高負荷状態が続いた。端末からのアクセス急増も重なって、メール送受信が利用しづらい状況となった。これについて嶋谷氏は、「立ち上げ方をもう少し小分けにしていれば問題なかったが、サービス復旧を急ぐあまり一気に立ち上げてしまった。手順に問題があった」と述べ、メールBOXサーバ再起動手順の考慮不足を認めた。

　また、メールBOX内のメールアドレス、カレンダー、リマインダーが端末上から見えなくなり、「アドレス帳が消える」障害も発生。これは、端末とサーバ間の同期処理に用いる情報に不一致が生じた際、端末上の連絡先がクリアされるという仕様によるもの。障害復旧後に新規連絡先を1件追加するなどしてメールBOXサーバと全データ同期が行われれば、正常に表示されるようになる。

　しかし、リアルタイム受信サービスでは、2012年6月27日以前に作成した連絡先情報について、サーバ側にデータを預かるサービスが提供されていなかったため、連絡先の復旧はできないという。今回、障害全体の問い合わせは約4万件、アドレス帳に関する問い合わせは約2400件、その内復旧できない可能性があるものは約180件あったという。

■同社の今後の対策

　第1の障害の原因となったコマンド誤りについては、手順書チェック、事前検証試験内容の見直しなどを社内の全システムに対して実施・徹底していくとした。第2、第3の障害についてはハードウェア故障原因の分析と対策決定とともに、二重障害や三重障害発生時の復旧手順の確立、メールの流量調整ツールの導入やメールサーバ・ストレージの増強などの対策を講じていくという。

KDDIのEメール障害、「二年に一度の大規模なバージョンアップ作業中」……検証不足・障害対策不足を認める