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

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

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

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

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

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

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

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

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

  2. 2 つのアプリ プロファイル(名前は live-trafficbatch-analytics)を作成します。

    クラスタ ID が cluster-acluster-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-acluster-bcluster-c を使用していることを前提としています。

    同じアプリケーションを提供している場合 cluster-acluster-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 クライアントを使用する場合、そのクライアント側指標を使用してレイテンシをモニタリングできます。

可用性の向上

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

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

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

  • 2 つのクラスタが同じリージョンにある(ゾーンは異なる)。 このオプションにより、高可用性とクロスリージョン レプリケーション コストを発生させることなくフェイルオーバーする機能が提供されます。複製された Cloud 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 Platform Console を使用してインスタンスのクラスタをモニタリングし、クラスタが受信リクエストを処理していることを確認します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    構成の例:

    • ムンバイのゾーン asia-south1-a にある cluster-a
    • ムンバイのゾーン asia-south1-c にある cluster-b
    • 東京のゾーン asia-northeast1-a にある cluster-c
    • 東京のゾーン asia-northeast1-a にある cluster-d
  2. 各リージョンの近くにアプリケーション サーバーを配置します。

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

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

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

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

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

インスタンスごとに複数クラスタ ルーティングで使用できるアプリ プロファイルは 1 つだけです。複数クラスタ ルーティング プロファイルと単一クラスタ ルーティング プロファイルを組み合わせて使用することはできません。インスタンスではどちらか一方を使用する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ゾーンまたはリージョンが利用できなくなった場合に、Cloud Bigtable クラスタが自動的にフェイルオーバーしないようにするには、この使用例に単一クラスタ ルーティングを使用できます。このオプションは、以下の場合に発生する可能性があるコストとレイテンシを管理するのに適しています。Cloud Bigtable が遠方のリージョンとの間でトラフィックのルーティングを開始する場合、または自分の判断やビジネスルールに基づいてフェイルオーバーを決定する場合です。

この構成を実装するには、単一クラスタ ルーティングを使用する 4 つのアプリ プロファイルを作成します。各アプリ プロファイルは、Cloud Bigtable インスタンス内の異なるクラスタにルーティングされます。

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

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

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

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

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

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

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

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

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

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

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

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

その他の使用例

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Bigtable ドキュメント