NDCSのグローバル・アクティブ表

Oracle NoSQL Database Cloud Serviceは、表の作成、複数のリージョン間でのレプリケート、およびリージョナル・レプリカ間での同期データの維持が可能なグローバル・アクティブ表アーキテクチャをサポートしています。

今日の企業は、顧客により速く、より良いサービスを提供する必要があります。ネットワーク・レイテンシは、アプリケーションのパフォーマンスを評価するための重要なパラメータです。ネットワーク・レイテンシは、データ・パケットがネットワークを経由して移動する最小時間です。ユーザーは、どこからでもスムーズかつ迅速にオンライン活動を完了することを期待しています。このような期待に応えるために、企業はユーザーに最も近い分散リージョンでアプリケーションとデータをホストする必要があります。

Oracle NoSQL Database Cloud Serviceは、グローバル・アクティブ表を介してこれらの要件に対するソリューションを提供します。この機能により、リージョンに書き込まれたアプリケーション・データを複数のリージョン間で透過的にレプリケートできます。

グローバル・アクティブ表の利点:

NDCSでグローバル・アクティブ設定を選択する方法

グローバル・アクティブ表機能を使用すると、リージョンに書き込まれたアプリケーション・データを複数のリージョン間で透過的にレプリケートできます。

単一リージョン障害のまれなイベントは、ユーザーのエクスペリエンスに影響を与えません。たとえば、単一のリージョンがオフライン、分離または低下した場合、アプリケーションは別のリージョンにリダイレクトされ、以前と同じように読取りおよび書込みの実行を続行する必要があります。つまり、リージョンに障害が発生した場合でも、データベースはディザスタ・リカバリを提供する必要があります。Oracle NoSQL Database Cloud Service (NDCS)でグローバル・アクティブ表を使用して、アクティブ/アクティブ構成によるディザスタ・リカバリを提供したり、ローカル・データ・アクセスを使用して低レイテンシを達成するために複数のリージョン間でデータをアクティブにレプリケートしたりできます。

人気のあるウェブサイトから買い物をする旅行ユーザーのニーズを考慮してください。同じ日に世界のさまざまな地域から同じショッピングサイトにアクセスすることができます。どこにいても、ユーザーが最小限のレイテンシとシームレスなインタラクションを実現する必要があります。

NDCSのグローバル・アクティブ表機能は、前述の両方のシナリオに対するソリューションを提供します。2つの各シナリオについて検討し、高可用性、低レイテンシおよびディザスタ・リカバリを提供するための最適なソリューションとして、グローバル・アクティブ表がどのようになるかを理解します。

最初のシナリオでは、フェニックス(米国西部)、フランクフルト(ドイツ)および東京(日本)でNDCSを使用し、世界中の様々な地域でショッピングしている顧客からのショッピング情報を格納するShoppingCartという表があるとします。この例では、地理的に最も近いデータ・センターを介して顧客にサービスを提供しています。このような設定には、Oracle NoSQL Database Cloud Serviceが使用可能な複数の地理的な場所が含まれます。地理的に分散した2つ以上のリージョンと、これらの各リージョンで使用可能なNoSQL Database Cloudサービスを持つアーキテクチャは、グローバル・アクティブ表アーキテクチャと呼ばれます。表ShoppingCartはグローバル・アクティブ表であり、複数のリージョンでレプリケートされます。

アクティブ/アクティブ構成では、複数のリージョンでNDCSを使用でき、すべてのリージョンのデータが同期されます。リージョンに障害が発生した場合、他のレプリカ・リージョンのグローバル・アクティブ表は通常どおり機能し続け、障害が発生したリージョンの影響を受けません。障害が発生したリージョンが戻ると、そのリージョン表のレプリカが他のリージョンと同期されます。「グローバル・アクティブ」表には、リージョンが停止したときにアプリケーションが別のレプリカに接続されているという障害時リカバリが示されます。

