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

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-5 複数リージョン・アーキテクチャ

「図1-5 複数リージョン・アーキテクチャ」の説明

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

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

また、複数リージョン・アーキテクチャでは次の点に注意してください。

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

複数リージョン・アーキテクチャでは子表を作成できます。つまり、既存の複数リージョン表に子表を含めることができます。複数リージョン・アーキテクチャで最上位レベルの表を有効にすると、作成された子表が、それらのリージョンで自動的に有効になります。子表の作成時にリージョンを明示的に指定する必要はありません。つまり、階層全体に対して複数リージョン・アーキテクチャが有効になります。

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

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

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

「図1-6 リモートKVStoreからのインバウンド・ストリーム」の説明

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

単一のXRegionサービス・エージェントがデータ・ストアの異なるシャードで同時書込みを処理する場合、複数のXRegionサービス・エージェントが必要です。次のステップを使用して、追加のXRegionエージェントが必要かどうかを判断できます。

ソースまたはターゲットのデータ・ストアが過負荷になっているかどうかを判別します。これは、リクエストの待機時間、タイムアウト、ストレージ・ノードのCPUおよびメモリー使用量などの様々なアプリケーション統計を使用して判断できます。

ソース・データ・ストアとターゲット・データ・ストアの両方が過負荷になっていない場合は、XRegionエージェントの統計を表示できます。showコマンドを使用すると、mrtable-agent-statisticsを表示できます。showコマンドの出力例を次に示します。

show mrtable-agent-statistics -agent 0 -json 
{ "operation": "show mrtable-agent-statistics", 
  "returnCode": 5000, 
  description": "Operation ends successfully", 
  "returnValue": { 
     "XRegionService-1_0": 
     {
      "timestamp": 1592901180001,  
      "statistics": 
      { "agentId": "XRegionService-1_0", 
        "beginMs": 1592901120001, 
        "dels": 1024, 
        "endMs": 1592901180001, 
        "incompatibleRows": 100, 
        "intervalMs": 60000, 
        "localRegion": "slc1", 
        "persistStreamBytes": 524288, 
        "puts": 2048, 
        "regionStat": 
         { "lnd": 
            { "completeWriteOps": 10, 
            "laggingMs": { "avg": 512, "max": 998, "min": 31 }, 
            "lastMessageMs": 1591594977587, 
            "lastModificationMs": 1591594941686, 
            "latencyMs": { "avg": 20, "max": 40, "min": 10 }
            }
           ……
         }
      }
   }
}

regionStatセクションには、latencyMs (avg, max, min)というリージョンごとのフィールドがあります。この統計は、経時的に監視する必要があります。ターゲットが過負荷になっておらず、この統計が増加し続けている場合は、XRegionエージェントがリモート書込みに追いつかず、スケーラビリティの問題が発生している可能性があります。

XRegionサービス・エージェントをさらに追加することで、水平方向のスケーラビリティを実現できます。データ・ストア・シャードのXRegionサービス・エージェントへのマッピングは、エージェントの負荷を分散するためにラウンドロビン方式で決定されます。

ノート:

データ・ストアのシャード数を超えるエージェントを構成しないでください。そうしないと、XRegionサービス・エージェントが起動しません。

各XRegionサービス・グループは、独立したXRegionサービス・エージェントのグループで構成され、グループ内の各エージェントはノード上で実行され、データ・ストアの1つ以上のシャードを処理します。XRegionサービス・グループのエージェントは、相互に完全に独立しています。つまり、各エージェントはグループ内の他のエージェントと直接対話しません。どのエージェントも、他のエージェントに影響を与えずに停止および再起動できます。XRegionサービス・エージェントは、構成されたストレージ・ノードを含まない個々のホストに追加することをお薦めします。

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

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

「図1-7 単一エージェントのビュー」の説明

各インバウンド・ストリームは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-8 複数リージョン表

「図1-8 複数リージョン表」の説明

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)を実行するたびに、変更は複数のリージョンにわたって非同期的にレプリケートされます。つまり、ローカル・リージョン内に行を書き込んだ場合、その書込み操作は完全にそのローカル・リージョン内で実行され、サブスクライブしているリージョンの更新を待つことはありません。
- 複数のリージョンにわたる変更をレプリケートするためのレイテンシには、次の処理に要する時間が含まれます。
  - リモート・リージョンで書込み操作を完了する、および
  - サブスクライブされた表からデータを受信する。
- 複数のリージョンで同じ主キーを持つ行を更新する場合は、組込み競合解消ルールが適用され、どのリージョンの更新を最終とみなすかが決定されます。このような場合はすべて、この組込み競合解消ルールにより、最新のタイムスタンプを保持する更新が優先され、データベースにコミットされます。
- 前述の組込み競合解消ルールは、TTL値の更新にも適用されます。
- MR表から行を削除する際、この表が存在する他のすべてのリージョンに変更を確実に伝播するための時間が与えられます。
- MR表での行の挿入または更新時にTTL値を定義できます。この値は、追加または更新される行にのみ適用されます。行レベルTTLは、表レベルTTLが存在する場合はそれをオーバーライドします。
- MR表には、リージョンによって異なる表レベルTTL値を指定できます。
- 行が他のリージョンにレプリケートされると、その有効期限はレプリケートされた行に絶対タイムスタンプとしてレプリケートされます。これは、デフォルトの表レベル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サービスの停止を参照してください。

複数リージョン表でのCRDTデータ型の使用

