1. 概要ガイド
  2. Oracle NoSQL Databaseの概要
  3. 複数リージョン・アーキテクチャ

複数リージョン・アーキテクチャ

Oracle NoSQL Databaseアプリケーションは、KVStoreと呼ばれるOracle NoSQL Databaseデータ・ストアに対してネットワーク・リクエストを実行することで、データの読取りおよび書込みを行います。組織において、NoSQLデータを保持するために複数のKVStoreを設定しなければならない場合があります。より現実的な状況として、これらのKVStoreクラスタを地理的に分散させることもあります。Oracle NoSQL Databaseの複数リージョン・アーキテクチャを使用すると、複数のKVStoreクラスタ内に表を作成して、これらのクラスタ間で一貫性のあるデータを維持できます。

たとえば、組織が3つのオンプレミスKVStoreをデプロイするユースケースを考えてみます。Frankfurt、London、Dublinとします。このように複数のKVStoreが関係する設定では、それぞれ独立したOracle NoSQL Databaseのインストールをリージョンと呼びます。地理的に分散された2つ以上の独立したKVStoreクラスタが双方向NoSQL Streamsによってブリッジされているアーキテクチャを、複数リージョン・アーキテクチャと呼びます。

図1-3 複数リージョン・アーキテクチャ


図1-3の説明が続きます。
「図1-3 複数リージョン・アーキテクチャ」の説明

複数のリージョンにわたって同様のデータを収集し、保守するとします。なんらかのメカニズムを通じて複数のリージョンにわたる表を作成し、すべての参加リージョンからの入力によって表が更新されるようにする必要があります。これは、複数リージョン表を使用して実現できます。複数リージョン表またはMR表は、様々なリージョンまたはインストールで格納および維持されるグローバル論理表です。これはどこでも読取り、どこでも書込みできる表で、複数のリージョンで保持されます。

図からわかるように、これらのリージョンで定義されているすべての複数リージョン表はNoSQL Streamsを介して同期されます。基本的に、分散するすべてのKVStoreが完全に接続された1つのグラフを形成します。各分散KVStoreクラスタには、各リモートKVStoreクラスタからのインバウンド・ストリームが1つあります。このインバウンド・ストリームは、ローカルKVStoreをリモートKVStoreからのすべての複数リージョン表にサブスクライブします。各リージョンではクロス・リージョン・サービス(XRegionサービス)を実行し、リモート・リージョン内のサブスクライブしている表からデータをプルする必要があります。

次に、複数リージョン・アーキテクチャに関する注意事項を示します。
  • ローカルおよびリモートのKVStoreは、
    • 異なるトポロジを使用している可能性があります。
    • エラスティック操作が発生する可能性があります。
    • 別個に管理されます。つまり、各KVStoreには独自の索引やセキュリティ資格証明などがあります。
    • 十分な表の作成権限と読取り権限を相互に持っています。
  • インバウンドおよびアウトバウンドのストリームは、
    • 完全に対称です。
    • 別個に管理され、アウトバウンドとインバウンドのストリーム間に一切の調整はありません。

クロス・リージョン・サービス

複数リージョンOracle NoSQL Database設定において、クロスリージョン・サービスまたはXRegionサービスは別個のノードで実行されるスタンドアロン・サービスです。これは、エージェントという簡単な用語で呼ばれることもあります。要件に応じて、1つのリージョンに1つ以上のエージェントをデプロイできます。XRegionサービスをデプロイするのは、ローカルKVStoreをリモートKVStoreと接続し、複数リージョン表を作成する場合です。

図1-4 リモートKVStoreからのインバウンド・ストリーム


図1-4の説明が続きます。
「図1-4 リモートKVStoreからのインバウンド・ストリーム」の説明