2つ目のシナリオでは、Phoenixのユーザーがオンラインで買い物をし、ショッピング・カートに携帯電話を追加したとします。西海岸のNDCSリージョンがこのセッションを処理し、リージョンのローカル・データ・ストアからの読取りおよび書込みリクエストの最小レイテンシをユーザーが経験します。このユーザーはその後、ドイツへの飛行機に乗り、13時間後に到着し、ホテルに到着し、Wi-Fiネットワークに接続し、モバイル会社のオンラインストアに行き、より魅力的に見える電話の別のモデルがあることを発見しました。そのため、ユーザーは、この新しいモデルの電話でショッピングカートを更新し、モバイルeコマースストアを閲覧し続けます。最もプロキシ性の高いデータ・ストアであるフランクフルトのリージョナル・データ・ストアは、このセッションを提供し、ユーザーに米国のものと同じ低レイテンシの読取りおよび書込みエクスペリエンスを提供します。その後、ユーザーは日本に旅行し、最新のモバイルモデルに関する詳細情報を取得するためにローカルモバイルストアを訪問することを決定します。次に、ユーザーは、モバイル・ストアに存在する電話の最新モデルでショッピング・カートを更新します。NoSQL Database Cloud Serviceは、フェニックスで1つ、ドイツで2つ、日本で3つのリージョンで使用でき、複数のリージョン表レプリカがあるため、ユーザーがショッピング・カートを更新したり、モバイルEコマース・ストアを参照するたびに、パーソナライズされた検索結果およびその他のデータが、ユーザーに最も近いローカル・リージョンからフェッチされます。この種のローカル処理は、最小の待機時間、最高のパフォーマンスを提供し、広域ネットワークアクセスを排除します。

レプリケーション・オブジェクト

グローバル・アクティブ表で使用される用語:

グローバル・アクティブ表を作成および管理するための基本ルール:

グローバル・アクティブ表を作成および管理するには、次の基準を満たす必要があります。

ノート: NDCSでは、リージョナル表レプリケーションはバックグラウンドで非同期に実行されます。

グローバル・アクティブ表に子表を作成できます。グローバル・アクティブな表の子表は、シングルトン表またはグローバル・アクティブ表です。子表をグローバル・アクティブ表にするには、子表のスキーマを凍結し、リージョナル・レプリカを追加する必要があります。親表の地域レプリカの1つから選択できます。

グローバル・アクティブ表ワークフロー

グローバル・アクティブ表にレプリケートされるもの

既存のNoSQL表のリージョナル表レプリカを追加する場合は、シングルトン表をグローバル・アクティブ表に変換します。次は表にレプリケートされます。

ノート: OCIタグを使用すると、リソースをメタデータに追加できます。1つ以上のタグをグローバル・アクティブ表に関連付けることができます。OCIタグはレプリケートされず、グローバル・アクティブ表は異なるリージョンで異なるタグを持つことができます。

リージョナル表レプリカの追加

表をレプリケートすると、表が受信者リージョンと呼ばれる別のリージョンに作成されます。送信者リージョン内の表がシングルトンである場合、その表はグローバル・アクティブ表に変換されます。送信者リージョン内の表がすでにグローバル・アクティブ表である場合、表に別のリージョン・レプリカが追加されます。リージョナル・レプリカは、送信者リージョンの表のデータで初期化されます。たとえば、送信者リージョンの表に行が1000行ある場合、すべてのデータが新しく作成されたリージョン・レプリカにコピーされます。

ノート:リージョナル表レプリカを追加すると、レシーバ・リージョンの表が、送信者リージョンの表と同じ表名を持つ同じコンパートメントに配置されます。グローバル・アクティブ表の存続期間中は、いつでも別のコンパートメントに移動できます。

リージョナル表レプリカの容量(読取りユニット、書込みユニットおよびストレージ)

表のリージョナル・レプリカを追加すると、「読取り容量」、「書込み容量」および「ストレージ容量」フィールドは、送信者リージョン内の表の対応する値に自動的にデフォルト設定されます。ただし、受信側リージョンの表の読取り容量および書込み容量の値を編集および変更できます。表のストレージ容量は変更できません。受信側リージョンの表は、送信側リージョンのテーブルと同じストレージ容量を持ちます。グローバル・アクティブ表の容量モードは、オンデマンドまたはプロビジョニングのいずれかです。グローバル・アクティブ表の任意のリージョン・レプリカの容量モードは、作成後に変更することもできます。容量モードの変更は、そのリージョナル・レプリカに対してローカルであり、グローバル・アクティブ表の他のリージョナル・レプリカには影響しません。

リージョン表レプリカ内のレコードのTTL

