システム稼働率を図で理解する｜直列・並列・冗長化からSLOまで

01｜予約アプリが突然開けなくなったら

Next.jsで作成した予約フォームにアクセスすると、普段は数秒で画面が表示されます。しかしある日、Webサーバーの障害で応答しなくなりました。データベースのPostgresが正常でも、アプリの受付部分が動かなければ予約できません。反対にWebサーバーが正常でも、必須のDBが止まると予約処理は完了しない場合があります。

これは「上から下まで必要な部品がそろって初めて成功する」構成です。信頼性の観点では直列システムと呼びます。Supabaseの実際の内部構成や保証値を示すものではなく、理解するための抽象モデルです。

02｜稼働率とは何を表す数字ですか

稼働率（Availability、アベイラビリティ）は、対象のサービスが利用可能だった時間の割合です。24時間のうち22時間動いていれば、稼働率は22÷24≒91.67%です。停止時間を引いてから割るだけなので、まずは時計のイメージで考えます。

稼働率 A = 稼働時間 / (稼働時間 + 停止時間)
停止率 q = 1 - A
例: 22 / 24 = 0.9167 = 91.67%

03｜故障率と稼働率は同じではありません

ここで「故障する頻度」と「サービスが使える時間」を区別します。故障が頻繁でも数秒で自動復旧できる仕組みと、めったに壊れないものの復旧に3日かかる仕組みでは、ユーザーが感じる停止時間が異なります。

故障と修復を繰り返す装置の単純な定常モデルでは A = MTBF ÷ (MTBF + MTTR) です。ただし故障・修復の定義や観測条件が変わると、公式の適用範囲も変わります。

04｜直列構成：どれか1つ止まると全体が止まります

WebサーバーとDBの両方が必須なら、2つとも稼働している必要があります。Webが90%、DBが90%の確率で利用可能で、故障が互いに独立しているとすると、両方稼働する確率は0.9×0.9=0.81、つまり81%です。

直列2台: A = R1 × R2
同じ稼働率Rのn台直列: A = R^n
R = 0.9 → 2台直列は0.81

05｜並列構成：生き残ったサーバーが受け付けます

Webサーバーが2台あり、一方が故障してももう一方が利用者の要求を受けられる場合、両方が故障しない限りサービスは利用可能です。90%の装置なら1台の停止確率は10%。2台同時に停止する確率が0.1×0.1=0.01なので、全体の稼働率は1−0.01=99%です。

並列2台: A = 1 - (1 - R1)(1 - R2)
同じRの2台: A = 1 - (1 - R)^2
R = 0.9 → 0.99 = 99%

06｜構成A：Webサーバー2台の並列

同じ装置Xが2台あり、いずれか1台が正常なら動作できる構成をAとします。単体の稼働率をRとすると、A = 1−(1−R)² です。

07｜構成B：並列でも共通部品が止まれば全停止です

2台のWebサーバーを並列にしても、その先に必須の単一の認証装置やDBがあるなら、最後の装置が止まると利用できません。並列部分の稼働率に共通装置のRを掛けます。B = R[1−(1−R)²] です。

ロードバランサーが1台だけの場合も、同様の単一障害点（SPOF：Single Point of Failure、単一障害点）になり得ます。ここでは装置3台の独立故障を仮定します。

08｜構成C：直列の経路を丸ごと2組に複製します

Web＋DBを1つの必須経路と考え、それを2セット並列化したイメージです。各経路は2台直列なので稼働率R²。経路が両方停止する確率を引けば C = 1−(1−R²)² です。

データがどちらの経路でも正しく利用できることや、経路の切替えが成立することを前提にしています。現実のDBレプリケーションや整合性維持は、単純な数式以上に設計が必要です。

09｜数字で比較：A・C・Bの順になる理由

例としてR=0.9を代入してみます。A=0.99、B=0.9×0.99=0.891、C=1−(1−0.81)²=0.9639となり、A＞C＞Bです。

ただし、R=0.9という一例だけでは「0＜R＜1のすべてで同じ順位」とは証明できません。次の節で式によって確かめます。

