冗長化完全ガイド — 99.999%可用性の秘密

可用性 = 正常運用時間 / 全体時間 × 100%

正常状態:
  [Activeサーバー] ←── すべてのトラフィック
  [Standbyサーバー]    (待機、同期のみ)

障害発生:
  [Activeサーバー] ✗   障害検知！
  [Standbyサーバー] ←── トラフィック切り替え（Failover）
        ↑
    新Activeに昇格

# KubernetesでのActive-Standby: StatefulSet + Leader Election
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-ha
spec:
  replicas: 2 # 1 Active + 1 Standby
  selector:
    matchLabels:
      app: redis
  template:
    spec:
      containers:
        - name: redis
          image: redis:7
          ports:
            - containerPort: 6379
        - name: sentinel # 障害検知 + 自動Failover
          image: redis:7
          command: ['redis-sentinel', '/etc/sentinel.conf']

正常状態:
  [サーバーA] ←── トラフィック50%
  [サーバーB] ←── トラフィック50%
      ↑
  Load Balancerが分散

障害発生:
  [サーバーA] ✗   障害！
  [サーバーB] ←── トラフィック100%（自動）

# Kubernetes Service = 自動Active-Active
apiVersion: v1
kind: Service
metadata:
  name: my-api
spec:
  selector:
    app: my-api
  ports:
    - port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 2 # 両方Active！
  template:
    spec:
      containers:
        - name: api
          image: my-api:latest
          readinessProbe: # 障害検知
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 5
            failureThreshold: 3 # 3回失敗 → トラフィックから除外

N+1: N台必要なところに1台追加（最小限の余裕）
  [サーバー1] [サーバー2] [サーバー3] [+予備1]
  → 1台落ちてもOK

N+2: N台必要なところに2台追加
  [サーバー1] [サーバー2] [サーバー3] [+予備1] [+予備2]
  → 2台同時に落ちてもOK + 1台メンテナンス可能

2N: 全体を2倍に（最もコスト高）
  [サーバー1] [サーバー2] [サーバー3] [サーバー4] [サーバー5] [サーバー6]
  → 半分が落ちてもOK（ミッションクリティカル）

二重化でネットワーク断絶時:
  [サーバーA] ──✗── [サーバーB]
  「Bが落ちた？自分がActive！」  「Aが落ちた？自分がActive！」
  → 両方Active → データ不整合 → 大惨事！

三重化（3ノードクラスター）:
  [ノードA]──[ノードB]──[ノードC]

ネットワーク分割時:
  [ノードA]    [ノードB]──[ノードC]
  1票（少数）     2票（過半数 = クォーラム！）
  → Aは自主退任
  → B、Cがサービスを継続
  → スプリットブレイン防止！

クォーラム公式: 過半数 = (N/2) + 1
  3ノード: 2票必要（1ノード障害許容）
  5ノード: 3票必要（2ノード障害許容）
  7ノード: 4票必要（3ノード障害許容）

# etcd 3ノードクラスター（Raft合意アルゴリズム）
# 1ノードダウン: クォーラム(2/3)維持 → サービス継続
# 2ノードダウン: クォーラム喪失 → 読み取りのみ可能

# kubeadmデフォルト設定
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
      initial-cluster: >-
        etcd-0=https://10.0.0.1:2380,
        etcd-1=https://10.0.0.2:2380,
        etcd-2=https://10.0.0.3:2380

# Raft合意アルゴリズム（疑似コード）
class RaftNode:
    def __init__(self, node_id, peers):
        self.state = "follower"  # follower → candidate → leader
        self.term = 0
        self.voted_for = None
        self.log = []

    def request_vote(self):
        """リーダー選出 — 過半数の投票が必要"""
        self.state = "candidate"
        self.term += 1
        votes = 1  # 自分自身

        for peer in self.peers:
            if peer.grant_vote(self.term, self.log):
                votes += 1

        if votes > len(self.peers) // 2:  # クォーラム！
            self.state = "leader"
            return True
        return False

    def replicate(self, entry):
        """データ複製 — 過半数確認後にコミット"""
        self.log.append(entry)
        acks = 1

        for peer in self.peers:
            if peer.append_entry(entry):
                acks += 1

        if acks > len(self.peers) // 2:  # クォーラム！
            self.commit(entry)  # 過半数確認 → 安全にコミット

[ユーザー]
   │
   ▼
[DNS] ← Route 53ヘルスチェック（マルチリージョン）
   │
   ▼
[CDN] ← CloudFront（グローバルエッジ）
   │
   ▼
[L4 LB] ← NLB x2（Active-Active、AZ分散）
   │
   ▼
[L7 LB] ← ALB x2（Active-Active）
   │
   ▼
[Webサーバー] ← Deployment replicas: 3+（Active-Active）
   │
   ▼
[アプリサーバー] ← Deployment replicas: 3+（Active-Active）
   │
   ├──▶ [DB Primary] ──同期レプリケーション──▶ [DB Standby]（Active-Standby）
   │    └── 非同期レプリケーション ──▶ [DB Read Replica x2]
   │
   ├──▶ [Redis Primary] ── [Redis Replica x2]（Sentinel）
   │
   └──▶ [MQ] ← RabbitMQ 3ノード（クォーラムキュー）

[同期レプリケーション]（Strong Consistency）
  Primary ──COMMIT──▶ Standby
  「両方に書き込むまで待つ」
  メリット: データ損失ゼロ
  デメリット: 遅い（ネットワークRTT追加）

[非同期レプリケーション]（Eventual Consistency）
  Primary ──COMMIT──▶（後で）Standby
  「まずPrimaryだけに書いて応答」
  メリット: 速い
  デメリット: 障害時に最新データ損失の可能性（RPOが0より大きい）

[半同期レプリケーション]（Semi-Sync）
  Primary ──COMMIT──▶ Standby（1つだけ確認）
  MySQLデフォルト + 金融機関で好まれる

-- PostgreSQL Streaming Replication設定
-- Primary (postgresql.conf)
-- wal_level = replica
-- max_wal_senders = 3
-- synchronous_standby_names = 'standby1'

-- Standby確認
SELECT client_addr, state, sync_state
FROM pg_stat_replication;
-- client_addr | state     | sync_state
-- 10.0.0.2   | streaming | sync
-- 10.0.0.3   | streaming | async

RPO (Recovery Point Objective):
  「どれだけのデータを失っても許容できるか？」
  同期レプリケーション: RPO = 0（データ無損失）
  非同期レプリケーション: RPO = 数秒〜数分

RTO (Recovery Time Objective):
  「どれだけ早く復旧しなければならないか？」
  Active-Active: RTO ≈ 0
  Active-Standby: RTO = 数秒〜数分
  バックアップ復元: RTO = 数時間

MTBF (Mean Time Between Failures):
  障害間の平均時間（長いほど良い）

MTTR (Mean Time To Repair):
  復旧までの平均時間（短いほど良い）

可用性 = MTBF / (MTBF + MTTR)

可用性     │ 構成                │ 相対コスト
───────────┼─────────────────────┼──────────
99%        │ 単一サーバー        │ 1x
99.9%      │ 二重化（1リージョン）│ 2〜3x
99.99%     │ 三重化 + 自動復旧    │ 5〜10x
99.999%    │ マルチリージョンActive│ 10〜50x
99.9999%   │ マルチリージョン + DR│ 50〜100x