1月11日のサービス停止についてのご報告

いつもご利用ありがとうございます。Feedeen運営者の伊藤です。

1月11日未明から13時にわたり、障害によるサービス停止が発生しました。多くの皆様にご不便をおかけしてしまい、たいへん申し訳ございません。以下に経緯と対策についてご報告させていただきます。

障害の経緯

1月11日未明（おそらく午前1時を少し経過した頃）にデータベースサーバーのOSに強制再起動がかかり、データベースのプログラムが停止してしまいました。これによりデータベースに依存しているプログラムが動作しなくなり、サービスのほぼ全体がご利用いただけない状態となりました。

また、この運営者がこの障害に気づくことなく就寝してしまったため、長時間障害が続くことになってしまいました。長時間の障害はいつもこれが原因で恐縮なのですが、忘れた頃に突然発生するのでなんとも対処しづらく...申し訳ございません。

同日13時過ぎ、ようやくですが運営者が障害に気づき、データベースを起動する作業を行い、ひとまずサービスを再開しました。その後、念のため各プログラムの再起動と動作確認を行い、15時過ぎにサービスの復帰作業を終了しました。

障害の原因

障害の原因について、現時点で判明していることをご報告します。

まずはデータベースサーバーのOSが再起動した点ですが、これはAWS（Feedeenで使用しているクラウドサービス）側からの事前通知なく発生したため、正確な原因はつかめておりません。おそらく、突発的なハードウェア障害などによるものと考えられます。また、この強制再起動が障害の切っ掛けではあるものの、再起動後はOSが正常に動作しており、実はデータベースを起動すればすぐにサービスが復帰できる状態でした。

障害が長期化した原因は、OS起動後にデータベースプログラムを起動する作業が自動化されておらず、運営者が手作業で行う必要があった点です。これは、以下の理由によります。

• 障害発生後に状態確認せずにデータベースプログラムを起動してしまうと、場合によってはデータ喪失などさらなる状況の悪化を招いてしまうことがある。
• AWSにおいて意図しないOS再起動がかかるような状況では、再起動後にサーバーが正常動作する可能性は低いと考えていた。実際に過去のデータベース障害では、停止したサーバーを復帰させることはできなかった。

しかし、今回実際に自動化されていれば影響を最小限にできた事例が発生しましたので、これを教訓に改善を検討しております。

再発の防止

前述のとおり、データベースプログラムを自動起動すれば数分程度で復帰できたはずですので、再発防止はこの点を中心に検討しております。データ喪失に対処するためのバックアップなども含め、必要な作業を自動で行う仕組みを検討・整備していきます。

また、データベースだけでなく、他のサーバー（フロントエンドのWebサーバーやクローラなど）も現状では自動起動になっておりませんので、併せて検討を進めます。


今回も多くの障害報告をいただき、まことにありがとうございます。ご報告を活かして早期復旧に繋げることができなかったのは運営者の不徳の致すところですが、ご報告がなければ障害がさらに長引いたことは間違いありません。勝手なお願いになりますが、今後もお気付きの点がございましたら、ぜひご報告いただければ幸いです。

また、繰り返しになりますが、長期間の障害でご不便をおかけしてしまい、たいへん申し訳ございません。上記の通り改善に努めてまいりますので、今後ともなにとぞよろしくお願い申し上げます。