クラウドの可用性SLAを考える

昨日の月曜の丸一日、さくらインターネットのDBサーバ障害でブログが完全に止まっていました。どうもすみませんでした。このブログはWordPressで作っているのですが、WordPressはデータベースから動的にページを構築する仕組みになっているため、DBサーバが止まると閲覧も不可能になってしまいます。また、このサイトではトップページからいきなりWordPressのブログになっているため会社サイトが全滅状態になってしまいます。トップページくらいは静的ページで作り直しておいた方がよかったのかもしれません。

さて、クラウドと呼ぶかどうかにかかわらず、外部のホスティング・サービスにおける可用性のサービス・レベルが重要であることは言うまでもありません。通常、可用性のサービス・レベル保証（SLA）は、年間あるいは月間の合計ダウン時間をパーセンテージで表わすことが多いと思います。たとえば、99.75%の可用性を保証する等です。

どのレベルの可用性が必要かは業務次第ですが、一般的な業務アプリケーションでは99.75%はそんなに悪くない数字です。99.75%の可用性とはは年間合計ダウン時間およそ22時間ということになります。

しかし、利用者の立場から言うと、1時間程度のダウンが年間22回あるのと、22時間連続でダウンする障害が1度あるのとでは全然インパクトが違います。前者は許容できても、後者は許容できないというケースは多いでしょう。当社のブログだってたまに1時間くらい止まるのは全然OKですが、1日使えないと結構困ります。

ということで、クラウド事業者と可用性SLAの交渉をする際には、合計ダウン時間だけではなく、障害1度当たりの回復時間、いわば、MTTR（Mean Time To Repair）に関する検討も必要と思います。

また、障害発生時にどの程度の見える化ができているかも問題です。今回の障害では朝一に障害が発生してから、正式の告知が出るまでかなりの時間がかかり、前述の静的なお知らせページを作るべきかどうかの判断が付かなくて困りました。「修復に時間を要する」というのは悪い知らせですが、「時間を要するか要しないかわからない」というのはもっと悪い状況です。まあ、当社のブログくらいならたいした話ではないですが、企業アプリケーションであれば、手作業による業務継続を起動するかどうかはかなり重要な意思決定です。

というわけで、クラウド事業者との可用性SLAの交渉においては、障害報告までの時間、障害時のサービス窓口の応答性なども考慮に加えておくべきでしょう。