はじめに
この記事では、インフラを「専任ではないけど見ることになった人」向けに、可用性・ディザスタリカバリまわりの用語を体系で整理します。ネットワークやセキュリティの用語は範囲を広げすぎるので外し、「止まる・壊れる・復旧する」を語るための言葉に絞ります。
対象読者
アプリ／データ寄りのエンジニアで、インフラ構成の意思決定にも関わるようになった人。クラウドの DB やサーバーの可用性を、用語で会話できるようになりたい人。
例示は AWS（Aurora／RDS あたり）に軽く寄せますが、用語そのものはクラウド汎用です。
この記事の用語定義は安定した概念が中心です。ただしサービス固有の挙動や数値（SLA の保証値など）は変わることがあるので、実運用では各クラウドの公式ドキュメントで裏を取ってください。
1. まず復旧と可用性の「目標値」
可用性の議論は、ほぼここから始まります。RTO と RPO は必ずセットで覚えてください。片方だけだと判断を誤ります。
| 用語 | 正式名 | ざっくり何を表すか |
|---|---|---|
| RTO | Recovery Time Objective | 障害発生から復旧までの目標時間。どれだけ止まってよいか |
| RPO | Recovery Point Objective | どの時点まで戻せるかの目標。どれだけデータを失ってよいか |
| SLA | Service Level Agreement | 顧客と結ぶ品質の「契約」。破るとペナルティが発生する対外的な約束 |
| SLO | Service Level Objective | 自分たちで定める品質の「目標」。SLA より厳しく設定するのが通例 |
| SLI | Service Level Indicator | SLO を測るための実測指標。可用率、レイテンシ、エラー率など |
RTO は時間軸、RPO はデータ軸。図にするとこの 2 つが障害の前と後ろに分かれているのがよくわかります。
RPO は障害より「過去」を向いています。最後にバックアップやレプリカで守れた時点から障害までの差が、失われるデータです。RTO は障害より「未来」を向いていて、止まってから復旧するまでの時間。ここが頭の中で混ざっていたのが、私が固まった原因でした。
SLA・SLO・SLI は階層で捉えると一発で整理できます。SLI で測り、SLO を目標にし、SLA で約束する。この順番です。
2. 可用性の「数字」の読み方
「うちは 99.99% を目指す」みたいな話、聞いたことありませんか。あの 9 の数（ナイン）が何分のダウンタイムに相当するのか、即答できると会議で強いです。
| 可用性 | 通称 | 年間の許容ダウンタイム（目安） |
|---|---|---|
| 99% | ツーナイン | 約 3.65 日 |
| 99.9% | スリーナイン | 約 8.76 時間 |
| 99.99% | フォーナイン | 約 52 分 |
| 99.999% | ファイブナイン | 約 5 分 |
9 が 1 つ増えるごとに、許される停止時間がだいたい 10 分の 1 になります。99.99% でも 1 年に 52 分しか落とせない——前回の話に出た「5〜10 分の復旧時間」を数回やったら、それだけで年間予算を使い切る計算です。この感覚があると、RTO の数分が軽く見えなくなります。
可用性の裏側にある 2 つの指標も押さえておきます。
| 用語 | 正式名 | 意味 |
|---|---|---|
| MTBF | Mean Time Between Failures | 平均故障間隔。どれだけ壊れにくいか |
| MTTR | Mean Time To Repair / Recovery | 平均復旧時間。壊れてからどれだけ早く直せるか |
この 2 つで可用性はざっくり次のように表せます。
可用性 = MTBF ÷ (MTBF + MTTR)
つまり可用性を上げる手は 2 つしかありません。壊れにくくする（MTBF を伸ばす）か、早く直す（MTTR を縮める）か。MTTR は RTO の実測値みたいなものだと考えると、両者がつながって見えてきます。
3. 冗長化・フェイルオーバー構成
ここからは「どう冗長化するか」の語彙です。前回の reader 昇格の話は、まさにこのレイヤーでした。
| 用語 | 意味 |
|---|---|
| フェイルオーバー | 障害時に待機系へ切り替えること |
| フェイルバック | 障害復旧後、元の構成へ戻すこと |
| Active-Standby | 片方を待機させる構成。待機系を昇格させて切り替える |
| Active-Active | 両系を同時に稼働させ、負荷分散も兼ねる構成 |
| Multi-AZ | 複数のアベイラビリティゾーンにまたがって配置し、AZ 障害に耐える構成 |
| クォーラム | 多数決で正常ノードを決める仕組み。3 ノード構成などの根拠 |
| スプリットブレイン | ネットワーク分断で両系が「自分が正だ」と思い込む障害 |
Active-Standby と Active-Active の違いは、待機系を遊ばせるか働かせるかです。待機系がいれば障害時にすぐ昇格できるので RTO が短くなる。reader を消すというのは、この待機系を 1 つ減らす判断だったわけです。
スプリットブレインは地味に怖い障害なので一言。ネットワークが分断されると、両方のノードが相手は死んだと判断して、どちらも書き込みを受け付けてしまう。データが分裂します。これを防ぐのがクォーラム1で、「過半数を確保できた側だけが正」とすることで、分断時にどちらか一方を確実に黙らせます。
4. 障害の影響範囲を語る言葉
障害「が起きたとき、どこまで巻き込まれるか」を語るための用語です。構成レビューで一番使います。
| 用語 | 意味 |
|---|---|
| SPOF | Single Point Of Failure（単一障害点）。そこが落ちると全体が止まる箇所 |
| Blast Radius | 障害の影響範囲。1 つの故障がどこまで波及するか |
| 縮退運転 | Graceful Degradation。一部機能を諦めてでもサービス全体を生かす設計 |
| ヘルスチェック | 正常性を監視し、異常ノードを切り離す仕組み。フェイルオーバーの起点 |
SPOF は「無くす」だけが正解ではありません。無くすにはコストがかかる。だから「この SPOF は許容する、その代わり RTO は X 分まで延びる」と明示的に意思決定することが大事です。暗黙の SPOF が一番危ない。
ヘルスチェックは縁の下の力持ちです。これが正常性を検知してくれるから、フェイルオーバーが自動で走る。ヘルスチェックの判定が甘いと、死んでいるノードにトラフィックを流し続けることになります。
5. データ保護・レプリケーション
最後に、データそのものを守る側の語彙です。ここは RPO に直結します。
| 用語 | 意味 |
|---|---|
| 同期レプリケーション | 両系に書き込みを確定してから完了。RPO はほぼ 0 だが書き込み遅延が増える |
| 非同期レプリケーション | 主系に書いてから遅れて複製。速いが障害時にデータ損失の可能性 |
| スナップショット | ある時点のデータの静止コピー |
| PITR | Point-In-Time Recovery。任意の時点まで巻き戻す復元方式 |
| DR | ディザスタリカバリ。リージョン障害など大規模災害を想定した復旧戦略全体 |
同期か非同期かは、RPO とレイテンシのトレードオフそのものです。データを 1 件も失いたくない（RPO=0）なら同期、書き込み性能を優先するなら非同期。ここでも「何を捨てるか」を決めているだけなんです。
まとめ
可用性・DR の用語は、結局のところ「何を捨てるか」を会話するための道具だと、今回まとめてみて腹落ちしました。
- RTO（時間）と RPO（データ）は別軸。必ずセットで考える
- ナインの数は許容ダウンタイムに直結する。99.99% でも年 52 分
- 冗長化は「待機系をどう持つか」、影響範囲は「SPOF と Blast Radius」で語る
- 同期／非同期は RPO とレイテンシのトレードオフそのもの
私はこれを書くまで、RTO すら自信を持って説明できませんでした。同じように「マネージドに任せてたから意外と知らない」という人、けっこういるんじゃないでしょうか。もし構成レビューでこの語彙が役に立ったら、ぜひ教えてください。
次は、Aurora の実際のフェイルオーバー挙動を計測してみた話を書こうと思っています。
-
3 ノードなら過半数は 2。分断で 2 対 1 に割れたとき、2 の側だけが処理を継続し、1 の側は停止する。だから冗長化は 2 ではなく 3 から、という設計判断につながる。 ↩