分散データベース入門シャーディング・レプリケーション・2相コミットを図解で理解する

小さなネットショップなら、商品・在庫・注文・会員を1台のデータベースで管理できます。ところが利用者が増えると、読み書きが集中し、バックアップや障害復旧にも負担がかかります。1台の故障でサービス全体が止まる構成も不安です。

そこでデータを複数のサーバーで扱う「分散データベース」を検討します。分散とは単にサーバーを増やすことではなく、どのデータをどこに置くか、更新をどう伝えるか、故障時に何を保証するかを決める設計です。

これらは排他的な技術ではありません。各シャードをさらに複製する構成も一般的です。一方で、複製先が増えたからといって複数シャードの更新が自動的に原子的になるわけではありません。

シャーディング（Sharding）は、例えば顧客IDのハッシュ値などに応じて、データを異なるサーバーへ振り分ける方法です。注文100万件を3台で分担すれば、1台ですべてを保持する必要がなくなります。図ではわかりやすく注文IDの範囲で区切っています。

分割キーの選び方は重要です。特定の人気商品や大型顧客だけにアクセスが集中すると、そのシャードだけが忙しくなる「ホットスポット」が発生します。複数シャードにまたがる集計や結合も複雑です。

レプリケーション（Replication）は、プライマリの更新内容をレプリカへ伝え、同じデータを複数ノードに保持する仕組みです。読み取りをレプリカへ分散したり、プライマリ障害時の切替先を用意したりできます。

代表的な構成では、書き込みをプライマリが受け、WAL（Write-Ahead Log）などの変更記録をレプリカへ転送して反映します。実装により物理・論理レプリケーションなどがあります。重要なのは複製が「いつ完了した」と扱われるかです。

非同期レプリケーションでは、プライマリがローカルの確定条件を満たすと、レプリカの反映完了を待たずに利用者へ成功を返せます。そのため書き込み応答を比較的速くしやすい一方、プライマリとレプリカの間に短い差が生まれます。

転送前にレプリカを読むと、まだ10個と表示されることがあります。これがレプリカ遅延（Replication Lag）です。さらに、プライマリが停止し、まだ変更を受け取っていないレプリカを昇格させると、利用者には成功と返した直近の更新が失われる可能性があります。

同期レプリケーションは、設定されたレプリカから所定の確認応答が返るまで書き込み完了の応答を待つ方式です。たとえば「レプリカがWALを永続化した」ことを確定条件にすれば、プライマリ単独障害時のデータ損失リスクを下げられます。ただし通信往復やレプリカの状態が書き込み待ち時間に影響します。

なお「同期」といっても、転送済み・ディスクへ永続化済み・問い合わせから参照可能、のどこまで待つかで保証が変わります。PostgreSQLの remote_write、on、remote_apply などがその例です。

プライマリが故障し、レプリカを新しいプライマリとして昇格させる処理をフェイルオーバーといいます。ただし切り替えるだけでは安全とは限りません。旧プライマリが復帰して両方が書き込みを受ける「スプリットブレイン」を避けるため、リーダー選出やフェンシング（旧リーダーの書き込み禁止）などが必要です。

「同じデータを複数台に持つ」だけで、どのサーバーから読んでも常に同じ値になるわけではありません。非同期複製では時間の経過とともに値が収束する結果整合性（Eventual Consistency）が典型的な選択肢です。ただしアプリケーションは、更新直後に自分の更新が見えることを要求する場合があります。

一方で、異なるノードを含む取引の原子性、読み取りの新鮮さ、サービスが応答できることは、それぞれ別の保証です。ネットワーク分断時は整合性と可用性の両立に制約が生じますが、CAP定理だけで具体的なDBの挙動を丸ごと説明することはできません。どの操作に何を保証するのかを確認する必要があります。

ECサイトの注文を考えます。注文DBに「注文済み」と記録し、別の在庫DBから1個減らす必要があるとします。2台をそれぞれ独立にCOMMITすると、最初のDBだけ成功して次で障害が起きるかもしれません。

単一のリレーショナルDB内であれば通常は1つのローカルトランザクションでまとめられます。しかし独立したDBやシャードをまたいで、全体でAll or Nothing（全部成功または全部中止）を必要とするなら、分散トランザクションの調停が課題になります。

2相コミット（Two-Phase Commit、2PC）は、調停者（Coordinator）が各参加者（Participant）へ確認を取り、全参加者のトランザクションをまとめてCOMMITまたはABORTするための手順です。

「YES」はCOMMIT済みではありません。「最終決定が来ればCOMMITできる」という準備完了の約束です。全員YESでも決定通知を待つ必要があります。

注文DBと在庫DBがYESを返した直後、調停者が停止したとします。どちらのDBも、全体でCOMMITするのかABORTするのかをまだ知らない可能性があります。自分で勝手にCOMMITやROLLBACKを選ぶと、別の参加者の結果と食い違う危険があります。

このためPrepared状態で待ち続けることがあり、ロックやリソースが保持されて後続処理を妨げます。これを2PCのブロッキング問題と呼びます。調停者の決定ログや参加者の状態を確認し、定められた復旧手順に従う必要があります。

シャーディングは配置、レプリケーションは複製、2PCは更新の原子性を扱います。3つを同時に利用することもあれば、どれかだけを利用することもあります。

したがって「レプリケーションが非同期で、2PCが同期」と単純に二分するのは正確ではありません。非同期／同期という区分はレプリケーション自身にもあり、2PCの「2相」はPrepareとCommit/Abortという決定手順を指します。

2PCを採用すれば、すべての設計が楽になるわけではありません。参加者全員が準備・確定手順に対応し、障害時に未解決のPreparedトランザクションを復旧できることが必要です。外部決済やメール配信など、すでに起きた現実の操作は厳密にROLLBACKできないこともあります。

例えば注文確定後にメールを送る処理まで2PCに含めるのは通常難しいため、Outboxと再送・重複排除の方が適切なことがあります。方式は厳密な同時確定が必要か、後から収束・補償できるかで選びます。

同じ「注文を確定する」という場面でも、複製を待つか・故障が起こるか・複数DBがYESを返すかで結果が変わります。まずレプリケーションの遅延と切替、次に2PCの投票とブロッキングを動かしてみてください。実DBへは接続しない概念シミュレーターです。

DBの製品ごとに、複製の確認条件、リーダー選出、分散トランザクションの対応範囲は異なります。アーキテクチャ図だけでは保証は分からないため、公式仕様と障害試験で確かめます。

分散データベースの理解は、「データをどこに置くか」「コピーをいつそろえるか」「異なる更新をどう確定するか」の3つに分けると整理できます。シャーディングは分割、レプリケーションは複製、2相コミットは分散した更新の原子性を調停します。

非同期レプリケーションは応答を速くしやすい一方でレプリカ遅延や切替時の損失が課題です。同期レプリケーションは複製先の確認を待ちますが、その分遅延や停止の影響を受けます。2PCは全参加者の確定をそろえますが、Prepared後の障害で待機が長引く可能性があります。