データレプリケーションとは？ メリットや手法、実装の際気を付けるポイントを解説

「思わぬミスで、業務にクリティカルなデータが消失してしまった…。」こんな事態は絶対に避けたいですよね。突然のデータ消失に備えるために欠かせないソリューションが、データレプリケーションです。

この記事では、データレプリケーションの基本からレプリケーションを行う意味、レプリケーション処理の種類や手法、さらに実装する上で注意するポイントまで詳しく解説します。

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

データレプリケーションとは、データベースやSaaS が保持しているデータを、そのまま別のデータベースやデータウェアハウスにリアルタイムでコピーする処理のことです。複製のことをレプリカというので、レプリカを作る処理、ということでレプリケーションです。

データレプリケーションを行う主要な目的は、データの可用性や利用可能性、またシステムの頑健性を担保することにあります。クリティカルなデータの複製を用意しておくことで、災害・インシデントの際すぐに復旧できます。

通常、バックアップでなくレプリケーションという場合には、マスターデータの変更に応じてリアルタイム（またはニアリアルタイム）でデータを複製することを指します。データベースがどこに位置していようとも、マスターデータの変更を同期先に反映して最新の状態に保つのが、データレプリケーションツールの役割です。主要な地域に複製DB を用意しておくことで、ユーザーは遅延を最小限に抑え、災害時の心配をすることなくデータを活用できます。

データレプリケーションを活用するメリット

データレプリケーションにはさまざまな利点がありますが、主要なものを紹介していきましょう。

データの可用性とアクセシビリティ

データレプリケーションを使えば複数のデータストアにマスターデータをコピーできるので、社内で組織や地域をまたいだデータ活用を実現できます。この点は複数拠点に展開する（グローバルを含む）企業にとって特に重要で、必要なデータを複数拠点にコピーしておけば各拠点から素早くデータにアクセスできます。

サーバーアクセス・ネットワークパフォーマンスの向上

可用性に関連したメリットとして、データレプリケーションを活用することで、ユーザーがサーバーにアクセスする際のパフォーマンスを改善できます。データを各拠点のサーバーに配置しておくことで、サーバーへのアクセスやネットワーク遅延を最小限にして各拠点のユーザーがデータにアクセスできます。

ディザスタリカバリ

データレプリケーションの主要な目的は、ディザスタリカバリ（災害復旧）およびデータ保護でしょう。レプリケーションをセットしておくことで、災害やシステム障害時でも直前のバックアップを確保できます。そのため、システムが停止しても複製データにすぐにアクセスして即座に復旧・再稼働を進められます。

データレプリケーションの実装する前に考慮するポイントは？

データレプリケーション処理の基本は、あるデータストアから別のデータストアにデータをコピーすることです。例えば、同一地域、または別地域間のオンプレミスデータベースで、一方のDB のデータをもう一方のDB にコピーする場合にはデータレプリケーションを活用できるでしょう。また、レプリケーションは必要なときに手動で実行することもできますし、スケジューリングを設定してバルクで行うこともできます。

このように、一言でレプリケーションといっても実装する際には同期するデータの選択方法、同期タイミングの選定、同期対象の選定など考慮すべきポイントが存在します。ここでは各考慮ポイント別に代表的な手法を紹介し、メリットとデメリットをまとめていきます。

レプリケートするデータの範囲

まずは、レプリケートするデータの範囲別の手法から見ていきましょう。レプリケートするデータ量はパフォーマンスやコストに直結するので、重要なポイントです。各レプリケーションで全データを同期するといったシンプルな方法から、最終同期時からの差分のみを更新するといった方法までさまざまな手法が存在します。データ量やデータの重要性などのポイントをもとに選定してください。

フルレプリケーション

フルレプリケーションは、マスターデータソースの持つデータを完全にセカンダリデータベースに複製する手法であり、もっともシンプルな手法です。この手法では、既存のデータと新たに追加されたデータをすべてマスターからセカンダリにコピーします。

この手法では、各レプリケーションですべてのデータを複製するので、通常ネットワーク負荷・処理コストは高くなります。とはいえデータを完全に削除してしまった場合などの復旧には有用であり、重要度のきわめて高いデータのバックアップ用途や、全体のデータ量が少ない場合には有効な手法です。

部分レプリケーション

部分レプリケーションは、データベース内の必要なデータだけを選択的にレプリケートする手法です。処理時間の短縮やストレージコストの面で利点がありますが、各レプリケーションでデータの整合性を保つには精緻な計画が必要であり、フルレプリケーションに比べると高度な手法です。

