可用性パターン

2つのフェイルオーバー方式

Active-Passive(現用・待機)

レジ係が1人(active)働いていて、後ろに予備の店員(passive)が控えているイメージ。働いている店員は定期的に『生きてるよ』という合図(heartbeat)を予備に送ります。合図が途切れたら『倒れた』と判断し、予備が前に出てレジ(=同じIPアドレス)を引き継ぎます。

• hot standby: 予備が常に温まっていて即座に交代(ダウンタイムほぼゼロ)。
• cold standby: 予備は普段眠っていて、起動に時間がかかる(その間サービス停止)。

Active-Active(両方稼働)

レジを2台とも開けて、お客さんを分担するイメージ。両方が働いているので負荷も分散できます。片方が倒れても、もう片方が全員を捌きます(混むけど止まらない)。ただし、公開サービスならDNSが両方のIPを知っている必要があり、内部サービスならアプリ側が両方を知っている必要があります。

図を描画中...

可用性は数字で掛け算する

ここが地味につまずくポイント。コンポーネントを直列につなぐと稼働率は下がり、**並列(冗長化)**にすると上がります。

直列(両方が生きていないと成立しない)

Availability(全体) = Availability(A) × Availability(B)
例: 99.9% × 99.9% = 99.8%  ← 下がった!

部品を直列に増やすほど、全体の稼働率は『下がって』いきます。鎖は一番弱い輪で切れる、というイメージ。

並列(どちらか1つ生きていれば成立する)

Availability(全体) = 1 − (1 − A) × (1 − B)
例: 1 − (1 − 0.999)² = 99.9999%  ← 大幅に上がった!

冗長化(同じ役割を並列に複数)すると、『両方同時に落ちる確率』だけが障害になるので、稼働率は劇的に上がります。

図を描画中...

つまずきポイント

• 「サーバーを増やせば必ず安定する」は半分正しく半分間違い。並列(冗長)に増やせば稼働率は上がるが、直列(依存先として)増やすと逆に下がる。
• active-activeは負荷分散も兼ねられて魅力的だが、両方が同じデータを書く場合は競合(後述のmaster-master)の解決が必要になる。