KDDIの「Eメールリアルタイム送受信システムの通信障害」を細かく見てみる

先日のリアルタイム通知の障害で、障害内容についての報告書が公開されたので、自分なりの予想などを立てながら細かく見てみます。

背景

障害の背景となる一番重要なポイントが、記者会見では触れられているのですが、実はこの報告書には書かれていません。


新サーバーのハードウェアは、通常、4つの設備（四重化）で運用しているが、今回はそれを半分ずつに分けて、一方を旧来の現行サーバー、残りを新バージョンのサーバーとしていた。

これを踏まえて、それぞれの事象を読み解いていきます。*1

p5 事象(1) ユーザ認証サーバでのユーザ情報の不一致発生（マスタ／レプリカ間）


原因 ： 手順書記載ミスによるコマンド誤り（事前検証試験不足）

  • コマンド誤りにより新ユーザ認証サーバと誤って接続された結果、ユーザ情報データが一部欠損
  • 1) ユーザ認証 エラー発生
  • 2) 新ユーザ認証サーバへの切替により認証エラー解消

こうありますが、結局「何が悪かったのか」ははっきりしていません。


KDDIでは、バージョンアップ作業について事前に試験を行い、手順書の検証などもベンダーを交えて行っていたが、今回の事態を招くような状況は考慮していなかった

会見ではこういう発言があったようですが、原因が手順書の記載ミスであれば「考慮されていない状況」ではなく、そもそも「手順書通りの検証が実施されなかった（おそらくは思い込みに従った検証を行っていた）」です。

対策として作業対象設備以外の周辺設備まで範囲を広げて設備ログの 確認を徹底とあるので、本番環境である「旧サーバがある環境での新サーバの追加」という検証をせず、「データを同期した新サーバだけで検証をしていたため、手順書の操作対象サーバのミスに気付かなかった」という予想ができます。

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


原因 ： HW障害（片系）と二重障害時の対策準備不足

  • 1) 予期せぬタイムアウトエラー発生
  • 2) 片系がHW障害でダウン、その後、残っていた片系も過負荷でダウン
  • 3) 現行ユーザ認証サーバへの接続変更とメールBOXサーバの再起動実施

「予期せぬタイムアウトエラー」はアプリケーションレベルの問題なので仕方無いとします。そのための切り戻しです。ひどいのもここからです。

ただでさえ、元が4重化されていたものを移行のため2重化にまで下げていたわけですが、どうやらレプリカサーバという事でActive-Active構成だったようで、そのうち片系が壊れてしまうと性能が当初の1/4になってしまうわけです。

障害が重なり時間がかかった結果、こうなるわけです。


新バージョンのサーバー2つのうち1つがダウンした形となったが、残ったサーバー1つの処理能力であれば切り戻し作業はこなせる、とされ、作業は続行された。 しかし、その想定は、ユーザーが本格的な活動時間を迎える朝6時ごろまでという前提に立つものだった。しかし時間は過ぎていき、多くのユーザーがiPhoneを積極的に利用しはじめ、トラフィックが上昇した朝8時8分、残っていた新サーバーの1つも過負荷によってダウン。

ここで大きな疑問が3点あります。軽い順に並べます。

  • 新ユーザ認証サーバ(レプリカ)のHW障害がいつ発生したのか。
    報告書や会見では明らかにされていないため、ディスクコントローラーの故障ならば緊急交換対応とかなんとかならなかったのかと思ってしまいます。
  • 現行ユーザ認証サーバ(レプリカ)の修復にどれぐらい時間がかかったのか。
    作業前にバックアップやスナップショットを取っていれば事象(1)の時点ですぐに戻せるはずなので、レプリカサーバという前提で取っていなかったのでは無いかと予想します。そのため、マスタサーバからのレプリカに時間がかかってしまったのでしょう。ですが、そもそも01:41に事象(1)が解消した時点からレプリカの再生に注力する事で、翌朝までには間に合った可能性がありますし、そもそも手順としてスナップショットなりで直ぐに復旧できるようにしておくべきだったでしょう。
  • なぜ4重化されているシステムを2重化まで冗長度を落としたのか。
    結果として1台では午前8時の負荷に耐えられない以上、2重化というのは冗長化されていないのと同じ事です。バージョンアップ中とはいえ冗長度がゼロというのは、サービス断を発生させないよう、現行設備と同構成の新バージョン設備を事前に準備という表現からイメージされるものとはかけ離れています。

