第1章：分散データベースとモダンアーキテクチャ

1-1. CAP定理とBASE特性

分散システムを設計する上で避けて通れないのがCAP定理です。

CAP定理

以下の3つの要素のうち、同時に満たせるのは最大で2つまでであるという定理です。

1. Consistency（一貫性）: どのノードからデータを読み取っても、常に最新の同じデータが得られる。

2. Availability（可用性）: 一部のノードがダウンしても、システム全体として応答を返し続ける。

3. Partition Tolerance（分断耐性）: ネットワークが分断されても、システムが動作し続ける。

現代の分散DBでは、ネットワーク障害を前提とするため「P（分断耐性）」は必須となり、「CP（一貫性重視）」か「AP（可用性重視）」かの選択を迫られます。

BASE特性

ACID特性（厳格な一貫性）の対照として、分散システムで採用されるのがBASE特性です。

• Basically Available: 基本的に動いている。

• Soft-state: 状態が厳密に固定されず、時間とともに変わる可能性がある。

• Eventual Consistency（結果整合性）: 一時的に不整合が起きても、最終的には正しい状態に収束する。

1-2. クラウドネイティブDBの特性

従来のDBを単にクラウドに乗せる（Lift & Shift）のではなく、クラウドの特性を最大限に活かした「クラウドネイティブDB」が主流となっています。

• ストレージとコンピュートの分離:

  • Amazon Auroraなどのアーキテクチャ。計算を行うエンジン（コンピュート）と、データを保持するストレージ層を分離します。

  • メリット: ストレージの自動拡張や、コンピュートノードの素早い追加・切り替えが可能。

• 水平スケーラビリティとグローバル分散:

  • Google Cloud Spannerなどのサービス。原子時計やGPSを利用した時刻同期により、世界規模で分散しながらも高い一貫性（外部一貫性）を実現します。

1-3. データベースのマイクロサービス化

システム全体を小さなサービスの集合体にする「マイクロサービス」環境でのデータ管理手法です。

Database per Service パターン

各サービスが自分専用のデータベースを持つ設計です。

• メリット: サービス間の疎結合（独立性）が保たれる。

• デメリット: 複数のサービスにまたがる「分散トランザクション」が困難になる。

Sagaパターン

分散トランザクションを解決するためのデザインパターンです。

1. 各サービスでローカルなトランザクションを順次実行する。

2. 途中で失敗した場合、それまでに行った処理を打ち消すための「補償トランザクション」を実行して、全体として整合性を保つ。

第1章のまとめ

• CAP定理を理解し、システムの要件が「厳密な一致」なのか「止まらないこと」なのかを判断する。

• 結果整合性を許容することで、分散システムのパフォーマンスを最大化できる。

• ストレージ分離型DBの活用により、運用負荷を下げつつ高い拡張性を確保する。

• マイクロサービスでは、Sagaパターン等を用いて分散環境での一貫性を制御する。