差分レプリケーション

差分データレプリケーションとは、最終更新時からデータソースに新たに追加、または更新されたデータ（差分）だけをレプリケートする手法です。差分レプリケーションでは通常、データソースと同期先間の持続的な接続が必要となり、レプリケーションを一定間隔でスケジュールすることで実行タイミングでの差分データだけを同期します。

差分レプリケーションは差分データだけをコピーするので、フルレプリケーションに比べてネットワーク負荷や処理時間を大幅に低減できます。場合によっては何時間という単位で時間を節約できるでしょう。とはいえ、すべてのデータソースが差分更新をサポートしているわけではないので、使いどころは限られます。

差分レプリケーションはどのように最終更新時との差分を検出するかで種類があるので、ここで代表的な手法を紹介します。

クエリベースのレプリケーション

クエリベースのレプリケーションは、レコードの最終更新日時を示すカラムをクエリして更新されたデータを検出する手法です。例えば、以下のようなクエリを使えばある最終更新日以降のデータだけに絞ってデータを更新できます。

Select * from Account Where updated_at> ‘yyyy-MM-dd(最終更新日時)'

各更新時にコピーする行はフルレプリケーションに比べて少なく済むので効率的です。ただし、クエリのフィルタリング時には全データを読み込むのでテーブルのデータ量によってはDB 負荷が大きくなったり、テーブルに更新日時用カラムを持つ必要がある、といった難点があります。また、最終更新日となるカラムそのものが消えてしまうハードデリートに弱い、という弱点があるので、クリティカルなデータに使うのはおすすめできません。

ログベースのレプリケーション

ログベースの差分レプリケーションは、データベース系のデータソースだけで使えるレプリケーション方法です。データベースのトランザクションを記録したログファイルから変更を読み取り、変更分だけをレプリケートします。ログを直接参照するためDB / DWH への負荷が少なく済み、ログからスキーマ変更のトランザクションを読み込めるため、DB 側のスキーマ変更にも対応できます。ただし、古いバージョンのDB では未対応の場合があります。

CDC（変更データキャプチャ）の解説を含む差分更新のさらに詳しい紹介はこちら

ETL / ELT

ETL は「Extract（抽出）、Transform（変換）、Load（ロード）」の順番で処理を実行しようという考え方で、データを変換・整形してからデータストアにレプリケーション（ロード）します。ETL では、多様なデータソースからデータを収集した後で、事前に定義したモデルに合わせてデータに統合・整形・重複削除といった処理を実行、最後に分析の際使用するデータストアにロードします。

ELT（Extract（抽出）、Load（ロード）、Transform（変換）は、ETL に対してデータストアへのロードを先に実行して、データベースの機能を活用してデータ変換を実行します。データをデータベースにレプリケーションしてから必要なデータ加工をデータベース内で行うので、大規模データを効率よく転送することに適した方式です。

ELT では連携先のデータベース上で変換処理を行うことから、豊富なコンピューティングリソースを持つクラウドデータウェアハウスソリューション（Snowflake、BigQuery、Redshift など）との組み合わせが最適です。

ETL / ELT について詳しくはこちら

レプリケートタイミング

レプリケートを実行するタイミングは、同期・非同期の2種類に分けられます。

同期レプリケーション

同期レプリケーションでは、データが追加・更新されると1つ以上の同期先に即座にコピーします。そのため、複製先のシステムには常にコピーが存在することとなり、マスターデータが消失した場合にもすぐにデータを復旧できます。データがプライマリストレージ（またはサーバー）に書き込まれる際には、セカンダリにも同時に書き込みリクエストが送信されます。

プライマリとセカンダリの両方が成功レスポンスを返すと、ストレージシステムがホストに書き込み成功のレスポンスを返します。この仕組みによって、プライマリとセカンダリ間でリアルタイムのデータ同期を実現できます。

非同期レプリケーション

非同期レプリケーションでは、データが追加された後で手動・または何らかのトリガーをベースにデータをコピーします。非同期レプリケーションはは、長距離間での利用やより狭い帯域幅での利用を想定されたデザインになっています。プライマリストレージにデータを書き込む際には、プライマリ側でデータの変更内容を記録しておきます。

プライマリストレージが書き込み成功のレスポンスを返すと、プライマリサイトがホストに書き込み成功のレスポンスを返します。その後、手動、もしくはユーザーが定義したトリガー条件に基づいてデータ同期が実行され、プライマリとセカンダリストレージ間の整合性を担保します。

レプリケート対象

