第4章：可用性とスケーラビリティ

大規模なサービスでは、1台のデータベースサーバー（DB）ですべてを賄うのはリスクが高く、限界もあります。そこで、複数のDBを連携させる技術が必要になります。

4-1. レプリケーション（複製）

レプリケーションとは、メインのDB（プライマリ/マスタ）のデータを、別のDB（レプリカ/スレーブ）にリアルタイムでコピーする仕組みです。

• 目的:

  • 参照負荷の分散: 重い検索クエリをレプリカ側に投げることで、メイン側の負荷を下げる。

  • バックアップ: メインが故障した際、レプリカを昇格させてサービスを継続する。

• 同期方式:

  • 同期レプリケーション: メインへの書き込み時、レプリカへの反映完了を待つ。データの一致は完璧だが、書き込み速度は低下する。

  • 非同期レプリケーション: レプリカへの反映を待たずに終了する。高速だが、障害時に一瞬のデータ差が生じる可能性がある。

4-2. 負荷分散とスケーラビリティ

アクセスが増え続けた際、どう対応するかという戦略です。

• 垂直スケーリング（スケールアップ）: サーバー自体のCPUやメモリを増強する。限界があり、作業時に停止が必要な場合が多い。

• 水平スケーリング（スケールアウト）: 台数を増やす。

  • リードレプリカ: 読み取り専用の台数を増やす（一般的）。

  • シャーディング（水平分割）: データを「ユーザーIDが奇数はAサーバー、偶数はBサーバー」のように物理的に分割して保持する。非常に難易度が高いが、書き込み負荷も分散できる。

4-3. 冗長化とフェイルオーバー

「止まらないシステム」を作るための仕組みです。

• フェイルオーバー: メインのDBが故障した際、監視システムが異常を検知し、自動的に予備のDBへ切り替える仕組み。

• マルチAZ（可用性ゾーン）配置: クラウド環境などで、物理的に離れたデータセンターにDBを分散配置し、地震や火災などの広域災害に備える構成。

4-4. メンテナンスと最適化

パフォーマンスを維持するために欠かせない内部処理です。

• VACUUM（掃除）:

  • PostgreSQLなどのMVCC（多版型同時実行制御）を採用しているDBでは、更新・削除した後の「古いデータ（ゴミ）」が残り続けます。これを整理して領域を再利用可能にするのがVACUUMです。

• 再インデックス（REINDEX）:

  • 長期間運用して断片化（スカスカの状態）になったインデックスを、作り直して効率を戻します。

第4章のまとめ

• レプリケーションでデータのコピーを持ち、参照負荷を逃がす。

• スケールアウトは台数を増やし、シャーディングはデータを分割して負荷を捌く。

• 故障時に自動で切り替えるフェイルオーバーが可用性の要。

• VACUUMや統計情報の更新など、DB内部の「掃除」が長期的な安定稼働を支える。