レプリケーション設定の例

このページでは、Bigtable レプリケーションを有効にする場合の一般的な使用例について説明し、以下の使用例をサポートするために使用できる設定を紹介します。

このページでは、使用例がここにリストされていない場合に使用する設定を決定する方法についても説明します。

このページを読む前に、Bigtable レプリケーションの概要を理解する必要があります。

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

ユースケースにかかわらず、インスタンス内のすべてのクラスタに常に十分なノードをプロビジョニングして、各クラスタがアプリケーションから受け取る負荷に加えてレプリケーションを処理できるようにします。クラスタに十分なノードがない場合、レプリケーションの遅延が増加し、メモリの増大によりクラスタでパフォーマンスの問題が発生し、インスタンス内の他のクラスタへの書き込みが拒否される可能性があります。

バッチ分析ワークロードを他のアプリケーションから分離する

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

2 つのワークロードを分離するには:

  1. 2 つのクラスタを持つ新しいインスタンスを作成するか、既存のインスタンスに 2 つ目のクラスタを追加します。

    この構成に対する標準の CPU 使用率の推奨に従います。

  2. 2 つのアプリ プロファイル（名前は live-traffic と batch-analytics）を作成します。

    クラスタ ID が cluster-a と cluster-b の場合、live-traffic アプリ プロファイルはリクエストを cluster-a にルーティングし、batch-analytics アプリ プロファイルはリクエストを cluster-b にルーティングする必要があります。この構成では、同じアプリ プロファイルを使用するアプリケーションに対しては書き込み後読み取りの整合性が実現されますが、異なるアプリ プロファイルを使用するアプリケーションに対してはそうした特性は付与されません。

    必要に応じて、live-traffic アプリ プロファイルで単一行トランザクションを有効にできます。このプロファイルを読み取り専用に使用することを前提とする場合は、batch-analytics アプリ プロファイルで単一行トランザクションを有効にする必要はありません。

  3. live-traffic アプリ プロファイルを使用して、ライブ トラフィック ワークロードを実行します。

  4. ライブ トラフィック ワークロードの実行中は、batch-analytics アプリ プロファイルを使用して読み取り専用バッチ ワークロードを実行します。

  5. インスタンスのクラスタの CPU 使用率をモニタリングし、必要に応じてクラスタにノードを追加します。

  6. 任意のツールを使用してクライアント側のレイテンシをモニタリングします。Java 用 HBase クライアントを使用する場合、そのクライアント側指標を使用してレイテンシをモニタリングできます。

2 つの小さなワークロードを 1 つの大きなワークロードから分離するには:

  1. 3 つのクラスタを持つ新しいインスタンスを作成するか、既存インスタンスのクラスタ数が 3 つになるまでこのインスタンスにクラスタを追加します。

    この構成に対する標準の CPU 使用率の推奨に従います。

    これらの手順では、クラスタが ID cluster-a、cluster-b、cluster-c を使用していることを前提としています。

    同じアプリケーションを提供している場合 cluster-a と cluster-b で同じ数のノードを使用します。より大きなワークロードをサポートするには、cluster-c でより多数のノードを使用してください。

  2. 次のアプリ プロファイルを作成します。

    • live-traffic-app-a: アプリケーションから cluster-a への単一クラスタ ルーティング
    • live-traffic-app-b: アプリケーションから cluster-b への単一クラスタ ルーティング
    • batch-analytics: バッチ分析ジョブから cluster-c への単一クラスタ ルーティング

  3. live-traffic アプリ プロファイルを使用して、live-traffic ワークロードを実行します。

  4. live-traffic ワークロードの実行中は、batch-analytics アプリ プロファイルを使用して読み取り専用バッチ ワークロードを実行します。

  5. インスタンスのクラスタの CPU 使用率をモニタリングし、必要に応じてクラスタにノードを追加します。

  6. 任意のツールを使用してクライアント側のレイテンシをモニタリングします。Java 用 HBase クライアントを使用する場合、そのクライアント側指標を使用してレイテンシをモニタリングできます。

高可用性（HA）の作成

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

高可用性（HA）のユースケースのためにインスタンスを構成するには、複数クラスタのルーティングを使用するアプリ プロファイルを新規作成するか、複数クラスタのルーティングを使用するようにデフォルトのアプリ プロファイルを更新します。この構成により、結果整合性が生まれます。複数クラスタ ルーティングを使用すると、単一行トランザクションによってデータの競合が発生することがあるため、単一行トランザクションを有効にすることはできません。

