ルーティング オプション
アプリケーションから 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 つ以上の異なるアプリ プロファイルで有効にすると、警告が表示されます。このような構成を採用する場合、競合する読み取り - 変更 - 書き込みリクエストや確認 - 変更リクエストを異なるクラスタに送信しないようにする必要があります。