8/23〜24に発生したサービス停止についてのご報告
いつもFeedeenのご利用ありがとうございます。運営者の伊藤です。
8/23の昼頃から8/24早朝まで、Feedeenのすべてのサービスが停止する障害が発生しました。長時間にわたるサービス停止で多くの方々にご不便をおかけしてしまい、大変申し訳ございません。また、障害発生中、サービスが停止しているにも関わらずSNS等で励ましのメッセージなどたくさんいただきました。この場にて改めて御礼申し上げます。ありがとうございます。
以下、今回の障害についてご報告させていただきます。
なお、Feedeenに保存されているデータに関しては障害発生時点のものが復旧できましたので、データの欠損等はございません。
この時点でのAWSの障害情報では通信障害とのことだったため、サーバー自体は生きていると判断し、AWS側の障害が回復するのを待つことにしました。しかし、実際にはこの判断が誤りであり、20時頃にAWSが障害回復をアナウンスした後も、Feedeenのサーバーが復帰することはありませんでした。
21時頃、障害が発生したサーバーの回復は望み薄であると判断し、代替サーバーを構築する準備をはじめました。しかし、次期バージョンの開発が進んでいたためデプロイ環境を整えるのに手間取り、実際に再構築を始めたのは23時頃となりました。日付が変わって3時頃に構築が終了、旧サーバーとの差し替え作業や動作確認等を行い、5時頃にサービスを復帰させました。以上が今回の障害の経緯となります。
さらに不運なことに、AWSの障害復帰後も回復しない「ごく一部のインスタンス」に両サーバーが含まれてしまい、サーバーの差し替えが必要となったことで、サービスの再開が大きく遅れました。この点は私の深刻な判断ミスとして反省しております。
ただ、今回の障害ではいくつか教訓も得られました。ひとつは、いずれかのサーバーに障害が発生したら、速やかに代替サーバーの構築を始めるべきということです。今回はAWS内での通信障害ということで、原因が解消されればサーバーが復帰するだろうという甘い見通しを立ててしまい、再構築の作業をせずに時間を浪費してしまいました。今後は早めに代替サーバーを準備し、障害の発生したサーバーには見切りをつけることで、サービス停止時間を最小限にします。
もうひとつは、使用するサーバーの種類についてです。AWSで利用できるサーバーにはいくつか種類(インスタンスタイプ)があるのですが、障害が発生したサーバーはいずれもかなり古い種類のものでした。性能とコストのバランスがFeedeenに適しているので採用したのですが、もしかしたら障害発生確率が高いのかもしれません。ちょうどサーバー構成の変更を考えていましたので、並行して新しい種類への移行も積極的に検討します。
前述の通り根本的な対策は難しいのですが、運用やサーバー構成の工夫により、少しでも障害の可能性を減らしていきたいと考えております。今後ともFeedeenをよろしくお願いいたします。
8/23の昼頃から8/24早朝まで、Feedeenのすべてのサービスが停止する障害が発生しました。長時間にわたるサービス停止で多くの方々にご不便をおかけしてしまい、大変申し訳ございません。また、障害発生中、サービスが停止しているにも関わらずSNS等で励ましのメッセージなどたくさんいただきました。この場にて改めて御礼申し上げます。ありがとうございます。
以下、今回の障害についてご報告させていただきます。
障害の影響
まずはユーザーの皆様にとって最も重要であろう、障害の影響についてです。サービスの停止は23日の13時頃(推定)から24日の5時頃まで、およそ16時間にわたりました。フィードの取得も停止しましたので、障害発生中のフィードの更新を取りこぼしている可能性があります。重要な情報については、配信元のWebサイトを直接ご確認いただくことをお勧めいたします。なお、Feedeenに保存されているデータに関しては障害発生時点のものが復旧できましたので、データの欠損等はございません。
障害の経過
障害の発生は、推定ですが23日の13時頃からと考えております。データベースを含む一部サーバーが通信不能となり、サービスが事実上停止しました。運営者が障害を認識したのは13:30頃で、状況の確認やAWS障害の情報収集等を行い、即時の回復が難しいと判断、14:30頃にサービスをメンテナンス表示に切り替えました。この時点でのAWSの障害情報では通信障害とのことだったため、サーバー自体は生きていると判断し、AWS側の障害が回復するのを待つことにしました。しかし、実際にはこの判断が誤りであり、20時頃にAWSが障害回復をアナウンスした後も、Feedeenのサーバーが復帰することはありませんでした。
21時頃、障害が発生したサーバーの回復は望み薄であると判断し、代替サーバーを構築する準備をはじめました。しかし、次期バージョンの開発が進んでいたためデプロイ環境を整えるのに手間取り、実際に再構築を始めたのは23時頃となりました。日付が変わって3時頃に構築が終了、旧サーバーとの差し替え作業や動作確認等を行い、5時頃にサービスを復帰させました。以上が今回の障害の経緯となります。
障害の原因
サービス停止の直接の原因は、Feedeenのサーバーをホストしているクラウドサービスである AWS の障害です。TVニュース等でも大きく報じられていましたので、ご存じの方も多いかと思います。Feedeenのデータベースを含む一部のサーバーへの通信が完全に遮断されてしまい、サービスを停止せざるを得ない状況となりました。さらに不運なことに、AWSの障害復帰後も回復しない「ごく一部のインスタンス」に両サーバーが含まれてしまい、サーバーの差し替えが必要となったことで、サービスの再開が大きく遅れました。この点は私の深刻な判断ミスとして反省しております。
今後の対策
今回のようにサーバーが突然停止してしまう障害を対策するには、サーバーを冗長化する(常に予備を用意しておく)しかありません。しかし、正直に申しますとFeedeenはそこまで儲かっておらず、予備サーバーのコストを捻出するのは難しいのが実情です。ただ、今回の障害ではいくつか教訓も得られました。ひとつは、いずれかのサーバーに障害が発生したら、速やかに代替サーバーの構築を始めるべきということです。今回はAWS内での通信障害ということで、原因が解消されればサーバーが復帰するだろうという甘い見通しを立ててしまい、再構築の作業をせずに時間を浪費してしまいました。今後は早めに代替サーバーを準備し、障害の発生したサーバーには見切りをつけることで、サービス停止時間を最小限にします。
もうひとつは、使用するサーバーの種類についてです。AWSで利用できるサーバーにはいくつか種類(インスタンスタイプ)があるのですが、障害が発生したサーバーはいずれもかなり古い種類のものでした。性能とコストのバランスがFeedeenに適しているので採用したのですが、もしかしたら障害発生確率が高いのかもしれません。ちょうどサーバー構成の変更を考えていましたので、並行して新しい種類への移行も積極的に検討します。
前述の通り根本的な対策は難しいのですが、運用やサーバー構成の工夫により、少しでも障害の可能性を減らしていきたいと考えております。今後ともFeedeenをよろしくお願いいたします。
コメント
コメントを投稿