データ複製とは

ソース・ロケーションから1つまたは複数のターゲット・ロケーションにデータをレプリケートすることにより、組織のグローバル・ユーザーがレイテンシーの問題に悩まされることなく、必要なデータにすぐにアクセスできるようにします。

同じデータのコピーが異なる場所に複数存在する場合、災害、機能停止、その他の理由により1つのコピーがアクセスできなくなった場合でも、別のコピーをバックアップとして使用できます。この冗長性により、ダウンタイムとデータ損失を最小限に抑え、事業継続性を向上させることができます。

データのレプリケーションは、クラウドだけでなく、ストレージ・エリア・ネットワーク、ローカル・エリア・ネットワーク、ローカル・ワイド・エリア・ネットワーク上でも行われます。複製は同期的に行うことも、非同期的に行うこともできます。つまり、オペレーションの管理方法によって異なります。

• 同期レプリケーションとは、データが常にメイン・サーバーとすべてのレプリカ・サーバーに同時にコピーされることを意味します。
  
  
• 非同期レプリケーションとは、データが最初にメイン・サーバーにコピーされ、その後、バッチでレプリカ・サーバーにコピーされることを意味します。

同期レプリケーションではデータが失われることはありませんが、非同期レプリケーションでは必要な帯域幅が大幅に少なく、コストも低くなります。

効果的なデータ・レプリケーション戦略を採用することで、次のようなメリットを得ることができます。

データ・レプリケーションは、複製プロセスの方法、目的、特性に基づいて、トランザクション・レプリケーション、スナップショット・レプリケーション、マージ・レプリケーションの3つに分類できます。

トランザクション・レプリケーションは、プライマリー・サーバー（パブリッシャー）からデータベースが丸ごとコピーされ、セカンダリー・サーバー（サブスクライバー）に送信されます。データの変更はすべて一貫して継続的に更新されます。データはリアルタイムで複製され、プライマリー・データベースからセカンダリー・サーバーに発生順に送信されるため、トランザクションの一貫性が保証されます。このタイプのデータベース・レプリケーションは、サーバー間の環境で一般的に使用されます。

スナップショット・レプリケーションでは、データベースのスナップショットがプライマリー・サーバーからセカンダリー・サーバーに配信されます。データは継続的に更新されるのではなく、スナップショットの時点で存在していたまま送信されます。このタイプのデータベース・レプリケーションは、データ変更があまりない場合や、パブリッシャーとサブスクライバーの間で初めて同期を開始する場合に推奨されます。スナップショットの複製はデータの変更を監視しないため、データのバックアップには役に立ちませんが、誤って削除した場合の復元に役立ちます。

マージ・レプリケーションとは、2つのデータベースを1つのデータベースに結合することです。データの変更は、パブリッシャーからサブスクライバーまで更新することができます。両者（プライマリー・サーバーとセカンダリー・サーバー）がデータに変更を加えることができるため、複雑なタイプのデータベース・レプリケーションです。このタイプのレプリケーションは、サーバーからクライアントへの環境での使用にのみ推奨されます。

レプリケーションのスキームとは、データ・レプリケーションを実行する際に必要な操作とタスクのことです。3つの主要なスキームは、完全レプリケーション、部分レプリケーション、およびレプリケーションなしです。

完全レプリケーションでは、プライマリー・データベース全体が分散システム内のすべてのサイトにコピーされます。このグローバル分散スキームは、高いデータベース冗長性、レイテンシーの低減、クエリ実行の高速化を実現します。完全レプリケーションの欠点は、同時実行性を実現するのが困難であり、更新プロセスに時間がかかることです。

部分レプリケーション・スキームでは、データベースの一部のセクションが一部またはすべてのサイトに複製されます。部分レプリケーションを使用すると、重要なデータや複製する必要があるデータに優先順位を付けて、フィールドのニーズに応じてリソースを分散できます。

複製なしとは、すべてのデータを単一のサイトにのみ保管する方式です。この場合、データの復旧が容易で、また同時実行を達成できます。一方で、複製なしのデメリットとして、可用性への悪影響と、クエリの実行速度の低下があります。

データ・レプリケーションの手法とは、プライマリー・ソースから 1 つ以上のターゲット・システムまたはロケーションにデータを複製するために使用される方法とメカニズムを指します。最も広く使用されている手法は、フルテーブル・レプリケーション、キーベース・レプリケーション、ログベース・レプリケーションです。

フルテーブル・レプリケーションでは、すべての新規および既存のデータを含め、すべてのデータがデータ・ソースから宛先にコピーされます。この手法は、レコードが定期的に削除される場合や、他の手法が技術的に不可能な場合に推奨されます。データ・セットが大きいため、フルテーブルの複製にはより多くの処理とネットワーク・リソースが必要であり、その費用も高くなります。

キーベースの増分レプリケーションでは、前回の更新以降に追加された新しいデータのみが複製されます。この手法では、コピーする行の数が減るため、効率的です。キー・ベースの増分レプリケーションの欠点の1つは、物理削除された以前の更新からのデータの複製ができないことです。

