WEBサービス起業の障害追跡をしている「ダウンディテクター」

2019/03/19

テクノロジー

t f B! P L
WEBサービスはもはや生活の一部になっているため、障害が発生すると何かしら困ってしまう事態に陥ってしまいます。 例えば、Gmailサーバーが障害になると、メールの送受信ができずに、各種連絡が出来ない事は容易に想像できますが、 それ以外でも、スマートフォンのアプリや、他のWEBサービスでGmailのOpenIDを使った代理ログイン機能などを使っている場合に、そうしたサービスも利用できなくなります。 こうした副作用による症状は発生して初めて発覚するものもありますが、ユーザー側でも普段から認識をしておく必要があります。 それでも、基本的にユーザーは指を加えて見ているしか無いのが現状です。 そんなもどかしさをほんの少し解消してくれる大手のサービスを常時監視していて、障害検知をしてくれるWEBサービスがあったので、ご紹介します。

ダウンディテクター

https://downdetector.jp/ 名前の通り「障害探知装置」なんですね。 # 追跡サービス(企業)一覧 https://downdetector.jp/tsuiseki-shiteiru-kigyo-saabisu 誰もがよく使っているサービスや企業の一覧が確認できると思いますが、普段利用しているサービスが調子悪いな〜と思ったら、このページを確認してサービスがダウンしているかどうかを確認するだけで、自分のスマートフォンがおかしくなったわけではない事が確認できます。 また、このサービスの面白い点として、「障害発生トップ10」というのがメニューにありますが、ソコを閲覧すると、過去の障害件数らしきランキングが掲載されているのがわかります。 https://downdetector.jp/top10/ Instagram、Gmail、Facebookと、なんと上位5位以内に主要OpenIDのサービスがランクインしていて、いかに世界的な大手企業であっても、こうしたサービス障害って無くせられないという事が一望できます。 エンジニアの皆さん、自分の構築、運営しているWEBサービスがダウンしたからと言って、落ち込まなくても大丈夫ですよ。 もちろん、原因は個人の凡ミスレベルや、コントロールできない、サーバー機器の劣化や、誤作動など、色々な要因があることに変わりないですが、「落ちないシステムは無い」という証拠としての安心感が得られます。 え?気が休まらない?障害した事実に変わりがないですって? そんなエンジニアには、障害が発生した夜は酒をたらふく飲んで忘れて爆睡することをオススメします。

誰も得しない障害はどうして起こるのか?

一般の利用者は、サービス障害の時には、当たり前のように利用できない事に対してイライラしてしまうと思いますが、その原因のほとんどが「個人の凡ミス」によるものだと分かると、より怒りが増すかもしれません。 サービス運営会社は、そんなストレートな情報は公開せずに、機器障害であったり、致し方ないミスというニュアンスで障害報告を行ってきます。 ただ、これに対して無料で利用しているサービスに関しては、笑って済ませるぐらいの広い心を持たないとWEBサービス提供会社もやってられないでしょうね。 有料で使っているサービスは、有料分文句を言う権利も買っていると考える人もいますが、B2B系サービスでは、サポート担当者が袋たたきにあっている状態を過去に何度も見かけました。 袋たたきと言っても、直接的な暴力ではなく、言葉の暴力ですけどね。 でも、その肝心の障害って、どうやって発生してしまうのでしょう? 報告で一番多いのがサーバー機器障害だと考えられますが、今どきのAWSの様なクラウドシステムでも、実態のサーバーハードウェアは存在するし、サーバーダウン障害は、日々発生しているようです。 ダウンディテクターでは過去に1件しか公開されていないようですが、この計測で難しいのは、AWSのWEBサーバーは個別に障害が結構発生しているので、監視で全てのサーバーを網羅できていないという事でしょう。 実際に、AWSの構成を理解していないエンジニアも意外といる事態を知った時には驚愕でしたけどね・・・ ここで、HW構成が理解できていないと、障害に対する認識も皆無であると認識できました。

自分たちが運営するサービス設計を寒くしないために

また、エンジニアであれば、自分の構築するWEBサービスでGmailのOpenIDを利用する場合に、アプリ立ち上げの度に認証処理を行っているとOpenIDサーバー障害の際にログインができないという自体になり、サポート電話がなりっぱなしの刑に突入してしまいます。 OpenIDを利用する時は、認証したら一旦自分たちのサービスでセッション保持を行い、ログアウトするか、期限切れになるまでは、認証サーバーには接続しないようにすることで、こうしたサービスダウン障害の際に、全てのユーザーが一斉に利用できなくなるという事態を回避することができます。 僕もFacebookサーバーがダウンした時に、とあるアプリから来たPUSH通知を確認することができずに、ビジネスに影響が出た経験がありましたが、そのアプリの設計者にこうした設計を教えてあげたい気分でした。 そういや、このダウンディテクターが障害を起こした場合は、どうなんでしょう? 僕なら、このサービスを外部監視するという数珠つなぎにしますけどね。 いくつかの数珠監視を行うと、エンドレスな循環システムが構築でき、確実に検知ができるシステムになるという事も可能です・・・ そう考えるとほとんどカオスですね・・・

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