Bigtable で高可用性を実現する方法について詳しくは、Bigtable を使用したグローバル データ プレゼンスの構築をご覧ください。

可用性を向上させる構成は次のとおりです。

  • 3 つ以上の異なるリージョンのクラスタ（推奨構成）。HA に推奨される構成は、それぞれ異なるリージョンにある N+2 個のクラスタを含むインスタンスです。たとえば、データを処理するクラスタの最小数が 2 つの場合、HA を維持するために 4 個のクラスタ インスタンスが必要になります。この構成では、2 つのリージョンが使用できなくなるというまれなケースでも稼働時間が提供されます。クラスタは複数の大陸に分散させることをおすすめします。

    構成の例:

    • アイオワのゾーン us-central1-a 内の cluster-a
    • ベルギーのゾーン europe-west1-d 内の cluster-b
    • 台湾のゾーン asia-east1-b 内の cluster-c

    この構成では、十分な数のノードをプロビジョニングして、3 つのクラスタ、3 つのリージョン インスタンスで 23% の CPU 使用率、4 つのクラスタ、4 リージョン インスタンスで 35% の CPU 使用率を維持します。これにより、2 つのリージョンが使用できなくなっても、残りのクラスタはすべてのトラフィックを処理できます。

  • 2 つのクラスタが同じリージョンにある（ゾーンは異なる）。このオプションは、リージョンの可用性内で高可用性を実現し、クロスリージョン レプリケーション コストを発生させることなくフェイルオーバーする機能が提供されます。フェイルオーバーのレイテンシは増加しません。複製された Bigtable インスタンス内のデータは、データが複製されているいずれかのゾーンが利用可能である限り、利用できます。

    構成の例:

    • シドニーのゾーン australia-southeast1-a 内の cluster-a
    • シドニーのゾーン australia-southeast1-b 内の cluster-b

    この構成に対する標準の CPU 使用率の推奨に従います。

  • 2 つのクラスタが異なるリージョンにある。このマルチリージョン構成は、前述のマルチゾーン構成と同様に高可用性を提供しますが、リージョンのいずれかに接続できない場合でもデータを使用できます。

    リージョン間で書き込みを複製すると料金が発生します。

    構成の例:

    • 東京のゾーン asia-northeast1-c 内の cluster-a
    • 香港のゾーン asia-east2-b 内の cluster-b

    この構成に対する標準の CPU 使用率の推奨に従います。

  • 2 つのクラスタがリージョン A にあり、3 つ目のクラスタがリージョン B にある。このオプションを選択すると、いずれかのリージョンに接続できなくてもデータを使用できるようになり、リージョン A に追加の容量が提供されます。

    リージョン間で書き込みを複製すると料金が発生します。リージョン A に書き込むと、リージョン B には 1 つのクラスタしかないため、1 回請求されます。リージョン B に書き込むと、リージョン A に 2 つのクラスタがあるため、2 回請求されます。

    構成の例:

    • ベルギーのゾーン europe-west1-b 内の cluster-a
    • ベルギーのゾーン europe-west1-d 内の cluster-b
    • フィンランドのゾーン europe-north1-c 内の cluster-c

    CPU 使用率の目標を、2 つのクラスタがあるリージョンで 35%、他のリージョンで 70% から始めます。インスタンスのクラスタをモニタリングし、必要に応じてノード数を調整して、各クラスタがフェイルオーバーを処理するのに十分なリソースを持つようにします。

この使用例のフェイルオーバーをシミュレートして、アプリケーションをテストできます。

  1. 複数クラスタのルーティングでアプリ プロファイルを使用して、テスト ワークロードを実行します。

  2. Google Cloud Console を使用してインスタンスのクラスタをモニタリングし、クラスタが受信リクエストを処理していることを確認します。

  3. いずれかのクラスタを削除して、停止をシミュレートします。

    この変更により、クラスタに格納されているデータのコピーも削除されます。

  4. レイテンシとエラー率を引き続きモニタリングします。残りのクラスタに十分な CPU リソースがある場合、受信リクエストに対応できるはずです。

  5. インスタンスにクラスタを追加し、インスタンスのモニタリングを続行します。データの新しいクラスタへのレプリケーションが開始されるはずです。

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

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