Table Time to Live (TTL)は、データが表内に存続できる時間(時間数または日数)として表されます。Oracle NoSQL Database Cloud Serviceを使用すると、開発者は、表の行に対する有効期限を設定できます。その後、行は自動的に期限切れになり、使用できなくなります。指定した期間が経過すると、行は自動的に失効し、使用できなくなります。リージョナル表レプリカのTTLは、送信者リージョンの表のTTLと同じ値です。行が他のリージョンにレプリケートされると、その有効期限は絶対タイムスタンプとしてレプリケートされます、したがって、この行は、レプリケートされた時期に関係なく、同時に期限切れになります。

リージョナル表レプリカが作成されると、送信者リージョンの表のデータで初期化されます。表データのこの初期化中にTTL値に達すると、これらの行は期限切れになり、読取り操作ではこれらのレコードが表示されません。

リージョナル表レプリカの作成後のDDL操作のスコープ:

次のDDL操作にはグローバル・スコープがあります。つまり、1つのリージョナル表レプリカの変更は、すべてのリージョナル表レプリカに自動的に伝播されます。

次のDDL操作にはローカル・スコープがあり、これは、開始されたリージョナル表レプリカでのみ変更することを意味します。

グローバル・アクティブ表のデータ・モデリングに関する考慮事項

表のスキーマを凍結する必要があるのはなぜですか。

グローバル・アクティブ表構成では、複数のリージョンにわたってNDCSに表がデプロイされ、すべてのリージョンが読取りおよび書込みリクエストを同時に処理しています。NDCSに接続するアプリケーションは、最も近いレプリケーション・リージョンに接続するように設計する必要があります。表の主キー、シャード・キーおよびデータはレプリケーション・リージョン間で同一である必要があります。これらの3つは、アプリケーションでの表の使用方法および問合せの実行方法に内在する部分であるためです。グローバル・アクティブ表では、表レコードを複数のリージョンの表に同時に書き込むことができるため、表のスキーマのコンセンサスに到達する必要があります。これを行うには、スキーマの変更を防止し、表に対するスキーマに関するすべてのリージョンの即時コンセンサスを強制します。シンプルさ、パフォーマンスおよび予測可能性のために、Oracle NoSQL Cloud Serviceでは、リージョナル・レプリケーションに参加している表に対してスキーマを凍結する必要があります。したがって、シングルトン表をグローバル・アクティブ表に変換する前に、表スキーマを凍結する必要があり、それ以上のスキーマ変更は許可されません。リージョナル・レプリカの作成後にグローバル・アクティブ表のスキーマを変更する必要がある場合は、まずすべてのリージョナル・レプリカを削除し、表のスキーマを変更してから、リージョナル・レプリカを再追加する必要があります。Oracle NoSQL Cloudサービスは、すべてのリージョナル・レプリカを送信者リージョンからの最新データで再移入します。このため、スキーマの柔軟性が向上し、スキーマの変更が不要になるため、表に少なくとも1つのJSON列を含めることをお薦めします。

グローバル・アクティブ表でのIDの定義

ポリシーおよびユーザー権限

表のIAMポリシーは、送信者リージョンに固有です。

ユーザーがシングルトン表またはグローバル・アクティブ表のレプリカを追加した場合、受信側リージョンにポリシーまたはユーザー権限は追加されません。レプリカを作成および管理するソース・リージョンのユーザーは、受信者リージョンで必要な権限も持っている必要があります。それ以外の場合は、ユーザーがリージョナル・テーブル・レプリカを追加したときにエラーが発生します。

リージョン表のレプリカが作成されると、送信者リージョンから受信者リージョンにデータ変更をレプリケートしても、ユーザー権限は必要ありません。つまり、あるレプリカ表のデータ変更は、ユーザー権限に関係なく、他のすべての表レプリカにレプリケートされます。リージョナル表のレプリカを作成および管理するために必要な権限を次に示します。

レプリカの追加:

表のレプリカを管理するユーザーは、送信者リージョンおよび既存のすべての受信者リージョンでNOSQL_TABLE_ALTER権限を持っている必要があります。新しいレプリカを作成するユーザーは、(レプリカを作成する必要がある)レシーバ・リージョンにNOSQL_TABLE_CREATE権限が必要です。リージョナル表レプリカを作成すると、送信者リージョン内の表の既存の読取りおよび書込み権限は、受信者リージョンに作成されません。レシーバ・リージョンで新しいレプリカを作成するユーザーは、作成するすべてのリージョン表レプリカに対する表の読取りおよび書込み権限の作成を担当します。

