iPhone節約レシピ&ライフスタイルマガジン

写真は、ロンドンアップルストアの壁面のロゴ
*

サイト内を検索する
Loading

auの3日におよぶメール障害は、たった1つの手順書のミスが連鎖的に障害を引き起こした。

  • このエントリーをはてなブックマークに追加
  • LINEで送る
  • follow us in feedly
この記事の所要時間: 314
公開日:2013年04月25日

4月25日、KDDIは今回のメール障害について説明しました


1つの障害が3日に及んだのは前代未聞です。

これまでの経過

4月16日 08:08~13:26 今回の障害の発端となった、iphoeやipadでリアルタイムのメール送受信ができない状態が発生した。障害は、全国288万人に影響。同日夕方には苦情や問い合わせが1万件に上った。
4月17日 05:30~19日 02:54 前日の復旧後もメールの送受信の不具合の状況は改善しないまま、17日05:30から再び障害発生と発表。ツイッター上にも、メールの本文がない、メールが届かないなど多数。
4月19日 02:54~ 再び復旧も、メールが同期しない、連絡先が消えたなどの障害報告が続々。KDDIではメールの同期方法と連絡先の復旧方法を、サイトに掲載。現在に至る

KDDIの説明による原因報告

最初に生じた16日午前8時からのメール障害は、さかのぼること7時間前、「4月16日の0時35分から1時間6分の間、全国で最大200人のサービスが利用できない状況」になった事だ。KDDIの説明によると、ちょうどこの時、今年夏からのバージョンアップに備えて、ユーザーの認証サーバーのバックアップ側のプログラムの変更をおこなっている最中に手順書に記載されたコマンドのミスにより本来正規のユーザー認証データに接続すべきところが、古いユーザー認証データをが使われたという。

au_Mailerror.jpg

このエラーのために、KDDIは新バージョン用のサーバー系に切り替えて運用する一方(上記図の緑側のサーバー群)、現行のユーザー認証データの修復をおこなわれていましたが、突然新バージョン用のサーバー群に原因不明のタイムアウトが発生し、修復が終わり次第元のサーバーに切り替えを実施せざるを得なかった。さらにこの切り替え作業中に新バージョンのサーバーのディスクコントローラにエラーが生じダウン。
ちょうどこのタイミングがメール障害の始まった16日午前8時頃で、片肺飛行中にもかかわらず、メールサーバーへの負荷が高まっていた。

au_Mailerror2.jpg

この時点で、KDDIはかなり深刻な状況に直面していたがさらに深手を負ってしまったのが

日中の高負荷な状況にも関わらず、現行サーバーの切り替え作業のため、メールを処理しているサーバー62台を一気に再起動を掛けてしまう。

サーバーを切り替えるのに再起動は避けて通れないものですが、ここでKDDIの致命的な判断ミスがあったものと思われます。片肺飛行を続ける新バージョン系と切り替え途中の現行サーバー系。一刻も早く安心感を得かったのでしょう。
一気にサーバーを再起動!
このため62台のサーバーのうち、24台が高負荷状態に陥ったという。
この時間帯は、上記図中から16日13:29。

au_Mailerror3.jpg

以後、KDDIはどんどん溜まるメールの処理に60時間(2日半)を要することになります。
KDDIのサーバーはたった5時間半(8:08~13:29)の停止で、60時間も稼動し続けなければならないって事?

いくらなんでもauのサーバーは余力なさすぎ!!

あとがき

それにしても、日中のサーバー再起動、誰がGoしたんだろうか?
結局、手順書のミスが原因。この手順書はベンダー側とKDDI側で2重にチェックしてあるという。
KDDIの現場が忙しすぎるのだろうか?
auの技術者2~3人ぐらいは死んだだろう。

rssアイコン

当ブログの最新情報を配信しています。右のボタンでニュースアプリ「Feedy」に簡単登録できます。


  • このエントリーをはてなブックマークに追加
  • 96 follow us in feedly
公開日:2013/04/25 カテゴリ:故障情報
  • Apple Watch情報
    価格・スペック情報
    お得キャンペーン情報
PAGE TOP ↑