この使用例のインスタンスを構成するには、単一クラスタ ルーティングを使用するアプリケーション プロファイルを作成するか、単一クラスタ ルーティングを使用するようデフォルトのアプリ プロファイルを更新します。アプリ プロファイルで指定したクラスタは、受信リクエストを処理します。フェイルオーバーが必要な場合、他方のクラスタがバックアップとして機能します。この配置は、アクティブ / パッシブ構成とも呼ばれ、強整合性と書き込み後読み取りの整合性のどちらも実現します。必要に応じて、アプリ プロファイルで単一行トランザクションを有効にできます。

この構成に対する標準の CPU 使用率の推奨に従います。

この構成を実装するには:

  1. 単一クラスタのルーティングでアプリ プロファイルを使用して、テスト ワークロードを実行します。

  2. Google Cloud Console を使用してインスタンスのクラスタをモニタリングし、受信リクエストを処理しているクラスタが 1 つだけであることを確認します。

    その他のクラスタは、引き続き CPU リソースを使用してレプリケーションやその他のメンテナンス タスクを実行します。

  3. インスタンス内の 2 つ目のクラスタを参照するようにアプリ プロファイルを更新します。

    書き込み後読み取りの整合性を失うことに関する警告が表示されます。これはまた、強整合性を失うことも意味します。

    単一行トランザクションを有効にした場合、データ損失の可能性についての警告も表示されます。フェイルオーバーの発生中に競合する書き込みを送信した場合、データが失われます。

  4. インスタンスのモニタリングを続行します。2 つ目のクラスタが受信リクエストを処理していることがわかるはずです。

高可用性とリージョンの復元力を維持する

大陸内の 2 つの異なるリージョンに顧客が集中しているとしましょう。それぞれの集中リージョンで Bigtable クラスタを使用している顧客に対して、可能な限り顧客近くでサービスを提供したいと考えています。各リージョン内でデータの可用性を高めたいと考えています。また、1 つ以上のクラスタが使用できない場合は、フェイルオーバーを選択することも考えています。

この使用例では、リージョン A の 2 つのクラスタとリージョン B の 2 つのクラスタを持つインスタンスを作成できます。この構成は、Google Cloud リージョンに接続できない場合でも高可用性を提供します。ゾーンが利用できなくなっても、そのゾーンのリージョン内にある他のクラスタはまだ利用できるため、リージョンの復元力も提供されます。

この使用例では、ビジネスニーズに応じて、複数クラスタ ルーティングまたは単一クラスタ ルーティングのどちらを使用するかを選択できます。

この使用例に対してインスタンスを構成するには:

  1. 4 つのクラスタを持つ Bigtable インスタンスを作成します（リージョン A に 2 つ、リージョン B に 2 つ）。同じリージョン内のクラスタは、異なるゾーンに存在する必要があります。

    構成の例:

    • ムンバイのゾーン asia-south1-a 内の cluster-a
    • ムンバイのゾーン asia-south1-c 内の cluster-b
    • 東京のゾーン asia-northeast1-a 内の cluster-c
    • 東京のゾーン asia-northeast1-b 内の cluster-d

  2. 各リージョンの近くにアプリケーション サーバーを配置します。

この使用例では、ビジネスニーズに応じて、複数クラスタ ルーティングまたは単一クラスタ ルーティングのどちらを使用するかを選択できます。複数クラスタ ルーティングを使用している場合、Bigtable は自動的にフェイルオーバーを処理します。単一クラスタ ルーティングを使用する場合は、別のクラスタへのフェイルオーバーをどの時点で行うか自分で判断します。

単一クラスタ ルーティング オプション

ゾーンまたはリージョンが使用できない場合に Bigtable クラスタが自動的にフェイルオーバーしないようにするには、このユースケースで単一クラスタ ルーティングを使用できます。このオプションは、Bigtable が離れたリージョンとの間でトラフィックのルーティングを始めることで発生しかねない費用やレイテンシを管理する場合、または独自の判断やビジネスルールに基づいてフェイルオーバーの決定を行う場合に適しています。

この構成を実装するには、インスタンスにリクエストを送信する各アプリケーションに単一クラスタ ルーティングを使用するアプリ プロファイルを少なくとも 1 つ作成します。アプリ プロファイルは、Bigtable インスタンス内の任意のクラスタにルーティングできます。たとえば、ムンバイで 3 つ、東京で 6 つのアプリケーションが実行されている場合、ムンバイのアプリケーションの 1 つのアプリ プロファイルを asia-south1-a に、2 つを asia-south1-c にルーティングするよう構成できます。東京のアプリケーションの場合は、asia-northeast1-a にルーティングするアプリ プロファイルを 3 つ、asia-northeast1-b にルーティングする 3 つのアプリ プロファイルを構成します。

