ニュース
au版iPhone/iPadのメール障害、その原因は
（2013/4/25 10:44）
KDDIは、4月16日および17日～19日に発生した、iPhoneおよびiPadでのメールの通信障害について、その原因を発表した。なおメールデータの消失はなかった。
原因として、事前の検証や試験が不足していたこと、障害発生時の対策が不足していたこと、さらに再起動したときの影響についての考慮が不足していたことが、長期にわたる障害を引き起こしたと分析し、KDDI側に原因があると説明。iPhoneの増加は影響していないとしている。
同社では25日、都内で会見を開催。KDDI取締役執行役員専務で技術統括本部長の嶋谷吉治氏から説明が行われた。同氏は、会見冒頭、「お客様、関係の皆様にご迷惑をおかけし、大変申し訳なく思っている。先の年末年始にLTEの設備で大きな障害を起こし、これまで改善活動を行ってきたが、今回、メールでの障害が発生し、改善活動が不十分だったと強く認識している。心よりお詫び申し上げます」と謝罪した。
今回の通信障害では、16日に、auのiPhoneとiPadで、Eメールのリアルタイム送受信を行っているユーザーで、メールが利用できなくなった。その後復旧したものの、19日2時54分まで、利用しづらい状況に陥った。
KDDIでは、事象の原因が判明したことを受けて、事前の検証体制の徹底化、復旧手順の確立、新たな対策ツールの導入などを行う方針。これらにかかる費用は、3億円程度になると見られている。
リアルタイム送受信での新機能に向けた作業
auのモバイル向けメールサービスとしては、Androidおよびフィーチャーフォン向けのサービス、iPhoneでのMMSやIMAPと呼ばれる方式でのサービス、そして今回通信障害の影響があったリアルタイム受信といったサービスが用意されている。
他社から送られてくるメールは、インターネット経由でいったんKDDI内の中継サーバーに繋がり、そこからAndroid/フィーチャーフォン向けシステム、MMS/IMAP向けシステム、リアルタイム受信向けシステムへとメールデータは流れていく。
リアルタイム送受信システムは、マイクロソフトの製品である「Exchange」で提供されており、同じ構成の設備が2つ用意されている。これは余裕を持たせる（冗長）ための構成ではなく、ユーザー数にあわせて用意されている。今回は2つのうち、一方の設備で障害が起きており、もう一方は無事だった。
同社によれば、今回の事象は、まずEメールのリアルタイム送受信システムをバージョンアップする作業中に発生した。このバージョンアップは新機能を提供する目的で実施された。新機能の内容は明らかにされていないが、今夏、導入される予定。障害はあったものの、原因と対策がはっきりしていることから、新機能の導入スケジュールは予定通りとされている。
障害拡大を招いた第1の事象
障害が発表された16日の段階では、同日8時8分～13時29分に利用できなかった、と案内されていた。しかし今回の会見で、それ以前の段階に小規模な障害（第1の障害）が発生していたことが明らかにされた。その第1の障害は、その後発生する第2の障害に影響を与え、障害が拡大する一因にもなった。
KDDIでは、15日から16日に切り替わるころから、iPhone/iPad向けのリアルタイム送受信のシステムのバージョンアップを行う方針だった。こうしたバージョンアップは2年に一回程度、行う規模とのこと。バージョンアップ作業にあたり、メールアドレスの変更など一部機能は停止しつつも、メールはニーズの高いサービスということで、メールそのものは中断せずに「旧→新」へとシステムを切り替えていく手順となっていた。しかし、16日0時35分、プロキシサーバーにおいてユーザー認証のエラーが発生した。これにより、一部のユーザー（200人）でメールが利用できない形となった。
調査したところ、ユーザー認証を行うサーバーで異常が見つかった。ユーザー認証サーバーはおおもとのデータとなる「マスタ」と、その複製である「レプリカ」と2つのサーバーがある。本来ならマスタとレプリカ内のデータは同じはずだが、エラー発生後の調査ではマスタとレプリカのデータが一致しない形となっていた。不一致が起きた原因は、その後の調査により、レプリカが参照するサーバーが本来のマスタサーバーではなく、新機能追加用のマスタサーバーになっていたためと判明した。
「旧来のレプリカが新サーバーのマスタから複製する」という事態は想定されておらず、想定外の事態を招いたのは手順書の記載にミスがあり、投入すべきコマンド（命令）が間違っていたことが原因だった。KDDIでは、バージョンアップ作業について事前に試験を行い、手順書の検証などもベンダーを交えて行っていたが、今回の事態を招くような状況は考慮していなかったと説明。事前の検証・試験の不足によるものと結論付けた。
この第1の障害により、旧来の設備のうちユーザー認証サーバーのレプリカは役に立たない状況に陥ったが、データが無事である新サーバーのレプリカへ切り替えていくことで、徐々に認証エラーは収まり、第1の事象は、16日1時41分に収まった。
メールが利用できない
第1の事象がおさまったことで、作業を続けていたKDDIだが、新しいプロキシサーバーへの切り替え中、タイムアウトエラーが発生した。このタイムアウトエラーの原因は明らかになっていない。またユーザーの利用に影響はなかったものの、第1の事象があったことも踏まえ、新バージョンへの移行はいったん中止すると決定。旧来設備のマスタサーバーへの切り替えを進めることにしたが、その切り戻し作業中に新サーバーの1つのハードウェア（ディスクコントローラー）が故障してダウンした。新サーバーのハードウェアは、通常、4つの設備（四重化）で運用しているが、今回はそれを半分ずつに分けて、一方を旧来の現行サーバー、残りを新バージョンのサーバーとしていた。新バージョンのサーバー2つのうち1つがダウンした形となったが、残ったサーバー1つの処理能力であれば切り戻し作業はこなせる、とされ、作業は続行された。
その想定は、ユーザーが本格的な活動時間を迎える朝6時ごろまでという前提に立つものだった。しかし時間は過ぎていき、多くのユーザーがiPhoneを積極的に利用しはじめ、トラフィックが上昇した朝8時8分、残っていた新サーバーの1つも過負荷によってダウン。ここで、メールが利用できなくなった。
KDDIでは、復旧作業を進め、約5時間後の16日13時29分、復旧させることに成功した。第2の事象を招いた要因としては、先述したハードウェア故障がある。また残った設備でこなせるという判断は、結果として甘い見通しだったことになるが、KDDIの嶋谷氏は「フェイルセーフの考え方が甘かった」と反省すべき点と語った。第2の事象では、最大で約288万人が影響を受けた。
焦りが招いた第3の事象
第2の事象を復旧させるため、メールデータが入っているメールボックスサーバーの再起動が実施された。これにより、うまくサービスが復旧したサーバーもある一方、一部のサーバーでは負荷が高いままとなり、利用しづらい状況に陥った。この障害は、2日以上続くという異例の長さ。KDDIでは、負荷の高い処理を一時停止したり、メモリリソースの割当を変えたりするなどメールデータの消失を防ぎながら対処しようとしたが、1日半、その作業を行っても事態は改善しなかったため、メールボックスサーバーへ流れ込むメールを制御。時刻も深夜になっていったことで、状況が改善し、19日2時54分、利用しづらい状況は改善された。
メールボックスサーバーは30台構成で構成されるシステム（1番）と、32台構成のシステム（2番）、計62台という形。このうち24台は、一気に再起動をかけたため負荷が高まり、ディスクとのインターフェイス（I/O）がボトルネックとなって、処理が進まなかった。1番のシステムはRAID（レイド） 6、2番のシステムはRAID 0/1という仕組みを採用している。RAIDとは、複数のハードディスクを組み合わせて、データ消失を防ぎやすくする仕組み。今回のKDDIの用いている内容は、一般的に、RAID 0/1は高速処理ながら故障にはやや弱く、RAID 6のほうが故障に強いとされるが、KDDIでは、RAIDの構成による違いが障害を招いたのではなく、一気に再起動したことで処理が進まなくなったことが原因と分析しており、再起動する手順での考慮すべき点が不足していた、としている。一気に再起動させたのは、5時間以上に及んだ、第2の事象をなるべく早く復旧させることが優先されていたため、だという。
第3の事象の影響を受けた最大127万人の大半は、iPhone 4Sユーザーと見られるという。ディスクとのインターフェイスがボトルネックとなり、その後の流量調整で障害から脱した形だが、今後の対策としてiOS搭載機器側からのリクエストの制御など、端末側の仕様変更をアップルに求めるかどうかという点について、嶋谷氏は「今回はあくまでKDDI側のシステムによるもの。iOS側に起因するものではなく、アップルにも仕様変更などは求めない」と語った。
連絡先データにも影響
メールサーバーの障害により、そのサーバーに情報を格納する連絡先情報にも影響が及んだ。Exchangeの仕様として、メールボックスサーバーに連絡先データが保存され、iPhoneやiPadとサーバーは定期的に同期している。
しかし、メールボックスサーバーが利用しづらい状況になった第3の事象では、同期が一時的にできなくなったiPhone、iPadでは、端末内の連絡先データが消去され、一時表示されない、という状況となった。ここで1件でも新しい連絡先を追加すれば同期処理があらためて発生し、サーバー内にあるデータが手元のiPhone、iPadに反映される。このため、KDDIでは、障害発生後の23日、こうした復旧手順を案内していた。
一方、昨年6月27日以前に作成された連絡先情報は、サーバー上では保管されていない、という仕組みだった。これは、たとえばauのiPhoneが登場した直後に購入していたユーザーが対象となる。同期がうまくいかなければ、先述した通り端末内の連絡先データが消去されてしまうが、6月27日以前に作成されていた連絡先情報は、端末内にしか存在しないにもかかわらず、消去され、復元できない。
この脆弱性は既にKDDIでもユーザーへの周知を図っていたとしているが、一方で、周知は不十分だったとも認めている。今回の障害では、約4万件もの問い合わせがありそのうち連絡先が見えない、使いづらいという問い合わせは2400件に及ぶ。さらにデータが消去され復元できないという申し出は約180件。この180件全てが今回の事象の影響かどうか確定はしていないとのことだが、2012年6月27日以前にauのiPhoneを使い始めていたようなユーザーは、今一度、連絡先情報が失われていないか、確認したほうが良さそうだ。
今後の対策
KDDIでは、3つの事象それぞれへの対策も固めており、今後順次実施していく。4月末まではあらためて手順書をチェックして、ベンダー、KDDIとの間での相互チェックを強化するほか、事前の検証や試験内容を見直す。メールシステムだけではなく、社内の全てのシステムに対しても5月末までに、そうした事前の検証体制の強化を図る。
ハードウェア故障の分析や今後の対策、あるいは流量調整ツールの導入なども図る。流量調整ツールの導入など新たな取り組みでの費用として3億円程度の設備投資が想定されている。
質疑応答で、大規模なシステムを自社で抱えることの是非を問われた嶋谷氏は「（他社からまるまる購入して運用するほうがよいのでは？ という質問に）そう言われても仕方ない。今回の事象は重く受け止めている。しかし、新しいサービスを柔軟に提供することなどを考えると、KDDIの技術陣としては引き続き頑張りたい。今の指摘を覆すよう頑張りたい」とコメント。
LINEなど新たなメッセージングサービスが人気となるなか、「“キャリアメールの終わりの始まり”ではないか」と指摘する記者からの質問に対して、依然としてニーズや要望は強く、引き続きサービスを提供していきたいと意欲を見せた。なお、会見後、あらためて嶋谷氏に確認したところ、最近のメールの利用傾向として、その利用量はさほど減少しておらず、横ばいと言える状況とのこと。
総務省に対しては、障害発生中もたびたび報告しており、今後1カ月以内に正式な報告を行うとのこと。
