KDDIメール障害 原因報告

先日4月17日頃に発生していたauのiPhoneでのメール障害について、KDDIが原因を発表しました。
この発表に関する各ニュース記事はこんな感じ

朝日新聞 作業ミスや機器の故障が原因
日経新聞通信設備更新の手順ミスなどが原因
NHK手順書に誤りがあり、それにしたがって作業を進めたことが原因

と、作業手順書の誤りが主原因だったと報道しています。

さて、KDDIの発表資料を実際に読んでみます。
Eメールリアルタイム送受信システムの障害について

2.3MBのPDFファイルですが、PowerPointで作成した資料のような体裁です。こういう発表資料ってWordで作るべきだと思うんだけど、なんでPowerPointで作っちゃうんだろう…は置いておいて、スライド11枚の発表資料をめくってみます。

新サービスを提供するための作業を開始したところ、いくつかの問題が発生して、結果として大規模障害に発展してしまったということです。

障害は大きく3個発生しています。

【事象(1) ユーザ認証サーバの接続先誤りによる一部ユーザの認証失敗】

これは単純なコマンドミス。影響が200人66分と比較的小さく済んだ障害で、後続の障害とも関連がないようです。ニュース各社が発表している手順書の誤りは、このミスコマンドを記載した手順書のことです。

【事象(2) 新ユーザ認証サーバの両系ダウン】

ここが、事件の本質的なところ。

現行系→新規系への切替作業中に問題が発生したため切り戻しを決定し作業を開始したところ、新ユーザ認証サーバ(レプリカ#1)がHW障害でダウン。ここまではありがちな障害で、想定されてもいます。ここで二重化の相手である新ユーザ認証サーバ(レプリカ#2)に負荷が集中してダウンしてしまうという問題が発生してしまっています。このことをKDDIは「二重障害」と表現しています。この二重障害という表現に違和感があります。二重化というのは片系がダウンしてももう片系で稼働をすることができる仕組みなので、片系だけでも稼働に耐え得るスペックを満たさなければなりません。しかし、このスペックを満たしていないことが顕在化したわけです。二重障害ではなく、二重化機構の性能計算の誤りがレプリカ#2の障害に繋がっているというのが僕の印象です。

この対処中、新ユーザ認証サーバ(レプリカ#1/レプリカ#2)への接続から現ユーザ認証サーバ(マスタ)への切替を行なって障害仮復旧しています。この作業が、なんだか不思議。切り戻し作業中とはいえ運用フェーズにあるのは新ユーザ認証系であり、現ユーザ認証サーバで動かすのはかなりのリクスがあると考えます。どこまで調べて判断した結果現ユーザ認証サーバに切り替えたのかが非常に気になります。また、現ユーザ認証サーバ(レプリカ)の事象(1)からの修復を待たず現ユーザ認証サーバ(マスタ)への接続に切り替えているわけですが、よく現ユーザ認証サーバ(マスタ)が高負荷でダウンしてしまわなかったなとも思います。

【事象(3) メールサーバ高負荷継続】

事象(2)の復旧後に端末(iOS端末)からの接続が集中し、結果として2日半の長時間に及ぶメール障害となった事象です。この事象で僕もずいぶんと不便を被りました。イメージとして、事故で運転を見合せていた電車が運転再開したから駅に向かったら、乗客がホームに殺到していて電車が発車できる状態にならない、と言ったものでしょうか。これは、まあいくらなんでも2日半はかかり過ぎだろうというのが印象です。iOSのリアルタイム受信の仕組みをまだ調べていないのですが、あまりサーバ負荷を考えていないような気もします。これはiOS側でもなんらかの処置が必要なんじゃないのかなと感じます。