10｜どの稼働率でも順位が変わらない証明

まずAとBの差は、B=R×Aであり0＜R＜1ですからA＞Bです。またR²＜Rなので、直列2台の1経路は単体装置より停止しやすくなります。したがって2経路を並列化しても、A＞Cです。

残るCとBは、式を展開すると比較できます。

B = R[1-(1-R)^2]
  = 2R^2 - R^3
C = 1-(1-R^2)^2
  = 2R^2 - R^4
C - B = R^3 - R^4 = R^3(1-R) > 0

つまり0＜R＜1なら必ず A＞C＞B です。R=1などの端点では等しくなる場合があるため、範囲条件にも意味があります。

11｜独立故障が崩れると数字はどうなりますか

直列・並列の積を使う計算では、故障が独立であることを仮定しています。しかし、2台のWebサーバーが同じラックの電源や同じリージョン、同じ設定ファイルを共有していれば、同時停止が起こり得ます。単純な並列式はそうした共通原因故障を織り込んでいません。

12｜ホットスタンバイ・コールドスタンバイと負荷分散

冗長化しても、無停止切替えや実行途中のトランザクション継続が自動的に保証されるわけではありません。そこには共有セッション、冪等性、DBレプリケーションなど別の仕組みが必要です。

13｜MTBF・MTTRを使って稼働率を求めます

平均故障間隔MTBFが1,000時間で、平均修復時間MTTRが10時間とします。故障と修復を繰り返す定常モデルでは、稼働率は1,000÷(1,000+10)≒99.0099%です。故障を減らすだけでなく、検知と復旧を早めることも稼働率を高めます。

A = MTBF / (MTBF + MTTR)
例: 1000 / (1000 + 10) ≒ 0.990099
MTTRが1時間なら 1000 / 1001 ≒ 0.999001

14｜稼働率99.9%の停止時間を実感します

99.9%は高い数字に見えますが、30日間では約43.2分の停止時間に相当します。99.99%なら約4.32分です。サービスの目標として使う場合は、対象時間や計測方法を一緒に示します。

15｜SLA・SLO・SLIは何が違いますか

SLI（Service Level Indicator）は実測する指標です。例えば「予約APIのリクエスト成功率」を指します。SLO（Service Level Objective）はその目標水準で、例えば「30日間の成功率99.9%以上」です。SLA（Service Level Agreement）はサービス品質に関する合意・契約で、達成できない場合の条件を含むことがあります。

16｜RTOとRPO：復旧の『時間』と『データ』を分けます

RTO（Recovery Time Objective、目標復旧時間）は、障害後どのくらいの時間で復旧するかという目標です。一方RPO（Recovery Point Objective、目標復旧時点）は、どこまで古い時点のデータへ戻ることを許容するかという目標です。30分で再起動できても、前日のバックアップしかなければ直近の予約を失うかもしれません。

17｜Supabaseを使う設計ではどこを見るべきですか

Supabaseを用いたアプリでも、利用者から見るとブラウザ・フロントエンド配信・API・認証・データベース・ストレージなど複数のサービスが組み合わさっています。予約の成功条件によって必須の経路が変わるため、どの要素が止まると機能が使えないかをノード図に整理します。

18｜操作ラボ：装置を落として確かめます

稼働率を変えたときのA・B・Cの数値を比較し、各装置をクリックして故障させてください。並列の片方だけが壊れたときと、直列の共通装置が壊れたときの違いが見えるようになっています。

19｜設計に使うチェックポイント

20｜まとめ：部品ではなく『経路』で考えます

稼働率の計算では、すべて必要な装置を直列、いずれかで代替できる経路を並列として捉えます。直列は掛け算、並列は「すべて停止する確率を1から引く」のが基本です。共通障害点や復旧時間、状態同期などを考慮すると、机上の数値を現実の設計へつなげられます。

まず利用者の操作がどの経路を通るかを描き、次に単一障害点を探し、最後に稼働率と復旧能力を設計する。この順番なら、新しいサービス構成でも応用できます。