レプリケーションの概要

Bigtable のレプリケーションにより、データを複数のリージョンまたは同じリージョン内の複数のゾーンにコピーして、データの可用性と耐久性を向上させることができます。さらに、異なるタイプのリクエストを異なるクラスタにルーティングすることで、ワークロードを分離できます。

このページでは、Bigtable のレプリケーションの仕組みについて説明し、レプリケーションの一般的な使用例をいくつか紹介します。さらに、レプリケーションが有効にされている場合に Bigtable が使用する整合性モデルについて説明し、一方のクラスタが他方のクラスタにフェイルオーバーする際の処理についても説明します。

一般的な使用例で使用できる設定の例については、レプリケーション構成の例をご覧ください。
レプリケーションを使用するインスタンスの作成方法については、インスタンスを作成するをご覧ください。
既存のインスタンスのレプリケーションを有効にする方法については、クラスタを追加するをご覧ください。
レプリケーションに関連する費用については、料金をご覧ください。

このページを読む前に、Bigtable の概要を理解する必要があります。

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

Bigtable インスタンスでレプリケーションを使用するには、複数のクラスタを持つ新しいインスタンスを作成するか、既存のインスタンスに複数のクラスタを追加します。

Bigtable インスタンスは最大 8 つの Bigtable リージョンにクラスタを配置できます。これら 8 つのリージョンごとに、インスタンスに含めることができるのはゾーンごとに 1 つのクラスタのみです。たとえば、8 つのリージョンにそれぞれ 3 つのゾーンを持つインスタンスを作成する場合、そのインスタンスには最大で 24 個のクラスタを作成できます。

各リージョン内のそれぞれのゾーンに配置できるクラスタは 1 つのみです。クラスタを別々のゾーンまたはリージョンに配置すると、Google Cloud ゾーンまたはリージョンの一つが利用できなくなった場合でも、インスタンスのデータにアクセスできます。

複数のクラスタを持つインスタンスを作成すると、Bigtable はすぐにクラスタ間でデータの同期を開始し、インスタンスにクラスタが含まれる各ゾーンに個別の独立したデータのコピーを作成します。同様に、既存のインスタンスに新しいクラスタを追加すると、Bigtable は既存のデータを元のクラスタのゾーンから新しいクラスタのゾーンにコピーし、ゾーン間でデータへの変更を同期します。

Bigtable は、次のすべてのタイプの変更を含むデータへの変更をレプリケートします。

既存のテーブルのデータの更新
新しいテーブルと削除されたテーブル
追加および削除された列ファミリー
列ファミリーのガベージコレクションポリシーの変更

レプリケーションにはレイテンシがあり、クラスタ間の整合性は結果的です。

Bigtable はインスタンスの各クラスタをプライマリクラスタとして扱うため、各クラスタで読み取りと書き込みのどちらも可能です。また、さまざまなタイプのアプリケーションからのリクエストがさまざまなクラスタにルーティングされるようにインスタンスを設定することもできます。

インスタンスにクラスタを追加する場合は、その前に、レプリケートされたテーブルのガベージコレクションポリシーを変更する際に適用される制限事項について認識していることが必要です。

パフォーマンス

レプリケーションを使用するとパフォーマンスに影響するため、レプリケートされたインスタンスを作成する場合や、単一クラスタのインスタンスにクラスタを追加してレプリケーションを有効にする場合には、この点を考慮する必要があります。たとえば、異なるリージョンの複製クラスタは、通常、同じリージョンの複製クラスタよりもレプリケーションレイテンシが長くなります。また、複数のクラスタを持つインスタンス内のクラスタでは、レプリケーションを処理するために追加作業が発生するため、多くの場合、より多くのノードが必要になります。詳細については、パフォーマンスについてをご覧ください。

ユースケース

このセクションでは、Bigtable レプリケーションの一般的なユースケースについて説明します。各ユースケースの最適な構成設定とその他のユースケースの実装のヒントについては、レプリケーション設定の例をご覧ください。

バッチ読み取りからサービスを提供するアプリケーションの分離

単一のクラスタ上で、多数の大規模読み取りを実行するバッチ分析ジョブを、読み取りや書き込みを実行するアプリケーションと並行して実行すると、大規模バッチジョブがアプリケーションのユーザーにとって処理を遅くする可能性があります。レプリケーションでは、単一クラスタルーティングのアプリプロファイルを使用してバッチ分析ジョブとアプリケーショントラフィックを異なるクラスタにルーティングできるため、バッチジョブがアプリケーションのユーザーに影響を与えることはありません。こうした使用例の実装の詳細については、こちらをご覧ください。

可用性の向上

インスタンスに 1 つのクラスタしかない場合、データの耐久性と可用性は、そのクラスタが存在するゾーンに制限されます。レプリケーションでは、複数のゾーンまたはリージョンにデータの個別のコピーを保存し、必要に応じてクラスタ間で自動的にフェイルオーバーすることで、耐久性と可用性の両方を向上できます。こうした使用例の実装の詳細については、こちらをご覧ください。

ほぼリアルタイムのバックアップを提供する