MR_COUNTERデータ型の概要

MR_Counterデータ型はカウンタCRDTです。CRDTは、競合のないレプリケートされたデータ型を表します。Oracle NoSQL Databaseの複数リージョン設定では、CRDTというデータ型は、サーバー間でレプリケート可能であり、その際にリージョンを個別に更新でき正しい共通の状態でそれが収束します。リージョン内の変更は同時実行され、相互に同期されません。つまり、CRDTを使用すると、ユーザーの介入なしにリージョン間で同時変更をマージできます。Oracle NoSQL Databaseでは、現在、MR_CounterというカウンタCRDTがサポートされています。MR_COUNTERデータ型はINTEGER、LONGまたはNUMBERデータ型のサブタイプです。スキーマレスJSONフィールドでMR_COUNTERデータ型を使用することもできます。つまり、JSONドキュメント内の1つ以上のフィールドをMR_COUNTERデータ型にできます。

複数リージョン表でMR_Counterが必要なのはなぜですか。

複数リージョンのデータベース構成では、同じデータのコピーを複数のリージョンに格納する必要があります。この構成では、異なるリージョンでデータが同時に変更される可能性があるという事実に対処する必要があります。

3つの異なるリージョン(データが3つの異なるOracle NoSQL Databaseストアに格納されているリージョン)にある複数リージョン表の例を考えてみます。リージョンをホストしているマシン間で調整を行わずに複数のリージョンの同じデータを同時に更新すると、リージョン間で不整合が発生する可能性があり、一般的な場合は解決できないことがあります。更新間で競合が発生した場合、リストアの一貫性とデータ整合性のために、更新の一部またはすべてを完全に削除する必要がある場合があります。たとえば、Oracle NoSQL Database内の複数リージョン表の現在の構成では、複数リージョン表の同じ列(カウンタ)が異なる値で同時に2つのリージョンにわたって更新されると、競合が発生します。

現在、競合解消方法では、最新の書込みによって複数のリージョンにわたる値が上書きされます。たとえば、リージョン1は値R1でcolumn1を更新し、region2は値R2でcolumn1を更新します。region1の後にregion2の更新が発生すると、両方のリージョンの列(カウンタ)の値はR2になります。これは実際には望ましくありません。かわりに、各リージョンの最後に列(カウンタ)を更新する必要があります。また、システム内部でリージョン間の列の合計を決定する必要もあります。

この競合を処理する1つの方法は、シリアライズ可能/線形化可能なトランザクションを作成することです(1つのトランザクションが完了し、すべてのリージョンで変更が同期されてから、次のトランザクションが発生します)。シリアライズ可能トランザクションがあると、パフォーマンスに大きな問題が発生します。ここでは、MR_COUNTERデータ型が便利です。MR_COUNTERデータ型では、シリアライズ可能なトランザクションが必要なく、競合解消が行われます。つまり、MR_COUNTERデータ型を使用すると、異なるリージョンでデータ変更を同時に実行できますが、データは常に一貫性のある状態にマージできます。このマージは、特別な競合解消コードやユーザーの介入なしに、MR_COUNTERデータ型によって自動的に実行されます。

MR_COUNTERデータ型のユースケース

顧客に異なるサービスとパッケージを提供する電気通信プロバイダを考えてみます。このようなサービスには、顧客とその家族がデータ使用プランを共有する「ファミリ・プラン」オプションがあります。顧客には、顧客の家族全員が集合的に使用する月の無料データ使用量制限が割り当てられます。顧客の家族の合計使用量がデータ制限の90%に達すると、電気通信プロバイダは顧客にアラートを送信します。顧客のファミリ・プランに、異なる物理的な地域に分散している4つのメンバーがいるとします。家族の合計消費量が無料使用量の90%に達すると、顧客は電気通信プロバイダからアラートを受け取る必要があります。レイテンシ、スループットおよびパフォーマンスの向上のために、データは異なるリージョンにレプリケートされます。つまり、4つのリージョンがあり、それぞれに顧客のデータ使用量の詳細を含むkvstoreがあります。ファミリ・メンバーの使用量は異なるリージョンで更新する必要があり、任意の時点の合計使用量を監視し、データ使用量が制限に達した場合はアラートを送信する必要があります。

MR_COUNTERデータ型は、異なるリージョン間でデータ使用量を競合のない方法で追跡する場合に理想的です。前述の例では、すべてのデータ・リージョンのデータ・ストアの増分カウンタによって、そのリージョンのデータ使用量が追跡されます。すべてのリージョンの統合されたデータ使用量は、ユーザーの介入なしに任意の時点で決定できます。つまり、任意の時点での合計データ使用量は、MR_COUNTERデータ型を使用して簡単に決定できます。

MR_COUNTERデータ型のタイプ

現在、Oracle NoSQL DatabaseでサポートされているMR_COUNTERデータ型は、Positive-Negative (PN)カウンタのみです。

Positive-Negative (PN)カウンタ

PNカウンタは増分または減分できます。したがって、これらは汎用カウンタとして機能します。たとえば、これらのカウンタを使用して、ソーシャル・メディアWebサイトでアクティブなユーザーの数をいつでもカウントできます。ユーザーがオフラインになったら、カウンタを減分する必要があります。

MR_COUNTER列を含む複数リージョン表を作成するには、管理者ガイドのMR_COUNTER列を含む複数リージョン表の作成に関する項を参照してください。