変更要約: 初版
6.1分散データベースとレプリケーション
複数のサイトにデータを分割配置する水平分割・垂直分割、同じデータを複製するレプリケーション(同期レプリケーション・非同期レプリケーション)、分散透過性を実現する6つの透過性、スケールアウトのためのシャーディング、そして分散システムの限界を示すCAP定理・BASE・結果整合性を学びます。
サービスの成長に伴いデータ量・アクセス量が単一サーバの限界を超えると、データベースを複数のサイトやノードに分散させる設計判断が避けられなくなります。しかし分散は無償ではありません——一貫性・可用性・応答性能のどれを優先し、どれを犠牲にするかというトレードオフが常に付きまといます。データベース設計者・データ基盤担当には、業務要件(金融取引のように一貫性が最優先か、SNSのフィードのように可用性・応答性が優先か)に応じて、分割方式・レプリケーション方式・整合性モデルを的確に選定する能力が求められます。この節では分散DBの仕組みを踏まえた上で、その設計判断の型を身につけます。
6.1.1データの分割:水平分割と垂直分割
- 水平分割(行分割)=1つの表を行単位で複数のサイト・ノードに分割配置する方式。例えば顧客表を「地域」や「顧客ID範囲」で分けて各拠点・ノードに配置する。各断片の表構造(列)は同一のまま行が分かれるため、負荷分散やスケールアウトに向く。
- 垂直分割(列分割)=1つの表を列単位で分割する方式。例えば頻繁にアクセスされる列(氏名・ステータス等)と、めったにアクセスされない列(詳細な履歴・大きなテキスト等)を別の表・別のストレージに分けることで、よく使う列だけを高速なストレージに載せるなどの最適化ができる。分割後も各断片は元の行の主キーで対応付けられる。
- 分割の判断基準は「アクセスパターンの偏り」にある。特定地域・特定顧客層へのアクセスが集中するなら水平分割でその範囲だけを高速化でき、特定列への集中アクセスがあるなら垂直分割でその列だけを最適化できる。両方を組み合わせる混合分割も実務では用いられる。
6.1.2分散透過性(6つの透過性)
- 分散データベースの理想は、利用者やアプリケーションがデータがどこに・どのように分散しているかを意識せずに単一のデータベースであるかのように扱えることで、これを透過性(transparency)と呼ぶ。代表的な6種:位置の透過性(データがどのサイトにあるか意識不要)、断片化(分割)の透過性(どう分割されているか意識不要)、複製の透過性(複製がいくつあるか意識不要)、障害の透過性(一部のサイト障害を意識せず処理継続)、並行性の透過性(同時実行制御が背後で行われる)、性能の透過性(分散していても性能が保たれるよう最適化される)。
- 透過性は理想であって完全な実現は難しい。特に障害の透過性とCAP定理はトレードオフの関係にあり、「一部サイトが止まっても常に応答する(可用性)」と「常に最新の一貫したデータを返す(一貫性)」を分断(ネットワーク分断)時に両立させることはできない、という限界を次に学ぶ。
6.1.3レプリケーション:同期と非同期
- レプリケーション(複製)=同じデータを複数のノードに複製して保持する仕組み。可用性向上(1台が故障しても他の複製で継続)と読み取り性能向上(複製先で読み取りを分散)が主目的。多くはマスタ/スレーブ(プライマリ/レプリカ)構成を取り、書き込みはマスタに集約し、スレーブへ変更を伝播する。
- 同期レプリケーション=マスタへの書き込みが全て(または規定数)のレプリカへの反映完了を待ってからコミット完了とする方式。複製間のデータ不整合が生じない(強い一貫性)が、レプリカの反映を待つ分だけ書き込みの応答性能が低下し、レプリカ側の障害・遅延が書き込み全体の性能に直結する。
- 非同期レプリケーション=マスタへの書き込みは即座にコミット完了とし、レプリカへの反映はその後(バックグラウンド)で行う方式。書き込みの応答性能は高いが、マスタ障害時に未反映の更新が失われるリスク(データロス)があり、レプリカを読み取るとマスタより古いデータ(一時的な不整合)を返す可能性がある。
「水平分割=行単位・垂直分割=列単位」「同期レプリケーション=全レプリカ反映待ち・強一貫性・低性能」「非同期レプリケーション=即時コミット・高性能・データロスリスクと一時的不整合」の対比が最頻出です。6つの透過性(位置・断片化・複製・障害・並行性・性能)の名称と意味も押さえましょう。
6.1.4シャーディングとCAP定理・BASE
- シャーディング=水平分割の一種で、データをシャードキー(分割キー)に基づいて複数の独立したノード(シャード)に分散配置し、各シャードが独立して読み書きを処理することで書き込みも含めた水平スケールアウトを実現する方式。単純なレプリケーションが読み取りのスケールに強い一方、シャーディングは書き込みも含めた全体のスケールに強い。シャードキーの選び方次第で特定シャードへのアクセス偏り(ホットスポット)が生じうる点に注意が必要。
- CAP定理=分散システムは一貫性(Consistency)・可用性(Availability)・分断耐性(Partition tolerance)の3つを同時に完全には満たせないという定理。ネットワーク分断は現実に起こりうる前提のため分断耐性は事実上必須とされ、実際の設計判断は一貫性(CP:分断時は一貫性を優先し一部要求を拒否/待たせる)か可用性(AP:分断時も応答を返すが古い/不整合なデータを返す可能性を許容)かの選択になる。
- BASE=ACIDと対比される、可用性重視の分散システムの設計思想。Basically Available(基本的に可用)・Soft state(ソフトステート=状態は時間とともに変化しうる)・Eventually consistent(結果整合性)の頭字語。結果整合性=更新直後は一時的に不整合な状態がありうるが、新たな更新が入らなければ最終的に全ノードが同じ値に収束するという緩い整合性モデルで、AP寄りのNoSQL等で採用される。
あるECサイトのデータ基盤担当者が、2つの異なる要件に直面しているとします。1つ目は決済・在庫の確定処理——顧客が同じ在庫を二重に購入してしまう、あるいは決済が二重に確定してしまうことは事業上絶対に避けたい強い一貫性要件です。この場合、マスタへの書き込みをレプリカへの反映完了を待ってからコミットする同期レプリケーションを選び、CAP定理の観点でも一貫性を優先するCP型の構成(ネットワーク分断時は一部の書き込みを拒否してでも不整合を防ぐ)を採用します。応答性能の低下は許容し、決済の正しさを最優先します。2つ目は商品閲覧数・「いいね」数のカウンタ——多少の遅延や一時的な不整合があっても、常にレスポンスが返ることの方が事業上重要な要件です。この場合は非同期レプリケーションを選び、CAP定理の観点では可用性を優先するAP型の構成を採用し、結果整合性(BASE)を受け入れます。書き込みは即座にコミットされ高いスループットを得られますが、読み取り先のレプリカによっては数秒古いカウンタ値を返すことがあり、これは事業要件上許容範囲と判断します。さらに、注文量の増加でマスタ1台の書き込み処理が限界に近づいてきた場合は、単純なレプリケーション(読み取りスケールのみ)では書き込みのボトルネックが解消しないため、顧客IDや注文日をシャードキーとするシャーディングへの移行を検討し、シャードキーの選定では特定の大口顧客や特定日への偏り(ホットスポット)が生じないよう注意します。このように「一貫性が生命線の処理か、可用性・応答性が生命線の処理か」を業務要件ごとに見極め、レプリケーション方式・CAP定理上の立ち位置・分割/シャーディング方式を使い分けるのが実務の核心です。
| 設計方針 | CAP上の優先 | レプリケーション | 代表的な用途 |
|---|---|---|---|
| CP型(一貫性優先) | 一貫性+分断耐性 | 同期レプリケーション | 決済・在庫確定・銀行残高 |
| AP型(可用性優先) | 可用性+分断耐性 | 非同期レプリケーション | 閲覧数・SNSフィード・キャッシュ |
ひっかけ: 「CAP定理は一貫性・可用性・分断耐性のうち2つを自由に選んで両立できる」という理解は不正確です——分断耐性は現実のネットワークでは事実上前提であり、実務の選択は「分断発生時に一貫性を優先するか、可用性を優先するか」の二択に近い形になります。また「非同期レプリケーションは常にデータを失う」も誤り=マスタ障害と未反映更新のタイミングが重なった場合にのみロスのリスクが生じるのであり、通常運用では反映が完了します。
6.1.5この節のまとめ
- 水平分割=行単位、垂直分割=列単位。分割方式はアクセスパターンの偏りで選ぶ
- 同期レプリケーション=強一貫性・低性能、非同期レプリケーション=高性能・データロスリスクと一時的不整合
- CAP定理では分断耐性は前提とし、一貫性優先(CP)か可用性優先(AP・BASE/結果整合性)かを業務要件で選ぶ。書き込みスケールにはシャーディング
進捗の記録にはログインが必要です。
理解度チェック
(軽い確認用)Q1. ECサイトの決済・在庫確定処理で、同じ在庫の二重販売や決済の二重確定を絶対に避けたい。レプリケーション方式とCAP定理上の設計方針として最も適切な組み合わせはどれか。
Q2. SNSの「いいね」カウンタで、多少の表示遅延や一時的な不整合が生じても常にレスポンスを返すことを優先したい。最も適した設計はどれか。
Q3. 注文量の増加でマスタ1台への書き込みが処理能力の限界に近づいている。読み取り専用レプリカを増やしても書き込みのボトルネックは解消しない。最も適した対策はどれか。

