ファーストサーバのデータ消失事件を見ていて雑感など
先週はファーストサーバ株式会社がサービスしているレンタルサーバでデータ消失事件が発生し、一部では何かと話題になっていた。サイボウズや EC CUBE をエンドユーザには ASP 的に売っていたこともあって、スケジュールが消えたりトランザクション情報が消えたりと何かと大変だったらしい。
個人的にはバックアップを取っていない状態で RAID5 が崩壊したりしたこともあったし、何よりも業務として SaaS 的なものをいくつか扱っていることもあって、今回のインシデントは決して対岸の火事ではなく、他山の石としたい事例だった。後出しじゃんけんにはなるが、いくつか思ったことを書いておきたい。
6/30 時点で「大規模障害の概要と原因について（中間報告）」が上がっているが、これを読む限りは今回のポイントはいくつかあって、ファーストサーバ側だと
- そもそも「別のマシンでバックアップを取っている」と書いて売っているのに「同じマシンの別ドライブにバックアップ」だったのは違うのではないか? → ウェブサイト側に修正が入った
- バックアップ「環境」と「データのバックアップ」は別物じゃないのか?
- 複数世代管理されていないバックアップはバックアップとはいわない。
- スタンバイ機を更新したときにデータ保全まで検証できなかったのか?
- そもそもバックアップ系のスクリプト作成タスクは、バックアップを書き戻す手順まで作って初めてタスク完了じゃないのか?
- SLA100% って相当コストがかかるよね? 無理じゃない?
- 実は社員が地雷を仕込んでいたのではないか? バックアップ・リストアスクリプトのコードレビューはやった?
あたりだろうか。特にバックアップの複数世代は本当は重要で、今回はたまたま問題発生後すぐに分かったからいいものの、実運用では問題発生から数日～数週間後に判明することも多い。バックアップを 1 世代しか取っていない場合はこういうケースで詰んでしまう。レンタルサーバの場合、1 顧客に割り当てる見込みディスク容量が非常に多いこともあって複数世代バックアップは難しいが、SLA100% を謳うならやはり外せないポイントだろう。
残念ながらエンドユーザとしても気をつける点はあって、
- 安いのには安い理由がある。大事な情報を扱うならそれなりにコストをかけるべき。
- 取れるならバックアップは取る。
といったところだろうか。ここでいう「コスト」はあくまでミクロ経済学的な「コスト」であり、単純に出費ではない。たとえばバックオフィスにかけられる費用がかなり限定されているのであれば、顧客情報などは別途紙ベースで管理しておくなどが挙げられる。正直面倒なのだが、顧客情報やトランザクション情報を自分のコントロール下におけないというのはかなり問題だと思う。
また、「取れるなら」と書いたのは、ソースはないが、一部でファーストサーバでホスティングされていたサイボウズはユーザがバックアップを取れないように修正されていたという話を聞いたから。
振り返って見ると、業務では割と「複数世代バックアップをデータセンタとは別の場所に取る」については実践されていると思う。だが、個人環境では
- 各サーバ・インスタンスのバックアップは定時に NFS マウントされたファイルサーバに取る。
- バックアップ先のディスクは RAID5。
- ファイルサーバはバックアップ完了後に、同じマシンの別ディスクに 5 世代分バックアップをコピーする。
- ただし、ファイル共有部分のバックアップは 2 世代で定時に rsync。
といった運用で、イマイチ励行できていない。これだとファイルサーバが炎上したりするとどうしようもなくなるので、いずれ対策を考える必要があるのだろう。
個人環境については、たとえばどうしても消せない XXX 動画があるといった特殊な事情を除いては、データ保全は業務水準である必要はない。だが業務となるとそうはいかないが、どうしても見えにくい部分のコストのため、決裁権者の決裁を取りにくいというのは否定できないだろう。申し訳ないが今回の事件はその決裁のための判断材料としては大きいものだと思うので、まさに他山の石とすべきだと思う。
また、決裁権者側としては、現場に負荷がかかりすぎていたり(いわゆるブラック)すると、どうしてもこういったミスが起きやすくなる。福利厚生やワークライフバランス的な視点だけでなく、潜在的なリスクを低減させるためにも、現場の仕事量は適度な量になるようにする必要があるだろう。
最後に、Twitter上での参考となる togetter:
