データレプリケーションとは？仕組み・種類・ユースケースを徹底解説

データレプリケーションとは？

データレプリケーションとは、データを複製し、すべてのデータリソース間で情報がリアルタイムに同一の状態を保つようにする手法です。データベースレプリケーションは、大切な情報がすり抜けて失われてしまうのを防ぐセーフティネットのようなものと考えると分かりやすいでしょう。データは停滞することなく常に変化し続けるため、レプリケーションは継続的なプロセスとなります。その結果、プライマリデータベースのデータが、たとえ地球の裏側にあるレプリカであっても、確実にミラーリングされることを保証できます。

現代では「瞬時」ですら速さが足りません。レイテンシをサブミリ秒単位まで削減することが、あらゆる業界共通の目標となっています。ウェブサイトの更新ボタンを押して、情報が表示されるまで数秒待った経験は誰にでもあるはずです。このわずかな数秒が、ユーザーの生産性を低下させます。目指すべきはニアリアルタイムの実現であり、あらゆるユースケースにおいて「タイムラグゼロ」が新たな理想形となっています。

データレプリケーションの仕組み

データレプリケーションは、あるホストから別のホストへデータをコピーするプロセスです。例えば、オンプレミス環境同士の間、あるいはオンプレミスからクラウド環境へのコピーなどが挙げられます。目的は、ユーザーがどこからデータにアクセスしても、全員がリアルタイムで一貫したデータを利用できるようにすることです。ゲーム業界に代表されるデータ駆動型ビジネスモデル（DDBM）は、リアルタイムデータから得られる分析結果に大きく依存しており、リアルタイムアクセシビリティの重要性が際立っています。

データレプリケーションのメリット

信頼性の向上と災害復旧（DR）

緊急時にプライマリインスタンスが侵害された場合、即座に切り替えられるレプリカによってミッションクリティカルなアプリケーションを保護できることが極めて重要です。災害復旧のためのレプリケーションは、非常用発電機とよく似た役割を果たします。重要なヒューズが切れたり停電したりしても、バックアップ用の発電機が即座に代替として稼働し、照明をつけ続けられるのと同じことです。

レプリカインスタンスはプライマリインスタンスの完全なコピーであるため、プライマリに何が起ころうとも、パフォーマンスが低下しないことを保証できます。仮にプライマリとレプリカ間の接続が切断されても、プライマリが部分再同期を実行し、接続断の間にレプリカへ配信されなかったコマンドを収集するため、パフォーマンスは維持されます。部分再同期が不可能な場合は、スナップショットを使用した完全再同期が自動的に開始されます。

アプリケーションパフォーマンスの向上

データを複数のインスタンスに分散させることで、読み取りパフォーマンスを最適化できます。また、データに複数の場所からアクセス可能になることで、レイテンシの問題も最小限に抑えられます。さらに、レプリカにほとんどの読み取り処理を担当させることで、プライマリは書き込みという重い処理に専念する余裕が生まれます。

ITチームの効率化

手作業によるデータ複製にかかるIT部門の労力を大幅に削減できます。

完全レプリケーションと部分レプリケーションの違い

完全データベースレプリケーション（Full Replication）は、プライマリデータベース全体を、利用可能なすべてのレプリカインスタンスに複製する方式です。既存データ、新規データ、更新データのすべてを全宛先へミラーリングする包括的なアプローチですが、その反面、大量のデータをコピーするため considerable な処理能力が必要となり、ネットワーク負荷も大きくなるという課題があります。

一方、部分レプリケーション（Partial Replication）は、データのごく一部、通常は最近更新されたデータのみをミラーリングします。特定の場所におけるデータの重要性に応じて、必要なデータだけを絞り込んで複製するのが特徴です。

例えば、ロンドンに本社を置く大手金融企業が、ボストンやクアラルンプールなど世界中に支店を持っているケースを考えてみましょう。部分レプリケーションを利用すれば、ロンドンのアナリストは英国関連のデータだけを自サイトに保有し、必要なデータのみを一貫してレプリケートできます。米国やマレーシアの各支店も同様に運用でき、特定のシステムに負荷が集中することを避けられます。これにより、パフォーマンスが向上し、ネットワークトラフィックも最小化されます。

データレプリケーションの種類と具体例

トランザクションレプリケーション

この方式では、プライマリデータベースでの変更が、変更された順序どおりにレプリカインスタンスへリアルタイムで反映され、高い整合性が実現されます。レプリケーションはまずプライマリデータの「スナップショット」を取得し、そのスナップショットを他の場所へ複製すべき内容の設計図として使用します。トランザクションレプリケーションを使えば、変更を追跡し、必要に応じて配信できます。

ただし、このプロセスは差分（増分）ベースで行われるため、バックアップ用途としては最適とは言えません。トランザクションレプリケーションが適しているのは、すべてのデータ拠点間でリアルタイムの一貫性が必要な場合、変更の全体的な影響だけでなく細かな変更一つひとつを記録する必要がある場合、そして特定の場所からデータが頻繁に更新される場合などです。

スナップショットレプリケーション

名前のとおり、スナップショットレプリケーションは特定の時点におけるプライマリのデータの状態を「スナップショット」として捉え、それをレプリカへ送ります。写真のように、ある時点でのデータの姿を捉えますが、その後の更新までは反映されません。したがって、バックアップ目的には使用しないでください。

ストレージ障害が発生した場合、スナップショットレプリケーションには最新情報への経路がありません。情報の一貫性を保つには、まずスナップショットを取得した上で、プライマリに対するすべての変更が各レプリカへ確実に伝わるように構成する必要があります。

その一方で、誤って削除したデータの復旧には非常に有効です。Google ドキュメントの「バージョン履歴」をイメージしてください。4時間前の状態でプレゼンテーションを作業できたらいいのにと思ったことはありませんか？1時間ごとにスナップショットが保存されていれば、4時間前のバージョンに戻って、当時のデータの状態を確認・復元できます。

マージレプリケーション

この方式は通常、データのスナップショットから始まり、そのデータをレプリカへ配布した後、システム全体でデータの同期を維持します。マージレプリケーションの最大の特徴は、各ノードが独立してデータを変更でき、そのすべての更新が統合された一つの全体へマージされる点です。

また、各ノードで行われた変更もすべて記録されます。先ほどのGoogle ドキュメントの例で言えば、同僚とドキュメントを共有してコメントや編集を受けたとき、誰がいつ何を変更したかが表示されますよね。マージレプリケーションはこれとよく似た仕組みで動作します。

キーベースレプリケーション

キーベース増分データレプリケーションとも呼ばれるこの方式は、レプリケーションキーを活用して、前回の更新以降に変更された特定のデータのみを識別・検出・変更します。対象データを絞り込むことで、必要最低限の負荷でバックアッププロセスを効率化できます。新しいデータを高速に反映できる反面、削除されたデータを複製できないという欠点がある点には注意が必要です。

アクティブ・アクティブ地理分散（Active-Active Geo-Distribution）

アクティブ・アクティブ地理分散はピアツーピアレプリケーションとも呼ばれ、ノード間の継続的なトランザクションデータに依存する点で、トランザクションレプリケーションに似ています。アクティブ・アクティブ構成では、同じネットワーク内のすべてのノードが、対応するすべてのノードとデータベースを同期しながら、常にお互いにデータを送受信します。すべてのノードが書き込み可能であり、世界のどこからでも誰でもデータを変更でき、その変更が他のすべてのノードへ即座に反映されます。これにより、変更が発生した場所がどこであっても、リアルタイムの一貫性が保証されます。

このデータ複製の挙動は、CRDT（Conflict-free Replicated Data Type：競合のないレプリケートされたデータ型）によって定義されます。いずれかのレプリカ（ノード）でネットワーク障害が発生しても、他のレプリカは必要なデータをすべて保持しており、そのノードがオンラインに復帰した時点でレプリケーションを実行できます。世界各地に複数のデータセンターを必要とするグローバル企業にとって、堅牢なソリューションと言えるでしょう。

同期／非同期レプリケーション

同期レプリケーションでは、その名のとおり、データがプライマリとレプリカに同時に書き込まれます。一方、非同期レプリケーションでは、プライマリへの書き込みが完了した後に初めてデータがレプリカへコピーされます。非同期レプリケーションはリアルタイム処理も可能ですが、通常はそうではありません。書き込み操作がバッチ形式で実行される傾向があるため、特にフェイルオーバー発生時にデータが失われることがあります。それでも、リアルタイム性がミッションクリティカルな要素ではない場合、長距離間でのデータレプリケーションには非同期が適した選択肢となります。

データレプリケーション導入における一般的な課題

複数のインスタンスにわたってデータを維持するには、安定したリソースセットが必要です。コストの面では、複数のレプリカインスタンスを持つプライマリの運用は、多くの場合かなり高額になります。これらの運用を維持し、システム障害を未然に防ぐには、専門知識を持つ専任チームが不可欠です。また、アーキテクチャによっては、新しいプロセスを導入した際にネットワーク帯域幅が過負荷になり、レイテンシや読み取り・書き込み性能に悪影響が出る可能性もあります。

Redisなら、データレプリケーションを迅速、低コスト、かつ簡単に実装できます。ぜひRedis Enterpriseの導入をご検討ください。