ルーティング オプション

アプリケーションから Bigtable にリクエストを送信する場合は、アプリ プロファイルを使用して、Bigtable にリクエストの処理方法を指示します。アプリ プロファイルでは、リクエストのルーティング ポリシーを指定します。レプリケーションを使用するインスタンスの場合、ルーティング ポリシーでリクエストを受信するクラスタとフェイルオーバーの処理方法を制御します。

このドキュメントでは、標準アプリ プロファイルで使用できるルーティング ポリシーについて説明します。

ルーティング ポリシーは、Data Boostプレビュー)を使用できないワークロードの分離ユースケースの場合に特に重要です。これらは、リクエストの優先度と組み合わせて構成できます。

ルーティング ポリシーはレプリケーションには影響しませんが、このページを読む前に、Bigtable レプリケーションの仕組みを理解する必要があります。また、フェイルオーバーもご覧ください。

単一クラスタのルーティング

単一クラスタのルーティング ポリシーでは、インスタンスの 1 つのクラスタにすべてのリクエストがルーティングされます。そのクラスタが使用できなくなった場合、手動で別のクラスタにフェイルオーバーする必要があります。

これは、単一行のトランザクションを有効にする唯一のルーティング ポリシーです。

レプリケートされたインスタンスは通常、結果整合性を提供します。ただし、単一クラスタのルーティングを使用するようにワークロード用のアプリ プロファイルを構成すると、レプリケートされたインスタンスのワークロードに対して書き込み後読み取りの整合性を実現することができ、読み取り / 書き込みリクエストを同じクラスタに送信します。ワークロード要件に応じて、レプリケートされたインスタンスの追加のワークロードのトラフィックを、インスタンスの他のクラスタにルーティングできます。

複数クラスタのルーティング

複数クラスタ ルーティング ポリシーは、インスタンスに送信されたリクエストを、そのインスタンスがクラスタを持つ最も近いリージョンにルーティングします。クラスタが利用できなくなった場合、トラフィックは自動的に利用可能な最も近いクラスタにフェイルオーバーされます。

この構成により、結果整合性が生まれます。複数クラスタ ルーティングでは、単一行トランザクションを有効にできません。単一行トランザクションを使用すると、データの競合が発生する可能性があるためです。詳細については、単一行のトランザクションをご覧ください。

高可用性(HA)が必要な場合は、複数クラスタ ルーティングを使用します。推奨されるインスタンスの構成と詳細については、高可用性(HA)の作成をご覧ください。

複数クラスタ ルーティングには、任意のクラスタクラスタ グループの 2 種類があります。

任意のクラスタ ルーティング

クラスタ ルーティングを使用すると、インスタンス内のすべてのクラスタでリクエストの受信とフェイルオーバーが可能になります。

クラスタ グループのルーティング

1 つ以上のインスタンスのクラスタをフェイルオーバーの可能性から除外する場合は、クラスタ グループのルーティングを使用できます。この形式の複数クラスタ ルーティングでは、アプリ プロファイルがトラフィックを送信できるクラスタのサブセットを指定できます。これは、クラスタを個別のワークロード用に予約する場合に役立ちます。

単一行のトランザクション

Bigtable のミューテーション(読み取り、書き込み、削除など)は、常に行レベルでアトミックに処理されます。同じミューテーション オペレーションに含まれている限り、単一行の複数の列に対するミューテーションも同様です。Bigtable では、複数の行をアトミックに更新するトランザクションはサポートされていません。

一方、Bigtable では他のデータベースでのトランザクションが必要となる一部の書き込みオペレーションがサポートされています。実際には、Bigtable は単一行のトランザクションを使用してこれらのオペレーションを行います。これらのオペレーションには読み取りと書き込みの両方が該当します。すべての読み取りと書き込みがアトミックに実行されますが、この場合でもオペレーションは行レベルでのみアトミックです。

  • インクリメントや追記を含む読み取り - 変更 - 書き込みオペレーション。読み取り - 変更 - 書き込みオペレーションでは、既存の値の読み取り、既存の値へのインクリメントや追加、更新された値のテーブルへの書き込みが行われます。
  • 確認 - 変更オペレーション。条件付きミューテーションまたは条件付き書き込みとも呼ばれています。確認 - 変更オペレーションでは、Bigtable は行が所定の条件を満たしているかどうかを確認します。行が条件を満たす場合、Bigtable は新しい値を行に書き込みます。

単一行のトランザクション間での競合

Bigtable インスタンスのすべてのクラスタは、読み取りと書き込みの両方を受け付けるプライマリ クラスタです。その結果、単一行のトランザクションが必要となるオペレーションでは、レプリケートされたインスタンスで問題が発生することがあります。

たとえば、チケット発行システムのデータを保存するために使用するテーブルがあるとします。整数カウンタを使用して、販売されたチケットの数を保存します。チケットが販売されるたびに、アプリは読み取り - 変更 - 書き込みオペレーションを送信してこのカウンタを 1 ずつ増やします。

インスタンスに 1 つのクラスタがある場合、リクエストはその唯一のクラスタが受信した順にアトミックに処理されるため、クライアント アプリで複数のチケットを同時に販売してデータを失うことなくカウンタをインクリメントできます。

一方、インスタンスに複数のクラスタがあり、アプリ プロファイルでマルチクラスタ ルーティングが許可されている場合、カウンタのインクリメントが同時にリクエストされると、各リクエストが異なるクラスタに送信されてから、インスタンス内のもう片方のクラスタに複製される可能性があります。異なるクラスタにルーティングされる 2 つのインクリメント リクエストを同時に送信した場合、各リクエストがもう片方のリクエストを認識することなくトランザクションが終了します。各クラスタのカウンタは 1 ずつ増えます。 Bigtable は、データがもう片方のクラスタに複製される場合、ユーザーが 2 ずつインクリメントする意図であったことを認識できない可能性があります。

意図しない結果が発生しないようにするために、Bigtable では次のことを行います。

  • 各アプリ プロファイルで、単一行トランザクションを許可するかどうかを指定する必要があります。
  • マルチクラスタのルーティングを使用するアプリ プロファイルで単一行のトランザクションを有効にできなくなります。これは、両方の機能を同時に有効にする安全な方法がないためです。
  • 単一クラスタのルーティングを使用していて、さらにそれぞれ異なるクラスタを参照している場合、単一行のトランザクションを 2 つ以上の異なるアプリ プロファイルで有効にすると、警告が表示されます。このような構成を採用する場合、競合する読み取り - 変更 - 書き込みリクエストや確認 - 変更リクエストを異なるクラスタに送信しないようにする必要があります。

次のステップ