レプリカの削除:

表のレプリカを管理するユーザーは、送信者リージョンおよび既存のすべての受信者リージョンでNOSQL_TABLE_ALTER権限を持っている必要があります。レプリカを削除するユーザーは、レシーバ・リージョン(レプリカを削除する必要がある)でNOSQL_TABLE_DROP権限を持っている必要があります。

索引の作成:

リージョナル・テーブル・レプリカで索引を作成するユーザーには、NOSQL_INDEX_CREATE権限が必要です。

索引の削除:

リージョナル・テーブル・レプリカ内の索引を削除するユーザーは、NOSQL_INDEX_DROP権限を持っている必要があります。

表の制限/TTLの更新:

表のレプリカを管理するユーザーは、すべてのリージョナル表レプリカでNOSQL_TABLE_ALTER権限を持っている必要があります。

読取り、書込みおよびACIDトランザクション

グローバル・アクティブ表を作成した後、既存のデータ・アクセスAPIやDML文を使用して、表に対する書込みまたは読取り操作を実行できます。

最良の待機時間のために、アプリケーションは通常、ローカル・リージョン・レプリカから読み取られます。ローカル・リージョナル・レプリカのデータには、他のリージョナル表レプリカからレプリケートされたデータ更新も含まれます。グローバル・アクティブ表で書込み操作(INSERT、UPDATEまたはDELETE)を実行すると、変更は複数のリージョンにわたって非同期的にレプリケートされます。つまり、送信者リージョンに行を記述すると、レプリカ・リージョンの更新を待機せずに、書込み操作が送信者リージョンで完全に実行されます。複数のリージョンが同じ主キーを持つ行を更新する場合、どのリージョンの更新が最終とみなされるかを判断するためのルールが適用されます。このような場合はすべて、この組込み競合解消ルールにより、最新のタイムスタンプを保持する更新が優先され、データベースにコミットされます。このルールは、複数のリージョンからのTTL値を同時に更新する場合にも適用されます。

ACIDトランザクションはリージョンに対してローカルです。トランザクションがコミットされると、書込みが発生したリージョンでは、アトミック、一貫性、分離および永続性が保証されます。リージョナル表レプリカの一貫性モデル・セマンティクスは、レプリケートされていない表と同じです。リージョナル・テーブル・レプリカの一貫性は絶対的ではありません。絶対一貫性は、読取り操作を実行する単一のリージョンに対してローカルです。送信者リージョンから受信者リージョンにレプリケートされるデータの読取りは常に一貫しています。

送信者リージョンからの書込みは、タイム・ラグ内のすべての受信者リージョンにレプリケートされます。複数のリージョン間で変更をレプリケートするこのタイム・ラグには、送信者リージョンのリージョナル表レプリカからのデータの受信に要した時間、および受信者リージョンでの書込み操作の完了に要した時間が含まれます。最終的に、受信者リージョンは送信者リージョンから更新を取得し、受信者リージョンは送信者リージョンで発生したトランザクション更新を逃しません。すべてのリージョナル表レプリカが最終的に書込みを受信し、永続的になります。

レプリカ・ラグの概要

グローバル・アクティブ表で書込み操作(INSERT、UPDATEまたはDELETE)を実行すると、変更は複数のリージョンにわたって非同期的にレプリケートされます。

つまり、送信者リージョンに行を記述すると、レプリカ・リージョンの更新を待機せずに、書込み操作が送信者リージョンで完全に実行されます。ネットワーク・レイテンシは、受信側リージョンに変更をレプリケートする際のタイム・ラグを作成します。複数のリージョン間で変更をレプリケートするためのレイテンシには、レプリカから書込みを受信して受信側リージョンで適用するために要した時間が含まれます。送信側リージョンに表に対するアプリケーション書込みがない場合、サービスは遅延の近似を計算するためにPingメカニズムを使用し、受信側リージョンでラグ統計を引き続き使用できます。

「レプリカ・ラグ」メトリックの詳細は、「レプリカ・ラグの詳細」を参照してください。

グローバル・アクティブ表の作成の概要

グローバル・アクティブ表を作成するプロセスは、シングルトン表を作成してからグローバル・アクティブ表に変換することから始まります。

グローバル・アクティブ表を作成するステップは、次のとおりです。