ao-log

インフラ系ITエンジニアのメモ帳です。

au のメールサーバ 62 台ダウンの原因を推測してみる

4/16 に発生した au のメール障害の原因が、メールサーバ 62 台のダウンとの事。62 台ってすごいですね。

[auのiPhoneメール障害が復旧、原因はメールサーバー62台のダウン]
http://itpro.nikkeibp.co.jp/article/NEWS/20130416/471303/

こういうとき、部外者だと気楽なんですが、中の人は大変なんでしょうね。
せっかくなので、原因がどこにあるか根拠のない推測をしています。可能性としてありそうなものを挙げてみる。

単に処理をさばけなくなった

システムの想定する処理能力を超える処理要求が発生してサーバダウンにつながった。この場合、対策しないと再発しまくりそう。

パッチの副作用

パッチを適用することで、特定の処理が重くなった。

マシンダウンによる台数減少が引き起こす問題

障害でサービスにまわせる台数が減ると、1 台あたりにまかせる処理量も多くなってしまいます。このとき、安定稼動できる閾値を超えると、サーバダウンにつながりますが、さらに台数が減っての悪循環になってしまうので悲惨ですね。
仮想化で運用している場合、一台物理サーバが障害でダウンした場合、vMotion とかで一気に負荷が上がり更なる問題発生というのもありそうです。

ストレージの問題

複数のマシンから同じファイルを参照するなどの用途で、ストレージをマウントしていることはよくあります。ただし、ストレージに問題が発生した時、ノード側の対策が甘いとマウントしているサーバ側にも問題が発生したりします。例えば、定期的な処理で問題の領域へアクセスしている場合、作りが甘いと、処理実行のたびにプロセスがたまり続け、やがてサーバの負荷が高まりサーバダウンにつながったりとか。

スイッチの問題

実は単にスイッチの問題で、メールサーバにアクセスできなくなっただけ。ただ、この場合はサーバダウンという表現にはならないので、多分これはないです。

施設面

電源側の問題か、あるいは空調の冷却能力に問題が発生して、高温を検知してシャーシ側の機能で強制停止というのもありうる。

オペ担当者のオペミス

メンテ対象マシンだけのリブートのはずが、サービス中のマシンも対象に実施してしまったというのもありがちかも。これだけ台数が多いノードを似た用途で使っていると、ホスト名も似通っていたりするので、ミスも起こりやすくなります。

OS 側のバグ

208.5 日問題でリブートしたという説もわずかに考えられるかも。さすがにこれは無いと思いたいですが。


・追記

au の発表情報によると設備故障と書いてありますね。どの設備が故障したかは不明ですが。

[au携帯電話 iPhone iPad Eメールリアルタイム受信設定のお客様にてEメールがご利用いただけない状況について(完報:4月17日 03時30分現在)]
http://www.kddi.com/news/important/important_20130417032027.html

・追記(2013/4/25)
KDDI さんからの障害原因の報告が出ましたね。技術者向けの情報ですが、逆に分かりやすいです。62台の再起動は、現行設備への切り戻しを決定した後に切り戻しの手順として意図的に実施したのが真相のようですね。ただ、認証サーバの問題や、滞留したメールが引き起こす問題、流量調整がうまくいっていなかったことについては、挙げられませんでした。僕もまだまだだな。
http://www.kddi.com/corporate/news_release/2013/0425/pdf/besshi.pdf