めもおきばスマートフォン用の表示で見るめもおきばHOMEARCHIVEBACKNUMBERSBOOTH投げ銭CONTACT2013-04-25KDDIの「Eメールリアルタイム送受信システムの通信障害」を細かく見てみる先日のリアルタイム通知の障害で、障害内容についての報告書が公開されたので、自分なりの予想などを立てながら細かく見てみます。障害の背景となる一番重要なポイントが、記者会見では触れられているのですが、実はこの報告書には書かれていません。新サーバーのハードウェアは、通常、4つの設備(四重化)で運用しているが、今回はそれを半分ずつに分けて、一方を旧来の現行サーバー、残りを新バージョンのサーバーとしていた。これを踏まえて、それぞれの事象を読み解いていきます。新ユーザ認証サーバへの切替により認証エラー解消こうありますが、結局「何が悪かったのか」ははっきりしていません。KDDIでは、バージョンアップ作業について事前に試験を行い、手順書の検証などもベンダーを交えて行っていたが、今回の事態を招くような状況は考慮していなかった会見ではこういう発言があったようですが、原因が手順書の記載ミスであれば「考慮されていない状況」ではなく、そもそも「手順書通りの検証が実施されなかった(おそらくは思い込みに従った検証を行っていた)」です。あるので、本番環境である「旧サーバがある環境での新サーバの追加」という検証をせず、「データを同期した新サーバだけで検証をしていたため、手順書の操作対象サーバのミスに気付かなかった」という予想ができます。「予期せぬタイムアウトエラー」はアプリケーションレベルの問題なので仕方無いとします。そのための切り戻しです。ひどいのもここからです。ただでさえ、元が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故障原因の調査とかぶっちゃけどうでもいいんです、何かしらどうせ壊れるんですから。必要なのは、それを折り込んで冗長性を確保することです。図にディスクアレイの構成が書いてあったり、対策でディスク処理能力が歌われているあたりからすると、ディスク処理能力不足が原因だったんでしょうね。ありがちな話なのでここについては特に言う事は無いです。07:30追加)個人的にこのような作業手順や冗長度を考える上での前提が以下の2つです。これらを折り込んでいれば、それなりに堅いシステムが組めていると思います。人が書いたものは必ず間違える繰り返し繰り返し繰り返し書いている取り、人間様のエラー率舐めちゃいけません。いくらクロスチェックを重ねたって、一定の確率ですり抜けてしまいます。止めたくないサービスならば、他の対応策も併用するべきです。システムを冗長化し、間違えてもサービス全体に影響が出ないようにする動作確認を行い、サービスへの影響をすぐに気付けるようにする(できれば自動化)バックアップやスナップショットを取り、すぐに元の状態に戻せるようにするチェックの段数を増やし、すり抜ける確率を減らすハードウェアは必ず壊れるそりゃもう壊れます。マーフィーの法則って知ってますか。今回のように、一番壊れて欲しくないときに壊れてくれるんです。FTとか使いましょう。そもそもどれぐらい「落としたくない」のか今回のシステムは「通信キャリアが提供するメールシステム」という、絶対に止めたくない系サービスだという前提で話をしていますが、それにはコストがかかります。ハードウェアの冗長度を上げればそこにお金がかかるし、手順でカバーしようとすればチェックも含めた人件費がふくれあがるわけです。最終的なコストやリスクを前提に、受けうるダメージが想定の範囲内に収まっていれば良いわけで、要するにこういうことです。web全体を通してとにかく手順と検証と復旧迅速化について触れていますが、結局「障害によるサービス停止を起こさないための冗長化にリソースを追加する」という考え方が一切入っていない事が気になりました。iPhone5使ってますよ!)。その上で、我々インフラエンジニアとしては対岸の火事と笑い飛ばさず、他山の石として自分が預かるシステムの冗長化について考えるきっかけとなれば、現実逃避にこの記事を書いたかいがあるというものです。我々には、我々自身が幸福でいられるシステムを組む義務があります。*1:引用は表記がなければ報告書、ただし大文字小文字混ざっている数字など細かい表記変更を行っています。再受賞(2019)Slack情報収集のためのチートシートデザインテーマ変えてみましたもっと見る月別アーカイブ検索はてなブログをはじめよう!nekoruriさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。