この構成に対する標準の CPU 使用率の推奨に従います。

この構成では、1 つ以上のクラスタが利用できなくなった場合、手動フェイルオーバーを行うか、ゾーンが再び利用できるようになるまで該当するゾーンでデータを一時的に利用不可にすることを選択できます。

複数クラスタ ルーティング オプション

この使用例を実装していて、アプリケーションがリージョンに接続できないときに別のリージョンに Bigtable が自動的にフェイルオーバーするようにしたい場合は、複数クラスタ ルーティングを利用します。

この構成を実装するには、各アプリケーションに複数クラスタ ルーティングを使用するアプリ プロファイルを新規作成するか、または複数クラスタ ルーティングを使用するようデフォルトのアプリ プロファイルを更新します。

この構成により、結果整合性が生まれます。リージョンが利用できなくなると、Bigtable リクエストは自動的に他のリージョンに送信されます。これが起こると、他のリージョンへのネットワーク トラフィックの課金が発生し、距離が遠いためにアプリケーションでレイテンシが高くなる可能性があります。

インスタンスを最初に設定するときは、各クラスタの CPU 使用率が 35% を超えないようにしてください。この目標に沿うことで、フェイルオーバーが発生した場合に、各クラスタがそのリージョン内の他のクラスタによって通常処理されるトラフィックを処理できるようにします。トラフィックと利用パターンに応じてこの目標を調整する必要が生じる場合があります。

この使用例のフェイルオーバーをシミュレートして、アプリケーションをテストできます。

  1. テスト ワークロードを実行します。

  2. Google Cloud コンソールを使用してインスタンスのクラスタをモニタリングし、4 つのクラスタがすべて受信リクエストを処理していることを確認します。

  3. ゾーン接続問題をシミュレートするために、リージョン A にあるクラスタの 1 つを削除します。

    この変更により、クラスタに格納されているデータのコピーも削除されます。

  4. 残りのクラスタのレイテンシとエラー率を引き続きモニタリングします。

    クラスタに十分な CPU リソースがある場合、受信リクエストに対応できるはずです。

  5. リージョン A のインスタンスにクラスタを追加し、インスタンスのモニタリングを続行します。

    データの新しいクラスタへのレプリケーションが開始されるはずです。

  6. リージョン接続問題をシミュレートするために、リージョン A にある両方のクラスタを削除します。

    この変更により、上記クラスタにあったデータのコピーが削除されます。

  7. 残りのクラスタのレイテンシとエラー率を引き続きモニタリングします。

    クラスタに十分な CPU リソースがある場合、以前に他のリージョンで処理された受信リクエストに対応できるはずです。クラスタに十分なリソースがない場合は、ノード数を調整することが必要になる場合があります。

ユーザーの近くにデータを保存する

世界中にユーザーがいる場合は、アプリケーションをユーザーの近くで実行し、データをできるだけアプリケーションの近くに配置することでレイテンシを低減できます。Bigtable では、複数の Google Cloud リージョンのクラスタを持つインスタンスを作成すると、データが各リージョンに自動的に複製されきます。

この使用例では、単一クラスタ ルーティングのアプリ プロファイルを使用します。複数クラスタ ルーティングは、クラスタ間の距離のため、この使用例には適切ではありません。クラスタが利用できなくなり、その複数クラスタ アプリ プロファイルが長距離にわたるトラフィックを自動的に再ルーティングすると、アプリケーションで許容できないレイテンシが発生し、予期しない追加のネットワーク コストが発生することがあります。

この使用例に対してインスタンスを構成するには:

  1. 米国、ヨーロッパ、アジアなど、3 つの異なるリージョンにクラスタを持つインスタンスを作成します。

    この構成に対する標準の CPU 使用率の推奨に従います。

  2. 各リージョンの近くにアプリケーション サーバーを配置します。

  3. 次のようなアプリ プロファイルを作成します。

    • clickstream-us: 米国のクラスタへの単一クラスタ ルーティング
    • clickstream-eu: ヨーロッパのクラスタへの単一クラスタ ルーティング
    • clickstream-asia: アジアのクラスタへの単一クラスタ ルーティング

この設定では、アプリケーションは最も近いクラスタのアプリ プロファイルを使用します。任意のクラスタへの書き込みは、他の 2 つのクラスタに自動的に複製されます。

その他の使用例

このページで説明されていない使用例がある場合は、次の質問を使用して、アプリ プロファイルの構成方法を決定してください。

次のステップ