たとえば、古いデータを読み取ることが許されない場合などでは、常に 1 つのクラスタにリクエストをルーティングする必要があります。ただし、1 つのクラスタでリクエストを処理し、別のクラスタをほぼリアルタイムのバックアップとして維持することで、レプリケーションを使用できます。サービスを提供するクラスタが利用できなくなった場合、手動でバックアップクラスタにフェイルオーバーすることでダウンタイムを最小限に抑えられます。こうした使用例の実装の詳細については、こちらをご覧ください。

データのグローバルプレゼンスを確保する

世界中の場所にレプリケーションを設定して、データをお客様の近くに配置できます。たとえば、米国、ヨーロッパ、アジアで複製クラスタを持つインスタンスを作成して、アプリケーショントラフィックを最も近いクラスタにルーティングするようアプリプロファイルを設定できます。こうした使用例の実装の詳細については、こちらをご覧ください。

整合性モデル

デフォルトで、Bigtable のレプリケーションは結果整合性があります。この用語は、1 つのクラスタに変更を書き込むと、最終的にその変更をインスタンスの他のクラスタから読み取れることを意味しますが、変更がクラスタ間でレプリケートされた後に限ります。

インスタンスが応答する場合は、レプリケーションのレイテンシは通常、数秒または数分であり、数時間に達することはありません。ただし、大量のデータをクラスタに書き込んでいる場合や、クラスタが過負荷になったり、一時的に使用不能になったりした場合は、レプリケーションが追いつくために時間がかかることがあります。また、クラスタ間の距離が離れていると、レプリケーションに時間がかかることがあります。その結果、常に書き込まれた最新の値を読み取れることを前提とすることや、書き込み後数秒待てば、Bigtable に変更をレプリケートする十分な時間が与えられると想定することは、通常安全とはいえません。

別の整合性の保証が必要な場合、Bigtable はレプリケーションが有効な場合に、書き込み後読み取りの整合性を提供することもできます。これにより、アプリケーションは最新の書き込みよりも古いデータを読み取ることがありません。アプリケーションのグループへの書き込み後読み取りの整合性を確保するため、グループ内の各アプリケーションが単一クラスタルーティング用に構成されたアプリプロファイルを使用し、すべてのアプリプロファイルが同じクラスタにリクエストをルーティングする必要があります。インスタンスの追加のクラスタを同時に他の目的に使用できます。

レプリケーションのユースケースによっては、Bigtable で強整合性を実現し、すべてのアプリケーションが同じ状態でデータを認識可能にすることもできます。強整合性を確保するには、単一クラスタルーティング用のアプリプロファイル構成を使用して前述の書き込み後読み取りの整合性を実現しますが、別のクラスタにフェイルオーバーする必要がある場合を除いて、インスタンスの追加クラスタは使用しないでください。レプリケーション設定の例を確認して、ユースケースに適しているかどうかを確認します。

競合の解決

Bigtable テーブルの各セルの値は 4 タプル（行キー、列ファミリー、列修飾子、タイムスタンプ）で一意に識別されます。これらの識別子の詳細については、Bigtable ストレージモデルをご覧ください。まったく同じ 4 つのタプルの 2 つの書き込みが 2 つの異なるクラスタに送信された場合、Bigtable は、サーバー側の時間に基づいて最後の書き込みを優先する内部アルゴリズムを使用して、競合を自動的に解決します。Bigtable の「最後の書き込みの優先」の実装は確定的で、レプリケーションが完了すると、すべてのクラスタの 4 つのタプルが同じ値になります。

アプリケーションプロファイル

インスタンスでレプリケーションを使用する場合、アプリケーションプロファイル（アプリプロファイル）を使用してルーティングポリシーを指定します。また、アプリプロファイルは、読み取り - 変更 - 書き込みオペレーション（インクリメントと追加を含む）と確認 - 変更オペレーション（条件付きミューテーションまたは条件付き書き込みとも呼ばれる）を含む単一行トランザクションを実行できるかどうかも決定します。

詳しくはアプリケーションプロファイルをご覧ください。一般的な使用例で使用できる設定の例については、レプリケーション構成の例をご覧ください。

ルーティングポリシー

すべてのアプリプロファイルに、アプリケーションからの受信リクエストを処理するクラスタを制御するルーティングポリシーがあります。ルーティングポリシーのオプションは次のとおりです。

単一クラスタルーティング: 指定した単一クラスタにすべてのリクエストを送信します。
任意のクラスタへのマルチクラスタルーティング: インスタンス内で最も近い使用可能なクラスタにリクエストを送信します。
クラスタグループルーティング: アプリプロファイルの設定で指定したクラスタグループ内で最も近い使用可能なクラスタにリクエストを送信します。

フェイルオーバー

Bigtable クラスタが応答しなくなった場合、レプリケーションにより受信トラフィックを同じインスタンスの別のクラスタにフェイルオーバーできます。フェイルオーバーは、アプリケーションが使用しているアプリプロファイルと、アプリプロファイルの構成方法に応じて、手動または自動で行えます。

詳しくはフェイルオーバーをご覧ください。

レプリケーションが有効な場合の行範囲の削除

Cloud Bigtable Admin API を使用すると、連続した範囲の行をその行キーに基づいて、テーブルから削除できます。レプリケーションを使用していないインスタンスでは、Bigtable は行範囲を迅速かつ効率的に削除できます。ただし、レプリケーションが有効にされている場合は、行範囲の削除は著しく遅くなり、大幅に効率が低下します。