後からはいくらでも言えるとはいえ、はっきり言って「支払うべきコストをケチった結果がごらんの有様」と言わざるを得ないです。

なにしろこれらは対策にも含まれていません。HW故障原因の調査とかぶっちゃけどうでもいいんです、何かしらどうせ壊れるんですから。必要なのは、それを折り込んで冗長性を確保することです。

p7 事象(3) 一部のメールBOXサーバにて高負荷が継続


原因 ： メールBOXサーバ再起動手順の考慮不足

  • 1) メールBOX再起動完了までメールが滞留
    30台中24台が高負荷
  • 2）端末〜メールBOXサーバのサーバ単位の流量調整により高負荷を解消

図にディスクアレイの構成が書いてあったり、対策でディスク処理能力が歌われているあたりからすると、ディスク処理能力不足が原因だったんでしょうね。割とありがちな話なのでここについては特に言う事は無いです。

考えるポイント(2013-04-26 07:30追加)

個人的にこのような作業手順や冗長度を考える上での前提が以下の2つです。これらを折り込んでいれば、それなりに堅いシステムが組めていると思います。

人が書いたものは必ず間違える

繰り返し繰り返し繰り返し書いている取り、人間様のエラー率舐めちゃいけません。いくらクロスチェックを重ねたって、一定の確率ですり抜けてしまいます。止めたくないサービスならば、他の対応策も併用するべきです。

  • システムを冗長化し、間違えてもサービス全体に影響が出ないようにする
  • 動作確認を行い、サービスへの影響をすぐに気付けるようにする(できれば自動化)
  • バックアップやスナップショットを取り、すぐに元の状態に戻せるようにする
  • チェックの段数を増やし、すり抜ける確率を減らす
ハードウェアは必ず壊れる

そりゃもう壊れます。

マーフィーの法則って知ってますか。今回のように、一番壊れて欲しくないときに壊れてくれるんです。本当にハードウェアの故障をなんとかしたいのであれば、最初っからいわゆる無停止サーバを買うかVMware FTとか使いましょう。

そもそもどれぐらい「落としたくない」のか

今回のシステムは「通信キャリアが提供するメールシステム」という、絶対に止めたくない系サービスだという前提で話をしていますが、それにはコストがかかります。ハードウェアの冗長度を上げればそこにお金がかかるし、手順でカバーしようとすればチェックも含めた人件費がふくれあがるわけです。

最終的なコストやリスクを前提に、受けうるダメージが想定の範囲内に収まっていれば良いわけで、要するにこういうことです。

全体を通して

とにかく手順と検証と復旧迅速化について触れていますが、結局「障害によるサービス停止を起こさないための冗長化にリソースを追加する」という考え方が一切入っていない事が気になりました。

今回のような細かい報告書を公開して頂いたKDDIさんには感謝すると共に、我々が体重を掛けられる通信キャリアとして頑張ってほしいと思います(自分もau iPhone5使ってますよ！)。

その上で、我々インフラエンジニアとしては対岸の火事と笑い飛ばさず、他山の石として自分が預かるシステムの冗長化について考えるきっかけとなれば、現実逃避にこの記事を書いたかいがあるというものです。

幸福は義務です。我々には、我々自身が幸福でいられるシステムを組む義務があります。

*1:引用は表記がなければ報告書、ただし大文字小文字混ざっている数字など細かい表記変更を行っています。