高可用性・災害復旧

01

障害は必ず起きる：可用性の数字と単一障害点

可用性は、サービスが使える状態だった時間の割合です。99.9%はかなり高く見えますが、1年に直すと約8時間45分止まるという意味です。9が1つ増えるたびに、許される停止時間は10分の1に減り、そのぶんコストも設計の難しさも上がります。

直列につなぐと下がり、並べると上がる

サービスは、いくつものコンポーネントがつながってできています。Webサーバー、アプリサーバー、DBを順に通ってはじめて応答が返るなら、3つとも動いていなければなりません。だから全体の可用性は、それぞれのコンポーネントの可用性の掛け算です。99.9%のものを3つつなぐと、約99.7%に下がります。逆に、同じサーバーを2台並べておくと、両方が止まらない限り止まらないので、その層は99.9999%まで上がります（2台の障害が互いに独立していると仮定した場合）。下の図で、層ごとに2台に増やしてみましょう。

1つ止まるだけで全体が止まってしまう場所を単一障害点（SPOF）と呼びます。高可用性の設計とは、単一障害点を見つけて1つずつなくしていく作業です。サーバーだけではありません。DB、ロードバランサー、ネットワークの経路、さらには「このサーバーの設定を知っているただ1人の人」も単一障害点になりえます。

SLAは保証ではなく、補償の約束

クラウドのサービスは、それぞれSLA（サービスレベルアグリーメント）で月間の稼働率を約束しています。ただしSLAは「必ずこれだけ動く」という保証ではなく、「守れなかったら料金の一部をクレジットで返す」という約束です。止まっていたあいだの損失を埋めてくれるわけではないので、自分のサービスの可用性は設計で作る必要があります。同じサービスでも、サーバー1台のときより、複数のゾーンに分けて置いたときのほうがSLAは高くなります。

単一障害点をなくそうと、サーバーを2台に増やしました。では、その2台が同じ建物にあったらどうでしょう？

02

障害の大きさ：サーバー、ゾーン、リージョン

障害には大きさがあります。サーバー1台のディスクが壊れることもあれば、データセンター1か所が停電・火災・ネットワーク障害で丸ごと止まることもあり、まれに地域全体が自然災害や大規模な障害で止まることもあります。1回の障害が影響を及ぼす範囲を影響範囲（ブラスト半径、blast radius）と呼びます。

クラウドは、この範囲を可用性ゾーンとリージョンに分けて見せてくれます。リージョンは東京や大阪のような地域で、その中に、電源・冷却・ネットワークがそれぞれ独立したデータセンターの集まりである可用性ゾーンがいくつもあります。ゾーン同士は同期レプリケーションができるくらい近く（遅延は数ミリ秒）、1つのゾーンの災害がほかのゾーンに広がらないくらいには離れています。

ほとんどの本番サービスは、複数のゾーンを基本にしています。同じリージョンの中なので遅延が小さく、DBを同期レプリケーションでき、ゾーンの障害にも耐えられます。リージョンの障害まで耐える必要がある場合（法律・規制、とても大きなサービス）に限って複数のリージョンに広げます。その方法が、7章の災害復旧の戦略です。

どこまで耐えるかを決めるには、まず目標が必要です。止まってもよい時間と、失ってもよいデータは、どれくらいでしょうか？

03

何をどこまで守るか：RTOとRPO

災害復旧を設計するとき、最初に決める数字が2つあります。RPO（目標復旧時点）は「障害が起きたとき、どれだけのデータを失ってもよいか」を時間で表したもので、RTO（目標復旧時間）は「どれだけ長く止まっていてもよいか」です。

障害の時点を真ん中に置いて見ると、わかりやすくなります。さかのぼって、最後にデータを守っておいた時点（最後のバックアップやレプリケーション）までが失うデータ、つまりRPOです。先に進んで、サービスを再開するまでが止まっている時間、つまりRTOです。ここがつまずきやすいところで、RPOは「過去」、RTOは「未来」を向いています。下の図で、データの守り方と復旧のしかたを変えてみましょう。

2つの目標は、技術ではなくビジネスが決めます。注文システムは1分止まるだけでも損失が大きく、注文を1件も失ってはいけませんが、社内レポートのシステムは1日止まっても大丈夫かもしれません。目標を短くするほどコストが上がるので、システムごとに損失とコストを比べて決めます。復旧にかかるコストが、障害で失うものより大きいなら、その目標は高く設定しすぎです。

目標が決まったので、次は止まらないようにする番です。まずは、リクエストが急に押し寄せたときにサーバーが耐えられるようにする方法から見ていきましょう。