2012/06/25

バックアップって言葉は意味が広すぎて大変 (ファーストサーバの件)

先日から世間を騒がせている件といえば鬼束ちひろ...はおいといて、我々の業界ではファーストサーバの件ですね。時間ねぇ〜って人は最後の結論だけよむといいかもしれない。

「特定の管理プログラムにバグが」とか発表されていて、こういうぼかした書き方をすると去年までサーバーベンダーで管理プログラムを作っていた身としては「あれ、もしかして...」と自分まで心配になってしまうのが怖いところです。

そんなことを思っていたら、今日の未明に中間報告という形で原因のあらましが出てきたようです。

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

まずこれの中身についてあーだこーだ書く前にとりあえず私のスタンスをはっきりさせておきましょう。

今回はレンタルサーバーの障害ってことで、普通レンタルサーバーにおいてあるサーバのユーザデータは普通ユーザがバックアップするもの...だと思っています。クラウドサービスとはそこら辺がちょっと違うわけですね。レンタルサーバー事業者はサーバーをレンタルしてるだけでユーザデータのバックアップまでは面倒見ないですよっていうのが一般的だと思います。

今回話がややこしくなったのはASPサービスの存在がひとつあるんじゃないでしょうか。ASPサービスをレンタルサーバーで提供すると、ASPサービスのユーザデータは誰がバックアップするのっていうのがなんか曖昧です。その辺約款とかに書いてあるのかなぁと思ったんですけど、どこにそれが書いてあるのかよくわかんないので調べていません。ただ、ASPサービスのユーザデータはサービス提供側がバックアップ取るべきじゃないかなぁというのがぼくの感想です。というか一般的なASPサービスってユーザデータは普通触れないようになってるんじゃないかなーというイメージ。

バックアップ環境ってなんぞや

さてさて、今回の大規模障害の原因を見ていくと、おおざっぱにいうと3種類のサーバがあることがわかります。1個は検証環境、もう1個は本番環境、あと1個がバックアップ環境となります。

この「バックアップ環境」っていうのが非常によくない呼び方なんじゃないかなぁと。

一般的なITリテラシーを持った人に「バックアップ」というのをイメージしてもらうと、普通はユーザデータをバックアップすることをイメージするでしょう。ほらマイドキュメントの写真が消えたら困るからUSB-HDDにバックアップしなきゃ! みたいな感じです。

で、この「バックアップ環境」っていうのはそのバックアップとは意味が違うんです。

ファーストサーバは稼働率100%保証を謳っていました。でも、100%で稼働するっていうのは1台ではありえないんですよ。ハードウェアはたいてい数年でどこか障害が発生します。なので、障害時にフェイルオーバーできるシステムを構築して可用性を高めることで、稼働率100%を確保します。

えーと、具体的な例でいうと、(1)サーバがHWレベルで二重化されて常時クロックが同期されているFTサーバとか、(2)同じサーバを2台用意しておいて片方を本番系、もう片方を待機系にするシステムとか、もしくは(3)システムを仮想マシンの上で動かして物理マシンに障害が発生してもシームレスに別の物理マシンに仮想マシンが移るシステムとかですね。

今回のファーストサーバは(2)のパターンで稼働率100%を目指していたと思われます。つまり、「バックアップ環境」っていうのは待機系のシステムだったんですね。それはどの辺から分かるかというと、原因3のメンテナンス仕様に以下のように書いてあることからわかります。

しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。

一文がながいよ(個人的な感想)。

注目するところは「ハードウェア障害が発生してバックアップに切り替え」るってところです。まさに本番系から待機系に切り替えるときのことを言ってます。

バックアップ環境はユーザデータのバックアップではない

ということで、ここまで見てわかったように、ここに書いてある「バックアップ環境」はおもにハードウェア障害でシステムが停止しないように可用性をあげるための待機系でした。

可用性を上げる待機系っていうのは、基本的にユーザデータのバックアップには何の威力も持ちません。物理的には本番系と待機系の2台の装置がありますが、論理的には稼働率99%くらいのハードウェアを2台組み合わせることで稼働率(ほぼ)100%の1台のハードウェアにすることを意図してシステムを構築しているだけです。システムの上に載っているユーザデータはバックアップされていないということです。

最初に書いたとおり、一般的なレンタルサーバーの約款ではユーザデータのバックアップは保証していないので、レンタルサーバー事業者としてはユーザデータのバックアップまではやらなくてもOK。稼働率100%を達成するための仕組みはちゃんと出来ていたと言えます。まぁアップデートにミスってシステム壊しちゃうのは検証がお粗末としかいいようがなかったですけど。

結論からいうと?

レンタルサーバーという事業の性質上、ユーザデータのバックアップ取ってないのはレンタルサーバー事業者の落ち度ではないでしょう。ただ、ASP事業のデータがロストしてるっぽいのは個人的にはASP事業者としてはヤバイのではないかと思います。

今回の中間報告を眺めると、ハードウェアまわりの構成自体は稼働率100%を目指せるようになってて特に問題なかったです。でも、オペレーションミスでここまで被害が甚大になるのはちょっとヤバイですね。

結局の所言いたかったのは、3日前くらいにつぶやいてた以下の140文字弱に凝縮されているのでした。

@acidlemon

ファーストサーバの件、SLA100%だからってユーザがバックアップしなくていい理由にはならないし、SLA100%が守れなくても返ってくるのはお金だけで万が一データが消えたらそれは返らないっていうのは平時からちゃんと説明しなきゃダメだね

2012/06/22 10:23

今回はミスによってすごい範囲に影響がでたようですが、別にこういうミスって珍しいことではないのではないかと思っています。ヒヤリ・ハットみたいなキーワードでググると危うく大惨事っていう事例は結構でてきます。ちょうど先日、Amazonでクラウドのシステム障害があって、それの原因は電源トラブルなんだけど、二重三重の防護策を立てていたのに全部倒れて障害になりました、というのがありました。

• Amazonクラウド先週のシステム障害、原因は電源トラブル。二重三重の防護策が次々と倒れる (Publickey)

この記事ではAmazonが昨年の障害以来、マルチアベイラビリティゾーンの設定をしておくようにユーザに喚起していたことが書かれていますが、これと同様にレンタルサーバー事業者もユーザデータのバックアップの必要性および重要性を喚起していかなければなりませんね。

静的なデータって普通手元からアップロードするだけなので手元にもデータ残りますが、サーバー側で動的に生成されるデータってサーバーにしか残らないので、ちゃんとダウンロードしないとバックアップできない。そういう意味で、これからのレンタルサーバー事業にはユーザが簡単にバックアップできるサービスが求められていくのではないでしょうか。