ファーストサーバのデータ消失障害事故
6月20日に発生した、レンタル･サーバー業界の大手｢ファーストサーバ｣社での大規模なデータ消失障害事故は、私にとって大きな衝撃だった。私が運営にタッチしていた2つの法人で、数年前までファーストサーバを利用してきていて馴染みがあったからだ(後述)。その後偶々の理由で別の社のサーバーに替えていて何れも実害が無かったのは幸いだった。以下、1)レンタル･サーバーについての若干の説明、2)ファーストサーバの事故の概要、3)若干の感想を述べる。技術者の想定していた前提条件がことごとく裏切られるミスによる事故という点で、大げさに言えば、インターネット社会での福島原発事故に相当するものとの印象だ*1。
1) レンタル･サーバーとは
レンタル･サーバーとは、サーバー(コンピュータ･ネットワーク上でサービスを提供するコンピュータ)を自社内に置かず、月額等のレンタルで提供される外部のものを利用することをいう。利用するサービスは各種あるが、小規模法人のメールやホームページは、殆どレンタル･サーバーを利用したものといっていいと思われる*2。他に、ウェブ上で顧客サービス、会員サービスなどを行う場合もあるが、現在ではレンタル･サーバー、もっと大規模、複雑のものについてはクラウド･サービスという、何れも社外のシステムを利用するのが普通になってきている。
ここで、レンタル･サーバーとホスティング･サービス、クラウド･コンピューティングとの違いが気になり、改めて調べて見た。私は、ホスティングとは提供するサービスの内容を示す概念で、レンタルとは契約形態を指すのかと思っていたが、現在では両者は同義らしい。英語ではhostingだから、レンタル･サーバーは和製英語らしい。
クラウドとの違いは、人それぞれの思い入れがあり、市場での差別戦略もあって悩ましい。両者とも他社が提供するサーバーをネットを介して利用するものだ、と言ってしまえば身も蓋もないがそういう面もある。クラウドは、発展途上で未来があり、現時点では具体的に定義しづらいが、レンタル･サーバーよりも進歩した高級なものだ。そこにはサーバー利用分野と技術面で大きな飛躍がある。クラウドは今後ますます発展していくと私は思っている。
冒頭に述べた私の関係していた2法人でのレンタル･サーバーの利用事例を簡単に述べる。
第1の事例は、その前はNTT系のホスティングでメールとホームページを運営していた。このきっかけは、10数年前に通信回線をNTTのADSLにし、インターネットプロバイダーをNTT系(確か｢ぷらら｣)とし、その流れでNTT系のホスティングを使ったのだと思う。その後経費節減策の一環として、廉価だったファーストサーバのレンタル･サーバーを導入したものだ。ホームページでは、セミナーの申込等やウェブ･アンケートの実施等も行っており、使い勝手はまあまあだったと思う。
第2の事例は、その前は社内サーバーでメールとホームページを運営していた。ある程度ネットに詳しい職員がいたので社内サーバーの運営が可能だったが、数年前に経費節減策としてレンタル･サーバーに替えた。レンタル･サーバー数社を比較してもらって、ファーストサーバとした。ただ、社内のファイルサーバーの方は、社外へのサービスは無かったので、ネットにはつながず、社内だけのLAN(ローカル･エリア･ネットワーク)としてそのまま使うことにした(これは第1の事例でも同じ)。この社内サーバーについては、後でまた触れる。社外のレンタル･サーバーの利用は安全の面で心配だという意見もあったが、社内のサーバーを職員で運営することにもリスクがあるということで説得した。
何れも経費節減効果は大きかったが、それぞれ別の事情があって2-3年前にファーストサーバから別の社に切り替えた。例えば第1の事例の場合の切替は、私が関係無くなってからだが、メールの添付ファイルの容量制限が10MBと割に小さく、職員から大きくしてほしいとの声があった等の理由により、システム見直しの際に替えたとのことだ。
2) ファーストサーバの障害事故と原因
6月26日付け日経記事によれば、6月20日の障害により、データの消失があった顧客数は5698件で、そのうち大半の共有サーバーのデータは、データの復旧が不可能だという。実に甚大な被害だ。同記事によれば、被害企業として、小林製薬、109シネマズ、長野電鉄、カルディコーヒーファーム、海遊館、兵庫ひまわり信用組合、薬事日報、日本新聞協会、東京都卓球連盟、静岡産業大学、大津市市民活動センター、太陽光発電協会、ロボット学会、LOFT PROJECT(ライブハウス経営)などがある。同記事が伝えているユーザーの被害の具体的内容は甚大だ。
ファーストサーバの障害事故の原因は次のようなことらしい(6月25日のファーストサーバ社の発表(http://support2.fsv.jp/urgent/report.html)に基づく日経記事による)。
6月26日付け日経記事 http://www.nikkei.com/article/DGXNASFK2600L_W2A620C1000000/
ファーストサーバによると今回、脆弱性対策のために更新プログラムを作り、いつものようにプログラムを走らせた。ところが、その更新プログラム自体に大きなバグ(不具合)があった。すなわち｢ファイル削除コマンド｣を停止させる記述漏れと、メンテナンスの対象となるサーバー群を指定する記述漏れがあったというのだ。
ファーストサーバにおけるセキュリティ対策では、3つのHDDに同じファイルをコピーしていた。1つは｢本番系｣。もう１つは本番系のHDDやシステムに不具合が生じた時、即座に切り替え、正常稼働を続けるための｢待機系｣。もう１つが、毎朝6時に本番系のデータを丸ごとコピーしておく｢バックアップ系｣だ。この3つが、すべて同じサーバー内に同居していた。
バグに気づかないまま、本番環境のサーバーで更新プログラムを起動。だが更新プログラムは、対象外のサーバーでファイル削除コマンドを実行し、次々とデータを消去していった。･･･(すなわち)更新プログラムのバグは、本番系、待機系に加え、同じサーバー内にあるバックアップ系のHDDまでをも消去するという代物だった。
これを踏まえ、世の中の批判の多くは、3つのファイルを全て同じHDDに置いていたことが問題で、それではバックアップにならないということだった。それもそうだが、次のブログが、バックアップに関するファーストサーバの誤解の可能性を論じていて参考になった。
新井俊一 ｢ファーストサーバの事故から考えること｣http://shunichi-arai.blogspot.jp/2012/06/blog-post_25.html
致命的ミスと言えるのは、待機系(スタンバイ)サーバーと、バックアップを混同してしまっていたことだと考えられます。
待機系サーバーというのは、あるサーバーが故障で動かなくなったさいに代わりに立ち上げるサーバーであり、そのデータは常に本番環境と同じデータを保持している必要があります。そのため、本番環境で行われたオペミスなどは待機系サーバーにも波及してしまいます。それに対し、バックアップというのは、基本的には「ある時点のデータ」を保存して、オペミスを含むデータ損失事故を防ぐというものです。
これはIT技術者にとって基本的知識だと思われますが、その点の配慮が無かったことが最大の敗因でしょう。
実は私も、待機系とバックアップについて理解していなかったことを白状する。前述の社内に残すファイル･サーバーを検討する際に、RAID1とか5とかの説明を受けていた。RAID(Redundant Arrays of Inexpensive Disks)とは、ハードディスクの信頼性、可用性を高めるために、複数台のハードディスクを組み合わせる技術だ。RAID1は、2台のハードディスクを用い、全く同じファイルを同時に作成する(ミラーリング(鏡のこと)ともいう)。RAID5は、3台のハードディスクを用いる。私は、(経営者の立場で、本当にそんなことが必要かと思いつつ)担当者の熱心な主張に従い、RAID5にした。その後、職員が定期的にカセットテープにバックアップを取っているのを見て、RAID5にしたのにバックアップが必要なのかと嫌味を言った記憶があるが、今では恥かしい。*3
新井俊一氏の分析によれば、ファーストサーバの技術者は、私と同じ誤解をしていたのだろうか。少なくとも基本的理念は忘れていたのだろう。待機系サーバーというのはRAIDの概念であろう。改めてwikipediaで調べると、｢RAIDはバックアップの代替にならず、バックアップもRAIDの代替にはならない｣と書いてある。
3) 若干の感想
私は、かねてレンタル･サーバーないしクラウド･コンピューティングの流れの熱心なファンだった。安全面の問題を指摘する人も多かったが、利便性とコストのメリットがそれを上回り、安全面の懸念も技術開発等で解決していくであろうと考えていた。今回の事故により、そのような楽観に冷や水を浴びせられたようだ。
しかし、事故の原因を見ると、基本を忘れた技術者のミスのようである。福島原発事故についても、その原因の1つに、非常用電源を同じ敷地に置くという、(私の見るところ)設計ミスがあり、その遠因は安全に関する基本を忘れたことにあると思う。事故の影響についても、被害者が多い点、一般利用者ないし一般国民の新技術への信頼を基本的に損なったという点で似通っている。大げさに言って、ファーストサーバの事故がインターネット社会での福島原発事故だと言う所以だ。
この事故の経験を関係者間で共有化し、更に技術開発を進めれば再発は防げるとも思える。一方、人間のミスは常に起こり得るし、他のリスクもあるとの考えもある。何れにしろ、安全の追及は不断の努力の積み重ねにあるのであろう。
以下、個人的なクラウド利用への反省を述べる。企業のクラウド利用の主たる理由がコスト面にあるとすれば、個人のクラウド利用の理由は利便性にある。今、私は個人的に、Googleドライブ*4、カレンダー、はてな、Evernoteを利用し、相当のデータをクラウドに置いている。これらのクラウド大手以外にも、個人的家計簿他でクラウドのソフトを使っている。データの入力と結果が、パソコンとスマートフォン、タブレットの何れでも切れ目なく行え、甚だ便利だ。
しかし、今回の事故を見ると、これらは大丈夫だろうかと当然ながら心配になる。全部ローカルにバックアップしておかなければならないとすると相当面倒だ。ローカルと同期しているもの(GoogleDrive内のストレージされたファイルなど)はいいのだろう。はてなのブログのように公開しているものについては、Google検索のキャッシュ(cache)を使えばデータファイルをある程度は復元できるようで、覚えておいていいノウハウと思う*5。
だが、考えてみると、大したデータでもなく、消えたら消えたでしょうがないと思えばいい訳で、クラウドを信頼することにした。面倒なことをこの年になってわざわざしようというのは億劫だ。
*1:福島原発事故の原因をミスというには異論があろうが、原因の1つである非常用電源を離れた高い所に設置しなかったのは、設計上のミスと思う。
*2:レンタル･サーバーで利用されるサービスとしては、メール･サービスのメール･サーバー、ホームページのウェブ･サーバー、その他ファイル･サーバー等がある。
*3:もっとも、実際に障害が起きて、バックアップやRAIDが機能したことは無かった筈だ。
*4:Googleドライブとは、本年2012年4月にGoogleが発表したストレージ･サービスで、従来のGoogle Document(これはウェブ上)を含めて拡張したものだ。ローカルのソフト(ワード、エクセル等)で作ったファイルもサーバー上に保存し、サーバーとローカルとを同期してくれる。もちろん、スマートフォン、タブレットでも編集することができる。
*5:｢ファーストサーバのデータ消失事故の教訓｣参照http://pepalife.blog33.fc2.com/blog-entry-522.html 万が一の時は、Googleキャッシュが書き換えられるまでが勝負で、その間に保存しまくる。ちなみにGoogleに保存されているキャッシュは、「cache:http://webka.jp/special/rep/no_201206101p1.html」のようにURLの前に「cache:」を付けると検索できる。
