Webシステムの障害検知してますか？

先日、開発のお手伝いをしているとある会社で、サーバートラブルが発生しました。 19:50分頃に、コンテンツ担当をしている人が、社内のプロジェクトメンバーチャットで、「今、本番で502エラーというのが表示されてます。」とのこと。 自分は、このプロジェクトチームのメンバーじゃないのですが、たまたま先日技術相談をされた時にチャットに入れてもらっていたので、そのチャットを見る事ができていました。 サーバーエラーは基本的に開発員じゃないと原因究明も対応することもできません。 そして、10分以上経っても、誰もそのプロジェクトの開発員からの返答がなかったので、502エラーは、サーバーエラーであることをチャットで共有してあげました。 じゃあ、その担当者はどうすればいいかはサーバー状態やログをチェックして原因究明をする必要があるんですが、サーバーのアクセスは自分は聞いていなかったので、これ以上の対応はできない旨も伝えておいて、小一時間ほどして、その会社の技術責任者の人が応答してきて、 開発担当者に連絡をして数時間ほどして復旧が完了したようでした。 不思議だと思いません？ Web系のサーバー公開型のサービスを運用しているのに、障害が起きてもされを対応する社内フローが無いように思えたんですよね。 ちょうど翌日に、自分が参加しているプロジェクトのミーティングがあり、そこに障害が起きたプロジェクトメンバーも参加するようなので、いろいろとわかってきた事と、それらをとりまく組織環境などについて、似たような環境の会社や組織で今一度障害検知について考えてもらいたく、ブログにまとめておきたいと思います。

障害検知の閾値

AWSを使っていると、サーバーに障害が起きた時に、メールなどでアラート報告を送ってくれます。 事後で聞いた話ですが、今回起きた障害でのアラートメールはちゃんと送信されていたようです。 でも、それを受けていた開発員は、半年前に退職した人と、プロジェクトに関係ない業務委託のエンジニアという事で、まるでアラートの意味が無いという実態が発覚したんですね。 実際にどういうアラートが出ていたかというと、502エラーが出たという内容のアラートだったと聞き、 それは、検知ではなく、障害報告ログですよ・・・という事をエンジニアに教えてあげました。 障害検知と障害報告って一体何が違うのかエンジニアは理解できていなかったようなので、もしかしたら、今時のエンジニアってこういうレベルなのか！？と呆れ半分、教育をしっかりせねば！という強い義務感を感じたんですよ。 簡単に説明すると、障害報告というのは、障害が起きた後で伝えられるモノで、障害検知は、障害が起きる前に検知するモノだと考えましょう。 障害って、起きてから対応するという思考でいるエンジニアもいるかもしれませんが、 障害が起きてからでは、サーバーにアクセスできなくなる事も考えられるし、そもそも障害が発生しているダウンタイムが少なからず発生します。 一方で、障害検知をしていると、障害が起きる前に検知報告があるので、即座にバランシングサーバーの台数を増やしたり、サーバースペックを向上させたりする事前の対応ができるんですね。 当たり前ですが、こうしたことを実際に障害が起きて、その組織の上司などから怒られないと理解できていないエンジニアって、結構多いみたいですね。 そして、とても重要なのは、障害検知をする場合の、サーバー内の何がどうなったらアラートを発生させるかという、閾値セットです。 自分の場合は、50%ルールとして、サーバーが1台あたり1秒間に100アクセスあったらダウンするという性能上限値を把握していたら、5分即検知などで50を上回ったらアラートメールを送信するようにしたり、 メモリ、ディスク容量、サーバー内温度（オンプレの場合）、LoadAverage数、これらの上限数の50%にセットして運用する事で、ほぼサービス停止をおこさないシステム運用ができるようになります。

サーバーダウンはサービス信頼性に比例する

