インタビュー
データ消失事故から3年、変革を決意 ファーストサーバはサーバーを捨てて中小企業の救世主となる
（2015/4/16 06:00）
2012年6月、レンタルサーバー事業を営むファーストサーバは、大規模なシステム障害を起こし、顧客から預かっていたサーバーデータを消失するという事故を起こした。インターネット黎明期の1996年7月に創業し、当初からレンタルサーバー事業を営んで規模を拡大してきた同社にとって、この事故は痛恨のミスであった。
それでも同社は、さまざまな対策や組織としての取り組みを実施して改善に努め、事業を継続してきた。もちろん去っていく顧客も少なくなかったが、真摯（しんし）な対応が評価されたためか、現在でも多くのユーザーが同社のサービスを利用し続けている。
そして2015年2月、新しいブランドとしてZenlogicを発表。第1弾となる「Zenlogicホスティング」を、同日から提供開始した。この発表は、“レンタルサーバー事業者がサーバーを捨てた”サービスとして話題となった。
それまで毎年のように新しいサービスを打ち出してきた同社にとって、この発表までの2年半は、我慢の年月だったが、レンタルサーバー事業者として抜本的な改革となるZenlogicホスティングには、さまざまな思いが込められていることだろう。
当時、ファーストサーバに何が起きたのか。その後、どのような対応・対策を講じて、再発防止に努めたのか。そして、新しいZenlogicとはどのようなサービスであるのか。代表取締役社長の村竹昌人氏に話をうかがった。
事故当時、何が起こっていたのか？
──事故の発生した2012年6月20日、ファーストサーバのシステムには何が起きていたのでしょうか？
この事故は、2段階にわたって発生しました。
当時、我々は一部のサーバーに発生していた脆弱性を解消するためのメンテナンス中で、ソフトウェアアップデートを行っていました。実際には、独自に作成した更新用のスクリプトを実行するという作業でした。このスクリプトにバグがあり、実行するとメンテナンス対象外のサーバー内のデータをすべて削除するようになってしまっていたのです。
トラブルに気づいたのは、サーバーからアラートが発せられてきたころで、アップデート作業は緊急停止しましたが、結果的にサーバー5676契約ものデータを、バックアップも含めて失っていました。これが、第1の事故です。
第2の事故は、データを消失したことに気づき、何とか復旧しようと試みたときに発生しました。我々は、OS上はデータを削除したことになっていても、ハードディスク上にデータが残されていると考え、さまざまなデータサルベージ手段を模索していました。
あるデータ復旧ツールを用いたところ、ファイルが復元できたのです。できるかぎり顧客へデータを返したいという思いから、復旧データとして戻したのですが、実はこれが早計でした。ファイルに不整合が発生し、権限のないユーザーがデータへアクセスできるようになっていたのです。
すぐに復旧データを引き下げ、ユーザーにもデータの削除を依頼しましたが、しばらくは閲覧可能状態になっていたため、アクセスログを精査する必要がありました。
その後、ハードディスクの検証を行った結果、データを安全に取り戻すことは困難であることがわかり、事故の1カ月半後にデータ復元の断念をアナウンスすることになりました。
──この事故の原因はどこにあったのでしょうか？
当社では、外部の専門家に依頼して「第三者調査委員会」を設置し、原因の究明と対策の立案をお願いすることにしました。その結果、3つの原因に対する抜本的な対策が必要であることがわかりました。
まず1つは、組織体制です。開発チームと運用チームの権限があいまいで、業務内容が重複する部分もあり、互いにチェックし合える状態になかったのです。
我々は、創業以来18年にわたってレンタルサーバーサービスを提供しており、ビジネスの拡大や事業の拡張に合わせて、その都度プラットフォームを増強してきました。中には古いプラットフォームもあり、ソフトウェアやハードウェアで大きく分けて5世代分、OSのバージョンやミドルウェアの違いを加味すれば21のサービスが稼働していました。特にミドルウェアを担当するエンジニアは中間組織的な役割を担っており、開発と運用の両方を担当するという状況すら発生していました。
専門性の高い領域では、属人的な保守・運用があり、十分な管理体制がとれていませんでした。
2つ目は、データバックアップの仕組みです。当時は同一筐体内に装備されたハードディスクにデータをコピーするという仕組みを採用しており、遠隔地などにネットワークバックアップを取るという仕組みを設けていませんでした。
3つ目はリスクマネジメントの不備です。すでに述べたように。運用と開発の境界線があいまいであったり、属人的な運用を行っていたりと、体制に問題があったことは事実です。こうした大規模な障害を想定したトラブルへの対応フローが整えられていなかったことは、第2の事故の原因となりました。ユーザーサポートも、逐次対応に追われる日々が続きました。そうしたトラブルの原因となりうる業務フローや承認プロセスの不備、スタッフの負荷や課題などを見直す体制・機会がなかったことも問題でした。
抜本的対策でリスクの徹底排除を図った
──こうした問題に対して、どのような対策をしたのでしょうか？
システムの改良はもちろんですが、まず我々が注力したのは業務や組織の改善です。事故の2カ月後、リスクマネジメント委員会を設置し、再発防止策を実行に移す作業を進めました。
まずは、ISO27002の一部をベースとして、データロストやサービス停止、情報漏えいなどのリスクを洗い出す「GAP分析」を実行しました。この結果を基に、業務プロセスのルール化と順守を徹底、ツールを活用して事象を定期的に分析し、業務の改善を図りました。また、ISO27001への取り組み自体も強化し、事故の評価基準を見直して改善に努めました。
GAP分析と同時に、全社員にヒアリングして「ヒヤリハット」をまとめる作業も行いました。最終的には、重複を含め約600件のリスクが挙げられました。
事故対応と再発防止策の実行が落ち着いたころ、2013年の半ばから、さらなる改善策として「コミュニケーションの促進」を図るべく、さまざまな取り組みを行いました。
当社はもともとトップダウンの文化が強く、また属人的な業務が中心であったことからわかるように、業務を透明化するという意識に欠けていました。そこで、基本的なコミュニケーションを学ぶセミナーやインタビューから始め、ワークショップなどのディスカッションの場を多く設けるようにして、とにかく会話できる環境を整えました。
加えて、会議の資料や議事録などをオープン化して、周りから見られていることを認識させる「見られる化」を進めました。これまで各担当者の“分野”を超えた情報共有はほとんどなされていませんでしたが、その垣根をなくそうという試みです。
当初こそ、ぎこちなかったものの、スタッフ全員が「何とかしなければ」という意識を強く持って取り組みへ参加してくれました。徐々に慣れてきて、現在では専門分野の異なるスタッフどうしが積極的に話し合い、協力し合う場面が増えています。さまざまな防止策の中で、最も効果的な施策だったと言っても過言ではないでしょう。
ファーストサーバがサーバーを捨てた“ワケ”
──2年半の苦節を乗り越えて、新しいサービス「Zenlogicホスティング」を立ち上げましたね。
さまざまな問題はあったものの、やはり煩雑化したプラットフォームが根本的な原因だと考えていました。事故の一次対応後、プラットフォームを再構築すべきかどうかでかなり悩みました。もともと事故の前から課題として取り組んでいたものの、抜本的な解決策を打ち出すことができていなかったのです。
最終的に我々は、顧客に一番近いところで、安心して利用できるサービスを提供することが重要であることに気づきました。
事故以来、顧客と直接話をする機会が増えて気づいたことがあります。現在では、どんなに小さな企業でもWebサーバーやメールサーバーを持つことが当たり前の時代になっています。当社が最も注力しており、得意としているのも、そうした中小企業のユーザーです。
最も驚いたのは、ホスティングサービスとコンシューマ向けのクラウドストレージサービスとを比較して、「もっと◯◯みたいに使いやすくしてよ」というユーザーの声があったことです。技術に不慣れなユーザーから見れば、Webから利用できるサービス、ということに違いはないのです。安定的に利用できればよく、サーバーやリソースの状況などは気にならないのですよね。
これは衝撃的でしたが、我々のユーザーのニーズなのだと理解しました。我々が持つべき競争力は、インフラの運用ではなく、カスタマーサポートを中心としたサービスであると悟ったのです。
そこで、サーバーリソースはYahoo! Japanが提供するIaaS基盤に移行して、インフラの運用は任せてしまうことにしました。一からプラットフォームを再構築し、これまでどおりに運用することに比べて、運用コストを圧縮できることもわかっていました。
インフラの運用に投入していたエンジニアリソースをサービスの強化に割り当てられるようになったおかげで、サービス品質の向上も図れます。
通常のレンタルサーバーでは提供できないさまざまなメリットを実現
──Yahoo! JapanのIaaSを基盤としたことによるメリットには、どんなものがあるのでしょう。
一般的なレンタルサーバーは、複数のユーザーの環境を1台のハードウェアに収容するベストエフォート型のサービスであるため、パフォーマンスが一定的でないという課題があります。例えば、あるユーザーのWebサイトにアクセスが集中すると、ほかのWebサイトのレスポンスが悪化してしまうのです。
Zenlogicのインフラは仮想専有型のサービスであるため、ほかのユーザー環境から影響を受けることはなく、専用サーバーと同等のパフォーマンスを実現しています。また、ビジネスの拡大や商戦などの時期に応じて、リソースを柔軟に拡充することが可能です。
またレンタルサーバーの場合、システムのパフォーマンスはハードウェアに依存します。数年後に新しく高性能なハードウェアが登場してきたら、新しいサービスとして再開発する必要がありました。最終的にハードウェアの老朽化が進めば、ユーザーに移行を迫ることになります。移行や設定の作業も、ユーザーに任せることになっていました。
IaaSを基盤とするZenlogicホスティングであれば、ハードウェアに変更があってもユーザーの環境には影響しません。面倒な移行作業を必要とせず、長期間にわたって安定的なサービスを受けることができます。
──こうした特徴を生かして、どのようなサービスを目指していきますか？
現在、クラウドサービスの分野では「Amazon Web Service（AWS）」が人気です。しかしながら、適切に利用しようとすると、技術的な専門知識が必要になってしまうのが現状です。専門のエンジニアを確保するのが困難な中小企業ユーザーにとっては、ハードルが高いサービスとなっています。
我々が目指すのは、AWSのような柔軟性を持ちながら、レンタルサーバーのように手軽に、かつコンシューマ向けのWebサービスのように簡単に使えるサービスです。そのままではなかなか使いづらいIaaSを、我々のサポートで使いやすくするというコンセプトになりますね。
我々は、できるかぎりシンプルなシステムとして管理できるように、統合されたコントロールパネルを用意しました。そして、設定や運用などのサポートだけでなく、さまざまな問い合わせに応えられる体制を整え、中小企業の「よろず相談窓口」となることを目指しています。
2月の発表後、“サーバーを捨てる”ことに驚かれることも多かったのですが、同時に「すごくよい」と期待してくれる声も多く聞かれました。既存のユーザーには、2015年7月をめどに移行ツールの提供を開始し、無理のない移行計画を立てられるようにサポートしていく予定です。中小企業のお客さまにも簡単に使えるクラウドサービスとして、さまざまなユーザーに使っていただきたいと考えています。
──最後に、将来の展望について教えてください。
今後は、さらに中小企業の支援を強化する施策を打っていきたいと考えています。
例えば、業務アプリケーションを自社開発することも考えていますし、優れたサードパーティ製サービスを導入するのもよいでしょう。システムインテグレータなどとの契約が困難な企業は、マネジメントサービスを期待しているかもしれません。
そもそもどのようなリソースが必要なのか、どのようなシステムを展開すればよいのか、検討段階からサポートするサービスも視野に入れています。
中小企業の強力な味方となって、再び「ファーストサーバを使いたい」と思えるサービスを提供していきたいですね。