レプリケーション（データ複製）

📌

レプリケーションとは

レプリケーションとは、同じデータを複数のサーバへ複製（コピー）して持たせ、可用性や性能を高める仕組みのことです。書込みを受け付けるマスタ（＝親サーバ）と、その複製を持つスレーブ（＝子サーバ）に分けるのが基本の形です。

身近な例で考えると、大事な書類を1か所だけでなく、コピーを別の場所にも保管しておくのに似ています。1つが火事で焼けても別のコピーが残るので安心ですし、複数の場所から同時に閲覧できるので便利です。データでも同じ発想で、コピーを分散して持たせます。

上のツールで▶ボタンを押すと、マスタへの書込みがスレーブへ複製され、全ノードの値がそろっていく流れを順に確認できます。シナリオを切り替えると同期型と非同期型の違いも見られます。

⚖️

同期/非同期の違い

複製を「いつ」行うかで2種類に分かれます。違いは「スレーブの反映を待つかどうか」です。

・同期レプリケーション：マスタ更新と同時にスレーブへ反映し、全部が書き込み終わるのを待ってから「完了」を返す。常に全ノードが一致するが、待つぶん書込みは遅くなる
・非同期レプリケーション：マスタを更新したらすぐ「完了」を返し、スレーブへは後から伝播する。書込みは速いが、伝わるまでの間はスレーブが古い値（＝レプリケーション遅延）になる

言いかえると、同期型は「正確さ優先」、非同期型は「速さ優先」です。銀行の残高のように必ず最新であってほしいデータは同期型、SNSの「いいね数」のように多少遅れても困らないデータは非同期型、というように使い分けます。上のツールでシナリオを切り替え、待つ／待たないの動きを見比べてみてください。

🔗

レプリケーションの構成パターン

レプリケーションは「どのサーバがどのサーバへ複製するか」という構成パターンに主に 3 種類あります。それぞれ得意・不得意が違うので、用途に合わせて選びます。

① マスタ-スレーブ型（最も基本）：書込みは マスタ 1 台 に集約し、その内容を複数のスレーブへ一方向に流す形です。読取りは全ノードに分散できるので、読取りが多いサービス（参照系の Web アプリ等）に向きます。一方で書込みは 1 台に集中するので、書込みが極端に多いと限界が来ます。

② マルチマスタ型（双方向）：複数のノードがすべてマスタとして動き、お互いに更新内容を交換します。書込みを分散できるので、大量書込みのあるサービスや、地理的に離れた拠点で別々に書込みたい場合に使われます。ただし同じデータを同時に書き換えた場合の「競合（コンフリクト）」を解決する仕組みが必要で、設計の難易度が上がります。

③ カスケード型（数珠つなぎ）：マスタ → スレーブ 1 → スレーブ 2 → スレーブ 3 ... と、バケツリレーのように複製を渡していく形です。マスタが複数台へ直接送る負担を減らせるので、スレーブ台数が多い大規模システムで使われます。末端のスレーブまで伝播するのに時間がかかる点には注意が必要です。

🔄

マスタ障害時のフェイルオーバー

マスタ-スレーブ型の弱点は、マスタが 1 台しかないことです。マスタがダウンすると書込みが止まりサービス全体が機能不全になります。これを救うのがフェイルオーバー＝障害時にスレーブを新しいマスタに「昇格」させて運用を続ける仕組みです。

フェイルオーバーの基本手順
・① 障害検知：監視ツールがマスタの異常を検知（応答なし、ハートビート途絶など）
・② スレーブ昇格：もっとも最新の状態に近いスレーブを 1 台選び、新しいマスタとして昇格させる
・③ 経路切替：アプリの接続先を旧マスタから新マスタへ切り替える（DNS や仮想 IP の付け替えなど）
・④ 残りのスレーブ再構成：他のスレーブを新マスタへ向け直し、複製を再開

自動と手動の2方式。フェイルオーバーには監視ソフトが判断して全部自動で行う自動フェイルオーバーと、管理者が手作業で切替える手動フェイルオーバーがあります。自動はダウンタイム（停止時間）を短くできますが、誤検知でマスタが 2 つできる「スプリットブレイン」状態に陥らないよう、慎重な設計が必要です。

非同期型では「データ消失」のリスクがある点も覚えておきましょう。マスタが落ちる直前の書込みがまだスレーブに伝わっていなければ、新マスタにはその更新が反映されません。重要な業務システムでは同期型と組み合わせ、最低 1 台のスレーブには確実に複製してから完了を返す、といった工夫がされます。

⏱️

結果整合性とCAP定理

非同期レプリケーションを使うと、「いまこの瞬間は値がそろっていない」という状態がどうしても発生します。これを結果整合性（Eventual Consistency）と呼びます。

整合性のレベルは大きく 2 段階に分かれます。
・強整合性（Strong Consistency）：どこから読んでも常に最新の値が返る。同期レプリケーションで実現
・結果整合性（Eventual Consistency）：いまは一致していなくても、放っておけばいずれ全ノードが同じ値になる。非同期レプリケーションで実現

CAP 定理：分散システムには「整合性（Consistency）」「可用性（Availability）」「分断耐性（Partition tolerance）」の3つを同時に満たすことができない、という有名な理論があります。ネットワーク障害が起きうる以上、現実のシステムでは整合性か可用性のどちらかを犠牲にせざるを得ません。
・整合性優先（CP型）：値が不一致になりそうなら一時的にサービスを止めても正確さを保つ（銀行系）
・可用性優先（AP型）：多少古い値が返っても、止まらないことを優先する（SNSやECサイトの一部機能）

身近な例で考えると、掲示板への投稿が地方の支店で見えるまで少しタイムラグがあるのに似ています。投稿した本人や本店ではすぐ見えますが、回線が遅い支店では数秒〜数分遅れて表示される、というイメージです。重要な業務システムでは強整合性を選び、SNS のいいね数のような軽い情報では結果整合性で十分、と使い分けます。

🆚

クラスタリング・バックアップとの違い

レプリケーションとよく似た仕組みにクラスタリングとバックアップがありますが、目的と動き方が違います。混同しやすいので整理しましょう。

レプリケーションは「同じ内容を複数の場所にも持つ」仕組みで、読取り分散と可用性が主目的。クラスタリングは「複数台を 1 台のように扱う」仕組みで、高い処理能力と可用性が主目的。バックアップは「過去の時点のデータを保存しておく」仕組みで、誤操作や災害からの復旧が目的です。

重要なポイント：レプリケーションはバックアップの代わりにならない。レプリケーションはリアルタイムでデータを複製するので、マスタで誤ってデータを削除するとスレーブにもすぐ削除が伝わります。「DELETE文を間違えた」のような操作ミスに対しては、過去の時点のデータを保管しているバックアップが必要です。実務では「レプリケーション＋定期バックアップ」のセットで運用するのが基本です。

身近な例で言うと、レプリケーションは「自宅と職場の両方に書類のコピーを置く」、クラスタリングは「3 人のチームで仕事を分担して同じ作業をする」、バックアップは「毎週末に書類を貸金庫に預ける」、というイメージで使い分けると分かりやすいです。

🎯

基本情報技術者 練習問題