ネットワークRAIDデータベースの考え方

兼ねてから、バックアップシステムについて、エンジニアとして考案してきて、一つの考え方に行き着いたので、指向性をブログに残しておきたいと思う。 まず大前提として、WEBサービスにおけるバックアップという事を基準に考えたい。

WEBサービスのバックアップについて

現在のWEBは、大きく分けて下記のデータ分類がされる。

1. ソースコードのバックアップ 2. データベースのバックアップ 3. 個別システムの各種データバックアップ 4. システムログのバックアップ

そんなに特質すべきことはないのだが、3番だけが、汎用的でないというか、各々のサービスによって内容が異なる為、ここはそれぞれのサービスで考えていただきたい。 これらのデータは、当たり前だが消えてしまってはサービスが継続できなくなるため、バックアップを取らなければならない。 そして、バックアップの考え方は以下の通り。

1. RAID1構成のディスクシステムとして、ハードウェア冗長化（HDD障害対策） 2. サーバー端末の冗長化（機器障害対策） 3. 拠点のディザスター対策（IDC障害やネットワーク障害の対策）

対策については、上記以外にもそれぞれのサービスによって存在するが、大きくこの３つを考えておけば、継続リスクは回避できるものが多い。 いわゆるバックアップをするということは、サービスを動かし続けるという事に他ならない。

SLAの考え方

企業に向けてWEBサービスを提供する場合などは、SLAというサービス品質保証契約を結ばされる場合がある。 この契約は、運営側としたら、命を掛けて保守しなければいけない為、非常に堅牢なバックアップシステムを組まざるを得なくなる。 実際にSLAってどんなものかというのを知らない人の為に記述しておくと、 WEBサービスは24時間365日継続して提供できて当たり前という事を前提に、 「サービスが停止してしまった場合、その停止している部分は、利用料は払わなくていいよね。」 という、取り決めなのである。 サービスが停止するって、一体どういう事が起きるのかわからない人は考えてもらいたい。 例えば、楽天市場で買い物をしようと思った時に、楽天市場がサーバーダウンしていたとする。 そしたら、せっかく買おうと思っていたのにユーザーは買えない。・・・そんなときはAmazonで買えばいいのだが、ここで困るのは、販売者の人。 購入者がいたにも関わらず機会損失を出してしまっているわけですよね。 フルタイムで動いていて、販売をしてくれるECシステムでサーバートラブルなんて起こった時には、販売する人は、リアル店舗でお店のシャッターを閉めているのと同じ状態というワケです。 当たり前ですが、こんな自体になったら、ECサービス運営会社は、非難轟々でしょう。 SLAは、サービス提供者が、こうした時のための保険として、サービス停止時に金額保証をどの位するかという事がかかれた契約書を交わすことが多いのです。

今回考えたいバックアップ方式とは？

サービス継続とバックアップの考え方は少しずれるところがあるのですが、そもそも、サーバーがダウンしてしまった時に、本当にハードウェアが故障していて、再起動できない状態になったとしたら、データをきちんと正常なハードウェアに保持していないと、それこそ停止していた時間以外にそれまで取得したデータもオジャンになってしまいます。 そこで、僕が兼ねてから考えていたのは、ハードウェアでは当たり前になっているRAID機能をネットワークで行うという方式がいいのではないかと考えて、それを実現するための方式を考えてみました。 ここでRAIDがわからない人は、wikipediaで知識をつけてからこの続きを読んで下さい。 ※Raid0 , Raid1 , Raid5が理解できれば十分です。 インターネットにおけるデータの保持は、HDD側でのRaid1がセオリーなのですが、僕は端末自体もエコシステム化して、HDD単体でいいという考え方です。 それをネットワーク上に存在する同スペック（容量など）の端末にコピーすることで、バックアップとしては十分に成り立つ上、経済的にも非常に効率的です。

エンジニアの指向性

そもそも、HDDやSSDはRaid1にしておかないと意味が無いというエンジニアも多くいますが、バックアップするタイミングや期間をどのくらいにセットするかで、ある程度のリスクは回避できるはずです。 バックアップ期間が24時間に1回だと、障害が発生した時に最大24時間分のデータロスが発生するかもしれないので、1時間に1度とか1分に1度とか、数秒毎などのような頻度になるはずです。 これも、感覚が短いと、システム負荷が高くなって仕方がなくなるので、データ容量との相談になりますね。 さすがに、本家のRaidシステムとの差としては、リアルタイムでのバックアップにならないのがどうしても仕方がないのですが、個人的な経験値からすると、プログラム構成や、サーバーのバランシング構成で、なんとでもなるので、1端末で完結させずに、グループサーバー構成にする設計が必要になるというワケですね。 AWSを使っている人は、インスタンスサーバーのバックアップにS3サーバーを使っているサービスが多いと思いますが、考え方は似ています・・・が、大きく違っている点としては、コピー先は、同じくインスタンスになっている事が望ましいという事ですね。 そして、それは、拠点を変えることで、かなりの障害リスクを回避できます。

既存にそんなシステムがあるか調査

NECのiStorageというサービスが、この考え方に近い事がググッた結果わかりました。 このシステムは非常に優秀で、アーカイブや各種バックアップアルゴリズムにも対応しているようですね。 そして残念なのが、同一インフラでしか動かないようです。（※資料をざっくり見た限りの判断です） インフラ内で複数のサーバーを構築して、それぞれデータの受け渡しを柔軟に行う仕組みなんですかね？ でも、実際こうした仕組みをつくるのって、DataWereHouseを設計したことがある人なら、どれだけ難しいかよくわかると思います。 何が難しいかというと、リアルタイムでのデータミラーリングなんですよね。 WEBサービスのサーバー構成によっては、１台のサーバーにデータが書き込まれたら他の全てのバランシングサーバーが同じデータを参照できるか、各サーバーに瞬時にデータコピーするというのが条件になります。 兼ねてから、金曜ロードショーでラピュタが上映されたときの「バルス」とか、２ちゃんねるの「まつり」とか、DDoS攻撃のような、アタックなど、サーバー障害は昔からキャパシティに対しての設計が柔軟にできないところに問題があるんですね。 インターネットが普及して２０年以上経つのに、未だにこのリスクが変わっていないということにも非常にもどかしさを感じますが、ここはインターネットの特性として「そういうもの」と割り切るしか無いでしょう。 エンジニアであれば、これを解決する手段を考えたいところなんですが、今回は、ネットワークRaidをつかて、死なないサービス設計をするという事が伝わってくれれば、ひとまず僕の考えてた事がまとまったという事です。

あとがき

未だにSQLを神のように信じ切っている人や、NoSQLを救世主の様に扱っているエンジニアも多いので、設計こそ全てだという思考に切り替えてもらいたい若手も多いと感じるのが、シニアエンジニアの僕の意見でもあります。 是非、もっと他にいいバックアップ方式があれば、教えて欲しいのですが、こうした考えに共感してもらえるエンジニアの人がいれば、ネットワークRAIDをシステムとして構築しようとも考えています。 そんな奇特なエンジニアの方、いらっしゃいましたら、ご連絡ください。