よくサーバーが落ちるシステムを、誰も使いたいとは思いませんよね。 Webサイトの3秒ルールというのがあって、一般的に3秒待って表示されないWebサイトは、アクセスした大半が諦めて離脱するというマーケティング統計があります。 これが、サイトにアクセスしたら、「○○エラー」と表示されるページを見たら、もしかしたら、ブックマークしている人も、そのブックマークを消してしまう可能性もあるんですよ。 怖いですね。機会損失どころではない損害につながります。 もちろん、課金をしていないサイトでも、アクセス数も格段に減るし、サーバーダウンすることによるメリットなんて何一つありません。 こんな当たり前のことを、多くのサービス運用者は、サーバーがダウンするまで気が付かないというケースも本当に多いんです。 もちろん、企業で運用しているWebサービスであれば、社長や役員といった、経営層が我ごとに考えていない場合、担当エンジニアや担当部門、チームに、サーバーダウンした事を叱責するという、アホな経営をして、結果的にエンジニアの大部分が退職してしまうという事態になってしまうことに、気が付かない場合もあるかもですね。（ていうか、実際にこういう会社多いです） 言ってしまうと、サーバーがダウンしても、末端従業員の人は、痛くも痒くもありません。 それを元に給料を下げられるのであれば、転職してしまえばよくて、業務委託の場合は、次の契約満了時に更新しなければいいだけなのです。 これを考えると、サーバーが落ちて困る人は、自分事として認識をして、しっかりとした組織を作るというのが最善の方向性なんですね。ていうか、これしかありません。 アホ経営している経営者は、経営を退くか、今一度悔い改めるようにしましょうね。（コンサルする場合、ここまでキツくはいいませんが、似たような内容で伝えます）

サービス障害を前向きにとらえるエンジニア思考

サービス障害は、システム障害やサーバートラブル意外にも、ネットワーク障害や、それ以外のトラブルなども必ず発生してしまうものです。 NTTの回線が障害で、サービスのURLを表示しても、画面が真っ白になる場合、回線キャリアの責務になりますが、こういう場合どういう事前対応ができるかというと、複数回線契約をするとか、 データセンターリージョンを離れた場所に複数持つなどの事前対策が考えられます。 これは、災害などに対応するでィザスターリカバリーという対策にもつながり、落ちないサービスを作る有効な方法ですが、サーバーコストは跳ね上がってしまいます。 提供するWebサービスの規模に応じてサービス障害の対応を事前に考えておく事も重要なんですね。 ちなみに、自分の場合は、サーバー障害もゲームのフラグ発生のような感じで考えていて、 いかに完璧に食い止める事ができるかというサーバー障害ゲームという感じで事前計画を立てる事が多いです。 不謹慎かもしれませんが、どんな時もゲーミフィケーションが最強という説です。

障害検知からの対応フローの確立

今回発生した障害で、もう一つ大きな問題が発覚しました。 それは、障害が発生した後で、どのように復旧するか、ユーザーへの告知をどうするか、誰がするか、その間プロジェクトメンバーはそれぞれ何をするか・・・ これらの障害対応フローがその会社には、全く存在しない、皆無の状態だったんですね。 呆れて口がふさがりませんでした・・・ これまで障害が起きた事ないの？と聞くと、たまにサーバー障害があったけど、回復に長い時間がかからなければ、うやむやになってきていたそうです。 時間がかかる場合は、その部門の上長にこっぴどく説教されてそれで終わりなのだそうです。 全くバカな組織ですよね。エンジニアもさることながら、上司のアホっぷりも、ハンパないです。 小学校でも行っている、災害訓練みたいなことをチームや組織でやっておく事が重要だということぐらい、小学生でもわかるはずです。

障害対応フロー

1. 障害発生する前に、まず閾値に従ってオーバーしたら、アラート送信、 2. アラートを受け取った人は、チームの中の人に連絡（これも連絡順番や連絡網などを整備する必要があります） 3. そして、サービスダウンにつながる場合は、ユーザーへの告知（同じサーバーを使っていたら伝わらないので、告知用のシステムは別途考える必要があります） 4. その後、障害種別に応じた復旧手順を遂行 5. サービスが復旧したら、その旨の連絡を連絡もうとユーザーに行い、 6. 障害が起きた原因と、それに伴う作業手順、サービスダウンタイム、発生時刻から復旧時刻までをちゃんと記録に残します。 7. 最後にチームでそれらの内容を共有して、必要があれば、再発防止策を検討する7. こんな手順のフローが作れたら、非常に堅牢なサービス運用ができることでしょう。

あとがき

障害が発生することしたいは、インターネットサービスにはつきものなので、当たり前ですが、 サービス構築時に障害対応まで考えられているサービスはどうやら少ないようです。 障害検知ができていても、対応フローがなければ、目覚ましが鳴っても起きない遅刻常習犯となんら変わりません。 待ち合わせによく遅れる友人は、友達からは信頼を失うように、 Webサービスの信頼もいとも簡単に失われてしまうという事を、今回のブログを読んで思い知ってくれたら幸いです。 たかがサーバー障害、されどサーバー障害、これらを楽しめるエンジニアと、デメリットに感じるエンジニアで大きくサービスクオリティも変わるという事がわかってもらえましたでしょうか？ 経営の人は、アホな経営しないようにしましょうね。