ファーストサーバの事故から考えること

つい先日、ファーストサーバというホスティング企業が多数の顧客の全データを喪失するという前代未聞の事故が起こりました。

twitterやfacebookでは技術者や弁護士など、様々な方々が色んな観点からの議論を始めています。

私としても、今回の事故から得られた教訓と、弊社でのデータ保全の取り組みについてお話ししたいと思います。


大規模障害の概要と原因について（中間報告） ファーストサーバ サポートWEB

こちらに中間報告があがっていますが、オペレーションミスによりサーバの削除タスクをバックアップ環境を含めた全サーバに対して適応してしまったという前代未聞の事故です。

動的にサーバのプロビジョニング(構成管理)を行う場合には、バグやオペミスによりデータを誤って消してしまうということは考えられますので、その点では作業手順やプログラムの安全品質については厳重な管理が必要と考えられます。

本質的な原因としては、このファーストサーバでは、ある時間の静的なバックアップ(スナップショット)を保存しておらず、そのために本番環境でのオペミスがバックアップまで波及してしまったということが言えます。

ホスティング企業では、膨大な顧客データを保持しており、銀行などのシステムに比べれば圧倒的に割安な価格でストレージ環境を顧客に提供していると考えられます。そのため、膨大なデータのスナップショットを取得するようなストレージ環境が用意できなかったことは原因の一つかと考えられます。

きしだなおきさんとも話したのですが、致命的ミスと言えるのは、待機系(スタンバイ)サーバと、バックアップを混同してしまっていたことだと考えられます。

待機系サーバというのは、あるサーバが故障で動かなくなったさいに代わりに立ち上げるサーバであり、そのデータは常に本番環境と同じデータを保持している必要があります。そのため、本番環境で行われたオペミスなどは待機系サーバにも波及してしまいます。

それに対し、バックアップというのは、基本的には「ある時点のデータ」を保存して、オペミスを含むデータ損失事故を防ぐというものです。

これはIT技術者にとって基本的知識だと思われますが、その点の配慮が無かったことが最大の敗因でしょう。


弊社では、データベースは毎日スナップショットを取得しており、データベース以外のファイルについてはバックアップでの上書きや物理削除を禁止する運用によって、データ損失事故を防ぐという思想で運用しております。

この思想により、今回のようなオペミス一回でデータ損失という事態は発生しないようになっております。

また、常時スタンバイサーバへのデータベースのレプリケーション(複製)を行っており、サーバ故障時には、バックアップ時点から更新されたデータについてもデータ損失を防ぐようになっております。

今回の事故の報に接し、大変に身の引き締まる思いであり、弊社としても、より一層のデータ保全への取り組みや投資を強化して行く所存です。

追記:

向井さんの見解として、まさかデータを消すような操作とは思わないから一気に全部のサーバに更新を適用しちゃったんじゃないの？ という見解がありました。そうなってくると昔ながらのテープバックアップなども再導入を検討するべきなのかもしれませんね。テープドライブが急に売れ出すという事態があるかもしれません。

再追記:

ちなみに私はファーストサーバ社を批難する意図でこの記事を書いているわけではありません。どんなシステムも100%のデータ保全性を保証することはできません。スナップショットを取る、テープにバックアップする、といったことはコストに大きく跳ね返ってくる選択肢です。

ファーストサーバ社がどれだけのデータ保全性を謳っていたのか分かりませんが、Amazon EC2であればAmazon EBSのデータは保全性が低いことが前提であり、顧客の判断でAmazon S3にスナップショットを取ることになっています。もちろん、そのスナップショットの保存は有料です。Amazon S3では低保全性モードでは、料金が安くなります。

サービス提供企業にとってデータ保全は事業継続性の上で非常に重要な問題ですが、利用者としてもホスティングというサービスが必ずしも高いデータ保全を目的として運用されるものではないこと、自社のデータについて最終的に責任を負えるのは自社しかいないことは考慮すべきであると思います。