多くの場合レプリケートする対象はデータベースやデータウェアハウスですが、レプリケートする対象によっては実装の構成が大きく変わってきます。データベース以外のレプリケート対象を利用する場合についてご紹介します。

SAN のレプリケーション

SAN（ストレージエリアネットワーク）は、大規模ネットワークで用いられる複数のコンピュータやストレージを結ぶネットワークです。SAN からSAN へのレプリケーションでは、アーカイブデータを集約したレポジトリをリアルタイムで別のデータレポジトリに複製します。SAN のレプリケーションは、社内インフラをすべて、または部分的にバックアップしておきたい場合におすすめの手法です。

この手法では、仮想マシンではなくストレージ全体がデータソースおよび同期先となります。通常単一のLUN 上に複数のVM を走らせておくわけですが、このような構成は複数VM 間でデータ・時間の整合性を保証する必要がある場合には便利です。

ゲストOS のレプリケーション

このレプリケーション手法では、データをディスクブロック単位でターゲットマシンにレプリケートします。OS、アプリケーション、データをすべて、ブロック単位でターゲットマシンにレプリケートできます。OS ファイルをターゲットマシンにステージング状態で用意しておき、フェイルオーバー時に操作を実行することでターゲットマシンがマスターのマシンに「変身する」という仕組みです。

アプリケーションのレプリケーション

アプリケーションのレプリケートは、トランザクションをもとに実施されます。各トランザクションは複数のシステムに保管、複製されます。この手法を使えば目標復旧時間（RTO）と目標復旧時点（PRO）を短縮できますが、フェイルオーバーの時点でOS を適切にメンテしておく必要があります。この手法は、SQL データベースでの利用が有効です。

データレプリケーションの課題・注意点

さて、ここまででデータレプリケーションの実装時、事前に考慮しておくとよいポイントを紹介しました。とはいえ、データレプリケーションは複雑で技術的にも実装が難しい処理です。ここまで見てきたように、データドリブンな意思決定や災害復旧への対策として大変有用ですが、シームレスで整合性のある処理を実装できなければ、データに非整合性が生じるといった問題が発生してしまいます。

このセクションでは、データレプリケーションを実装する際の主な課題や注意点と解決方法を紹介します。

非整合なデータ

データが複数のシステムやデータベースに分散した環境でレプリケーションを制御するのは、データが集約した環境で行うよりも複雑です。多様なデータソースのデータをそれぞれのタイミングでレプリケートしようとすれば、容易に非整合性が生まれてしまいます。

データを集約したデータウェアハウスがあれば、すべてのデータが1つのインスタンスに統合されている分、データが最新の状態かチェックするのは簡単です。データが複数のストレージ・マシン・データストア・システムに分散している環境では、データを更新する際にすべてのインスタンスのデータが同期され、最新であることを確認する必要が出てきます。

特にこうした環境では、レプリケーション処理の実装をしっかり計画、レビューして最適化しておくべきでしょう。

ストレージコストの増大

レプリケーションを行う場合、同じデータを複数の場所に保存しておく必要があるので、ストレージコストはかさみます。データレプリケーションプロジェクトを進める際には、こうしたコストをしっかり計画に入れておく必要があるでしょう。

処理・ネットワークコストの増大

複数サイトからデータを読み込むのは、単一サイトから読み込むよりも高速である場合が多い一方、複数データベースへの書き込みはどうしても遅くなります。そのため、レプリケーションは処理コストがかさみ、ネットワーク負荷を増大させます。

レプリケーション処理をどのように効率化してこの負荷を減少させるかは、重要な課題です。ELT 処理を活用するのは1つの手です。ELT であれば、データウェアハウスへのロードには通常の処理コストがかかる一方、データの整形・加工はデータベース側の処理を利用できるので、その分ネットワーク・転送負荷は下げられます。

レプリケーション処理を慎重に選択することで、運用時のトラブルを減らすことができるでしょう。

ノーコードでシームレスなデータレプリケーションの実装ならCData Sync

CData Sync を使えば、400種類以上のSaaS / DB データソースを人気のデータベース、データウェアハウスにレプリケートできます。設定はノーコードで手軽に実装でき、ダウンロードしてすぐに使用開始できるので、データパイプラインの構築が初めての方でも簡単に始められます。

さらにカスタムSQL 変換やdbt 連携といった高度なETL / ELT 処理、スケジュール実行やカスタムトリガーといった高度な機能もサポート。必要に応じてシンプルな処理、複雑なパイプラインの双方に対応できます。

全機能が利用可能な30日間無償トライアルがダウンロードできるので、この機会にぜひお試しください。