リモートのKVStoreに4つのシャードがあり、ローカルのKVStoreに3つのシャードがある例について考えます。前述の図のとおり、ローカルKVStoreでは2つのNoSQLエージェントをデプロイし、それぞれが2つのシャードをリモートKVStoreからストリームしています。これらのエージェントはリモートKVStoreからの更新をサブスクライブし、新規行および変更された行をローカルKVStoreにパブリッシュします。リモートKVStoreをローカルKVStoreに接続しているエージェントをまとめて、ローカルKVStoreのエージェント・グループと呼びます。

次の図に示すように、エージェントにより、リモートKVStoreのデータがローカルKVStoreのMR表のセットにストリームされます。

図1-5 単一エージェントのビュー


図1-5の説明が続きます。
「図1-5 単一エージェントのビュー」の説明

各インバウンド・ストリームはStreams APIのサブスクライバ・グループ機能を利用してサブスクライバ・グループを作成し、ストアからストリームを行います。各ローカル・エージェントには、次の役割があります。
  • リモートKVStoreからのインバウンド・サブスクリプション・ストリームを確立します。
  • 接続を維持し、障害が発生した場合は再接続します。
  • 失敗に備え、サブスクリプション・ストリームにチェックポイントを設定します。
  • リモートKVStoreからのMR表への書込みをサブスクライブします。
  • リモートKVStoreのエラスティック操作を自動処理します。
ローカルKVStoreの場合、インバウンド・ストリームのオーバーヘッドには次のものが含まれます。
  • リモートKVStoreからデータをストリームする、NoSQLエージェント内のスレッドのグループ。これらのスレッドはローカル・ストアの外部でスタンドアロン・エージェントとして実行されることに注意してください。エージェントはローカルKVStoreにサービスを提供しますが、ローカルKVStoreのコストには追加されません。
  • 競合の解決後にリモートKVStoreからストリームされたデータによって生じるローカルPUTまたはDELETE。
ローカルKVStoreの場合、アウトバウンド・ストリームのオーバーヘッドにはリモートKVStoreのチェックポイントの作成、読取りおよび書込みが含まれます。

複数リージョン表のライフ・サイクル

Oracle NoSQL Databaseで複数リージョン表(MR表)を作成および使用するには、実行するタスクの順序と関連する概念について注意する必要があります。

わかりやすくするために、MR表のライフ・サイクルについて、例を使用して説明します。Frankfurt、London、Dublinの3つのリージョンを持つOracle NoSQL Databaseについて考えてみます。Usersという表を作成し、図に示すように、3つすべてのリージョンのユーザー詳細を格納すると仮定します。

図1-6 複数リージョン表


図1-6の説明が続きます。
「図1-6 複数リージョン表」の説明