ログベースのレプリケーションは、データベースのログ・レコード（ログファイルまたはChangeLog）を監視することによって、データソースでデータに加えられた変更をキャプチャします。これらの変更はターゲット・システムに複製され、サポートされているデータベース・ソースにのみ適用されます。ログベースのレプリケーションは、ソース・データベース構造が静的である場合に推奨されます。

データ・レプリケーションは、データの可用性、フォールト・トレランス、パフォーマンスを向上させるためにさまざまな業界やシナリオで役立つ多用途の技術です。最も一般的なユースケースには、次のようなものがあります。

• 可用性とフェイルオーバーの向上：データ・レプリケーションは、重要なデータの冗長コピーを維持するために一般的に使用されます。ハードウェアまたはシステムに障害が発生した場合、アプリケーションはレプリカに切り替えることができるため、ダウンタイムとデータ損失を最小限に抑えることができます。
  
  
• 災害復旧（DR） ポジションの強化： データを別のロケーションに複製することで、組織は自然災害、火災、またはプライマリー・データセンターに影響を与えるその他の壊滅的なインシデントの際にデータが確実に保存されるようにすることができます。
  
  
• 負荷分散によるパフォーマンスの向上：読み取り要求を複数のデータベース・レプリカに分散することで、プライマリー・システムの負荷を分散し、ピーク時に最適なパフォーマンスを確保できます。
  
  
• グローバルな従業員の待ち時間を短縮：複数の大陸に複数のオフィスを持つ企業は、各ユーザーにより近いデータセンターにデータを複製できます。これにより、待ち時間が短縮され、ユーザー・エクスペリエンスが向上します。
  
  
• ビジネス・インテリジェンスと機械学習の強化： データ・レプリケーションでは、クラウドベースのビジネス・インテリジェンス・レポートを同期し、さまざまなデータソースからデータ・ストア（データウェアハウスやデータレイクを含む）へのデータ移動を可能にすることで、高度な分析をサポートします。
  
  
• 医療データへのアクセスの改善：電子カルテ（EHR）と患者のデータを複製することで、医療プロバイダーはデータの冗長性を維持しながら、重要な患者情報に迅速にアクセスできるようになります。
  
  
• ゲームとオンライン・マルチプレイヤー：ゲーム・サーバー間でゲーム・データとステータス情報を複製することで、オンライン・マルチプレーヤー・ゲームをサポートし、同期化と一貫したプレーヤー体験を保証します。

データ・レプリケーション戦略を導入するにあたって、システムの複雑さが増し、サーバー間の物理的距離が増えると、次のようなリスクが生じます。

データ・レプリケーション・プロセスを監督および監視するデータ管理システムを導入することで、関連するリスクを大幅に軽減できます。SaaS（Software as a Service）ベースのデータ・オブザーバビリティー・プラットフォームは、そのようなシステムの1つで、次を保証するのに役立ちます。

• データがクラウド・インスタンスを含む他のインスタンスに正常に複製されている
• レプリケーション・パイプラインとマイグレーション・パイプラインが待通りに機能している
• パイプラインの破損や不規則なデータ量に対して、即座にアラートで通知される
• データが時間通りに配信されている
• 配信されるデータは信頼性が高く、分析に使用できる

レプリケーション・プロセスに関与するデータ・パイプラインを監視することで、DataOpsエンジニアは、パイプラインを流れるすべてのデータが正確で完全であり、信頼できることを確認できます。これにより、利害関係者は各インスタンスに複製されたデータを信頼して使用できるようになります。監視に関しては、効果的なSaaS可観測性プラットフォームには次のような特徴があります。

• 詳細—問題の場所を詳細に提示
• 永続的—リネージュをたどってエラーの原因を理解
• 自動化—手動での作業によるエラーを減らし、しきい値を使用できるようにする
• ユビキタス—エンド・ツー・エンドのパイプライン・カバレッジを提供
• 即時—影響が及ぶ前にエラーを検出

パイプラインを追跡することで、体系的なトラブルシューティングが可能になります。これにより、ユーザーは分析において、更新された信頼性の高い正常なデータから常にメリットを得られるようになります。追跡できるさまざまなタイプのメタ・データには、タスクの期間、タスクのステータス、データの更新日などがあります。異常が発生した場合、追跡（およびアラート）によって、DataOpsエンジニアはデータの正常性を確保できます。

データ・パイプラインの異常アラートは、観測可能性のループを閉じるために不可欠なステップです。アラートを活用することで、DataOpsエンジニアは、データの正常性の問題がさまざまなインスタンス間でのデータ・レプリケーションに影響を与える前に修正できます。既存のデータ・システム内では、データ・エンジニアは次のアラートをトリガーできます。

• データ配信の失敗
• 予期しないスキーマの変更
• 未達成のSLA
• 列レベルの統計の異常（NULLや分布など）
• 不規則なデータ量とサイズ
• パイプラインの障害、非効率さ、エラー

アラートを積極的に設定し、ダッシュボードやその他の好みのツール（Slack、PagerDutyなど）を通じて監視することで、組織はデータ・レプリケーションのメリットを最大化し、事業継続性を確保できます。