Users表を複数リージョン表として作成および管理するには、次のタスクを実行する必要があります。
  • 独立したKVStoreのデプロイ: 複数リージョンNoSQL Databaseの各リージョンに、KVStoreを個別にデプロイする必要があります。管理者ガイドの構成の概要を参照してください。
  • ローカル・リージョン名の設定: KVStoreをデプロイして、各参加リージョンに最初のMR表を作成する前に、ローカル・リージョン名を設定する必要があります。ローカル・リージョン名は、そのリージョンにMR表が作成されていないかぎり変更可能です。最初のMR表を作成した後は、ローカル・リージョン名は変更できなくなります。ローカル・リージョン名はそのリージョンで作成されるKVStoreとは完全に独立しています。管理者ガイドのローカル・リージョン名の設定を参照してください。
  • XRegionサービスの構成: MR表を作成する前に、1つ以上のエージェントを使用してXRegionサービスをデプロイする必要があります。エージェントはローカルKVStoreとは独立して実行されます。ローカルKVStoreの近くにデプロイすることをお薦めします。
    複数リージョン表をサポートするセキュアなKVStoreを設定する場合、管理者はXRegionサービス・エージェントに次の権限を付与する必要があります。
    • ローカル・ストアへのWRITE_SYSTEM_TABLE (または同等のwritesystableロール)。
    • ローカル・ストア内のすべての複数リージョン表に対する書込み権限。
    • リモート・ストア内のすべての複数リージョン表に対する読取り権限。
    • リモート・ストア内のチェックポイント表に対する書込み権限。

    エージェントのデプロイ方法の詳細は、管理者ガイドのXRegionサービスの構成を参照してください。

  • XRegionサービスの起動: XRSTARTコマンドを使用して、各リージョンでXRegionサービスを起動する必要があります。このサービスは長時間実行のプロセスであるため、コマンドの最後に&を付加してバックグラウンド・プロセスとして起動することをお薦めします。管理者ガイドのXRegionサービスの起動を参照してください。

    注意:

    ローカルKVStoreは、XRegionサービスを起動する前に起動する必要があります。ローカル・リージョンのKVStoreが起動していないかアクセスできない場合、XRegionサービスは起動しません。
  • リモート・リージョンの作成: MR表の作成および操作を行う前に、リモート・リージョンを定義する必要があります。リモート・リージョンはコマンドが実行されるリージョンとは異なるリージョンを表します。この例の場合、FrankfurtリージョンからUsersというMR表を作成するには、最初に他の2つのリージョン、つまり、LondonとDublinを、CREATE REGION DDLコマンドを使用して定義する必要があります。リモート・リージョンの作成方法の詳細は、管理者ガイドのリモート・リージョンの作成を参照してください。
  • MR表の作成: 接続されたグラフ内の各KVStore上にMR表を作成し、表で網羅するリージョンをリストにして指定します。この例では、FrankfurtリージョンおよびLondonリージョンにUsers表をMR表として作成するため、リージョンにFrankfurtとLondonを指定してCREATE TABLEコマンドを実行します。DDLコマンドでリージョンをリストする順序に決まりはありません。Users MR表は作成後、指定した各リモートKVStoreからの受信ストリームに含められます。それと対称的にリモートKVStoreでも、Users表がそれ自身の受信ストリームに含められます。MR表を正常に作成するには、次のことが必要です。
    • 指定したリージョンに表を作成するために必要な権限を事前に取得していることを確認します。そうしないと、MR表の作成はすべてのリージョンで失敗します。セキュリティ・ガイドのKVStoreで必要な権限を参照してください。
    • CREATE TABLE DDLコマンドに少なくとも1つのリージョンを指定します。リージョンを1つのみ指定した場合、MR表は指定したリージョンにのみ作成され、書込みは他のリージョンにはレプリケートされません。

      注意:

      単一リージョンのMR表はローカル表と同様に機能しますが、単一リージョンのMR表は将来、複数のリージョンに拡張できます。
    MR表の作成方法の詳細は、管理者ガイドのMR表の作成を参照してください。
  • MR表での読取り/書込み操作の実行(オプション): MR表の作成後、既存のデータ・アクセスAPIまたはDML文を使用して表に対する読取りまたは書込み操作を実行できます。MR表で機能する既存のデータ・アクセスAPIまたはDML文に変更はありません。通常の表に適用される次の内容は、MR表にも同様に適用されます。
    • 永続性と一貫性の構成および制約: MR表へのローカル書込みについては、一貫性モデルのセマンティクスは変わりません。通常(MR以外)の表への書込みと同じです。

      注意:

      MR表の場合、絶対的な一貫性は参加リージョンにわたってグローバルではありません。これは、読取り操作と書込み操作を実行する単一のリージョンに対してのみローカルです。
    • 表索引インフラストラクチャ: 各リージョンのMR表にプライマリ索引とセカンダリ索引を作成することは、通常の(非MR)表と同じです。ただし、MR表を任意のリージョンから削除する場合は、最初にその表に定義されている索引をすべて削除する必要があります。
    読取り操作:
    • MR表での各読取り操作はローカル読取りです。つまり、データのローカル・コピーのみを読み取ります。ただし、このローカル・コピーには、Oracle NoSQL Streamsの表同期の結果として生じた他の参加リージョンからの行が含まれる場合があります。
    書込み操作:
    • MR表で書込み操作(INSERT、UPDATEまたはDELETE)を実行すると、変更が複数のリージョンにわたって非同期的に同期されます。つまり、ローカル・リージョン内に行を書き込んだ場合、その書込み操作は完全にそのローカル・リージョン内で実行され、サブスクライブしているリージョンの更新を待つことはありません。
    • 複数のリージョン間で変更を同期する際のレイテンシには、レプリケーション(PULL)および書込み操作に関連する時間が含まれます。
    • 複数のリージョンで同じ主キーを持つ行を更新する場合は、競合解決ルールが適用され、どのリージョンの更新が最終とみなされるかが決定されます。この場合は、最新のタイムスタンプを持つ更新が優先され、データベースにコミットされます。
    • MR表から行を削除するたびに、7日間のTTL (存続時間)値が削除した行に自動的に適用されます。この7日間TTLは、行自体ではなく、削除されたキーのツームストンにのみ適用されます。この値は手動で設定または変更できません。

    例は管理者ガイドのMR表のアクセスおよび操作を参照してください。

  • MR表への新規リージョンの追加(オプション): Oracle NoSQL Databaseでは、MR表を新しいリージョンに拡張できます。これは事実上、既存のMR表に新しいリージョンを追加することを意味します。説明用の例では、Users表をFrankfurtとLondonという2つのリージョンにのみ作成したと仮定します。その後、このUsers表をDublinリージョンに拡張する場合は、次の操作を実行する必要があります。
    • 新しいリージョン(つまり、Dublin)にUsers MR表を作成します。新規リージョンにMR表を作成するときには、3つのリージョンをすべて指定する必要があります。管理者ガイドの新規リージョンでのMR表の作成を参照してください。
    • 既存のリージョン(FrankfurtとLondon)のUsers MR表に新しいリージョン(Dublin)を追加します。これはALTER TABLE DDLコマンドを使用して行います。管理者ガイドの既存リージョンへの新規リージョンの追加を参照してください。

      注意:

      既存のリージョンのデータ量によっては、新しいリージョンのMR表を他のリージョンからのデータで初期化するのに時間がかかる場合があります。ただし、新しいリージョンのMR表は、作成後すぐに読取り/書込み操作に使用できます。

      MR表の拡張方法および詳細なコード例は、管理者ガイドのユース・ケース2: 複数リージョン表の拡張を参照してください。

  • MR表からの既存リージョンの削除(オプション): 既存のMR表に新しいリージョンを追加できるだけでなく、リンクされているリージョンを表から削除することもできます。これは事実上、MR表を特定のリージョンから切断し、削除したリージョンからの書込みでMR表が同期されないようにすることを意味します。これは、MR表のコントラクトと呼ばれます。MR表のコントラクト方法および詳細なコード例は、管理者ガイドのユース・ケース3: 複数リージョン表のコントラクトを参照してください。
  • リモート・リージョンの削除(オプション): ビジネス要件に応じて、複数リージョンのOracle NoSQL Database設定から1つ以上の参加リージョンを削除できます。ただし、複数リージョンのNoSQLデータベースからリージョンを削除する前に、次のことを実行することをお薦めします。
    • そのリージョンにリンクされているすべてのMR表への書込みを停止します。
    • そのリージョン内のMR表に対するすべての書込みが、他のリージョンと同期していることを確認します。これは、異なるリージョン間でデータの一貫性を保つのに役立ちます。

    注意:

    NoSQL Databaseではリージョンを直接削除できますが、削除する前に、そのリージョンを他のすべてのリージョンから切り離すことをお薦めします。これにより、既存のリージョンと削除されるリージョンとのリンクを切断します。

    複数リージョンNoSQL Databaseからリージョンを削除する方法の詳細は、管理者ガイドのユース・ケース4: リージョンの削除を参照してください。

  • XRegionサービスとKVstoreの停止: XRegionサービスを別のホスト・マシンに再配置する場合は、現在のマシンでサービスを停止してから新しいホスト・マシンで再起動する必要があります。管理者ガイドのXRegionサービスの停止を参照してください。