NDCSのグローバル・アクティブ表
Oracle NoSQL Database Cloud Serviceでは、表の作成、複数のリージョンへのレプリケート、およびリージョンのレプリカ間の同期データのメンテナンスを行うことができるグローバル・アクティブ表アーキテクチャをサポートしています。
今日の企業は、顧客により迅速で優れたサービスを提供する必要があります。ネットワーク待機時間は、アプリケーションのパフォーマンスを評価するための重要なパラメータです。ネットワーク待機時間は、データパケットがネットワークを経由する最小時間です。ユーザーは、どこからでもスムーズかつ迅速にオンライン活動を完了することを期待しています。このような期待に応えるために、企業は、ユーザーに最も近い分散リージョンでアプリケーションやデータをホストする必要があります。
Oracle NoSQL Database Cloud Serviceは、グローバル・アクティブ表を介してこれらの要件に対するソリューションを提供します。この機能により、リージョンに書き込まれたアプリケーション・データを複数のリージョン間で透過的にレプリケートできます。
- ローカルでの読取りおよび書込み、およびグローバルでのデータへのアクセス: 複数のリージョンでのグローバル・アクティブ表のアクティブ/アクティブ構成により、あるリージョンの表で実行された更新が、他のレプリケーション・リージョンの表のレプリカに自動的にレプリケートされます。データには、レプリケートされた任意のリージョンからアクセスできます。
- パフォーマンス: グローバル・アクティブ表を使用すると、データをローカルで読み書きできるため、1桁ミリ秒のレイテンシを実現できます。これは、グローバルに分散したアプリケーションのローカル・アクセスの特性です。これにより、大規模にスケーリングされたグローバル・アプリケーションのパフォーマンスが向上し、アプリケーション・リクエストの待機時間が短縮されます。
- 設定と管理が簡単: Oracle NoSQL Database Cloud Serviceを使用すると、グローバル・アクティブ表を使用してマルチリージョン・レプリケーションをデプロイおよび管理する複雑さが解消されます。リージョン表レプリカの追加は簡単で、API、TerraformまたはOCIコンソールを使用して実行できます。
- 複数リージョンのレジリエンシ: グローバル・アクティブ表では、リージョン障害のまれなケースでもフォルト・トレランスが有効になります。1つのリージョンが使用不可またはオフラインになった場合、アプリケーション・リクエストは表をレプリケートするリージョンにリダイレクトでき、この表に対して読取りおよび書込みを実行できます。
NDCSでグローバル・アクティブ・セットアップを選択する方法
グローバル・アクティブ表機能を使用すると、リージョンに書き込まれたアプリケーション・データを複数のリージョン間で透過的にレプリケートできます。
単一リージョン障害のまれなイベントは、ユーザーのエクスペリエンスに影響しません。たとえば、1つのリージョンがオフライン、分離または機能低下した場合、アプリケーションは別のリージョンにリダイレクトされ、以前と同様に読取りおよび書込みの実行を継続する必要があります。つまり、リージョンに障害が発生した場合でも、データベースは障害時リカバリを提供する必要があります。Oracle NoSQL Database Cloud Service (NDCS)のグローバル・アクティブ表を使用すると、アクティブ/アクティブ構成によるディザスタ・リカバリを提供したり、ローカル・データ・アクセスを使用して低レイテンシを達成するために複数のリージョン間でデータをアクティブにレプリケートできます。
人気のWebサイトから購入する旅行ユーザーのニーズを考慮してください。同じ日に世界のさまざまな場所から同じショッピングサイトにアクセスすることができます。ユーザーがどこにいても、最小レイテンシとシームレスなインタラクションを実現する必要があります。
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つ目の3つのリージョンで使用でき、ユーザーがショッピング・カートを更新したり、モバイルEコマース・ストアを参照したりすると、ユーザーに最も近いローカル・リージョンからパーソナライズされた検索結果およびその他のデータがフェッチされるたびに、複数のリージョン表レプリカが存在します。この種のローカル処理は、最小の待機時間、最高のパフォーマンスを提供し、広域ネットワークアクセスを排除します。
レプリケーション・オブジェクト
グローバル・アクティブ表で使用される用語:
- リージョン: Oracle Cloud Infrastructure (OCI)リージョン。お客様がアプリケーションをデプロイできる、ローカライズされた単一の地域です。
- 送信者リージョン: 表更新が他のリージョンにレプリケートされるリージョン。
- 受け側リージョン: 別のリージョンから表更新を受信するリージョン。
- シングルトン表: リージョン的にレプリケートされない表。
- リージョナル表レプリカ: 別のリージョンで作成された表のレプリカ。
- グローバル・アクティブ表: 1つ以上のリージョナル表のレプリカを持つ表。
グローバル・アクティブ表を作成および管理するための基本ルール:
- シングルトン表には、少なくとも1つのJSON列が必要です。
- 表のスキーマ状態はFROZENである必要があります。
- 受け側リージョンに、同じ名前の表が存在してはいけません。
- 受信者リージョンには、コンパートメント(送信者リージョン内のコンパートメントと同じ名前)がすでに存在している必要があります。
- 表を削除する前に、表のすべてのリージョナル表レプリカを削除する必要があります。
ノート:
NDCSでは、リージョナル表レプリケーションはバックグラウンドで非同期に実行されます。グローバル・アクティブ表に子表を作成できます。グローバル・アクティブ表の子表は、シングルトン表またはグローバル・アクティブ表です。子表をグローバル・アクティブ表にするには、子表のスキーマを凍結し、リージョナル・レプリカを追加する必要があります。親表のリージョン・レプリカの1つから選択できます。
グローバル・アクティブ表ワークフロー
グローバル・アクティブ表にレプリケートされる内容
- 表の定義/スキーマ
- 表内の索引- 2次索引の数および定義。
- 表内のデータ。
- 読取り容量および書込み容量- デフォルトでは、リージョナル・レプリカの読取り制限は、グローバル・アクティブ表の他のリージョナル・レプリカの読取り制限と同じです。ただし、読取り操作は純粋にローカルであるため、オプションで各リージョンの読取り制限を設定できます。デフォルトでは、リージョナル・レプリカの書込み制限は、グローバル・アクティブ表の他のリージョナル・レプリカの書込み制限と同じです。ただし、書込み制限はリージョンごとに異なる値に設定できます。
- ストレージ容量- グローバルアクティブテーブルのすべてのリージョナルレプリカは同じテーブルデータを格納するため、リージョナルレプリカのストレージ制限は、グローバルアクティブテーブルのほかのすべてのリージョナルレプリカにコピーされます。
- 表のデフォルトの表Time to Live (TTL)
リージョナルテーブルレプリカの追加
ノート:
リージョナル表レプリカを追加すると、レシーバ・リージョンの表が、送信者リージョンの表と同じ表名を持つ同じコンパートメントに配置されます。グローバル・アクティブ表の存続期間中は、いつでも別のコンパートメントに移動できます。リージョン表レプリカの容量(読取りユニット、書込みユニットおよびストレージ)
テーブルのリージョナルレプリカを追加すると、read capacity、write capacity、および storage capacityフィールドは、送信者リージョン内のテーブルの対応する値に自動的にデフォルト設定されます。ただし、レシーバ・リージョンの表の読取り容量および書込み容量の値を編集および変更できます。テーブルのストレージ容量は変更できません。受信側リージョンの表は、送信側リージョンの表と同じストレージ容量を持ちます。グローバル・アクティブ表の容量モードは、オンデマンドまたはプロビジョニングのいずれかです。グローバル・アクティブ表の容量モードは、作成後に変更することもできます。容量モードの変更は、そのリージョナル・レプリカに対してローカルであり、グローバル・アクティブ表の他のリージョナル・レプリカには影響しません。
リージョナル表レプリカ内のレコードのTTL
表Time to Live (TTL)は、表のデータが存続できる時間(時間または日数)で表されます。Oracle NoSQL Database Cloud Serviceを使用すると、開発者は、表の行に対する有効期限を設定でき、その後、行は自動的に期限切れになり、使用できなくなります。指定した期間を経過すると、行は自動的に期限切れになり、使用できなくなります。リージョナル表レプリカのTTLは、送信者リージョンの表のTTLと同じ値です。行が他のリージョンにレプリケートされると、その有効期限は絶対タイムスタンプとしてレプリケートされます。したがって、この行は、いつレプリケートされたかにかかわらず、同時に期限切れになります。
リージョナル表レプリカが作成されると、送信者リージョンの表のデータで初期化されます。表データのこの初期化中にTTL値に達すると、これらの行は期限切れになり、読取り操作ではこれらのレコードは表示されません。
リージョナル表レプリカの作成後のDDL操作の範囲:
- 索引の追加
- 索引の削除
- 表のストレージ容量の変更
- 表TTLの変更
- 読取りユニットの変更
- 書込みユニットの変更
- キャパシティ・モードをオンデマンドからプロビジョニング済、またはその逆に変更
グローバル・アクティブ表のデータ・モデリングに関する考慮事項
表のスキーマを凍結する必要があるのはなぜですか。
グローバル・アクティブ表構成では、NDCS内の表が複数のリージョンにデプロイされ、すべてのリージョンが読取りリクエストと書込みリクエストを同時に処理しています。NDCSに接続するアプリケーションは、最も近いレプリケーション・リージョンに接続するように設計する必要があります。表の主キー、シャード・キーおよびデータはレプリケーション・リージョン間で同一である必要があります。これらの3つは、アプリケーションでの表の使用方法および問合せの実行方法の固有部分であるためです。グローバル・アクティブ表では、表レコードを複数のリージョンの表に同時に書き込むことができるため、表のスキーマのコンセンサスに到達する必要があります。これを行うには、スキーマの変更を防止し、すべてのリージョンに表のスキーマに関する即時のコンセンサスを強制します。簡易性、パフォーマンスおよび予測可能性のために、Oracle NoSQL Cloud Serviceでは、リージョナル・レプリケーションに参加している表に対してスキーマを凍結する必要があります。したがって、シングルトン表をグローバル・アクティブ表に変換する前に、表スキーマを凍結する必要があり、それ以上のスキーマ変更は許可されません。リージョナル・レプリカの作成後にグローバル・アクティブ表のスキーマを変更する必要がある場合は、まずすべてのリージョナル・レプリカを削除し、表のスキーマを変更してから、リージョナル・レプリカを再度追加する必要があります。Oracle NoSQL Cloudサービスは、すべてのリージョナル・レプリカを、送信者リージョンの最新データで再移入します。
スキーマをフリーズするときに表に少なくとも1つのJSON列が必要なのはなぜですか。
リージョナル表レプリカでのスキーマ変更の調整は困難であり、潜在的なエラー・ケースにつながります。JSON列を指定すると、スキーマの柔軟性が向上し、スキーマの変更が不要になります。
グローバル・アクティブ表でのアイデンティティの定義
-
リージョナルテーブルレプリカ内のレコードの識別情報は、テーブルのすべてのリージョナルレプリカで一意である必要があります。自然キー(表内の各レコードを識別するグローバル一意識別子)は、すべてのリージョナル表レプリカ間で一意性を保証できる場合にのみ、グローバル・アクティブ表でアイデンティティとして使用できます。
- グローバル・アクティブ表でシステム生成のIDを使用する場合は、UUIDを使用する必要があります。アイデンティティ列は、リージョナル表のレプリカ間で一意であることが保証されていないため、ほとんどの場合、使用しないでください。
ポリシーおよびユーザー権限
表のIAMポリシーは、送信者リージョンに固有です。
ユーザーがシングルトン表またはグローバル・アクティブ表のレプリカを追加する場合、レシーバ・リージョンにポリシーまたはユーザー権限は追加されません。レプリカを作成および管理するソース・リージョンのユーザーも、レシーバ・リージョンで必要な権限を持っている必要があります。そうしないと、ユーザーがリージョナルテーブルレプリカを追加したときにエラーが発生します。
リージョナル表のレプリカが作成されると、送信者リージョンから受信者リージョンにデータ変更をレプリケートしても、ユーザー権限は必要ありません。つまり、ユーザー権限に関係なく、1つのレプリカ表のデータ変更が他のすべての表レプリカでレプリケートされます。リージョナル表レプリカの作成および管理に必要な権限を次にリストします。
レプリカの追加:
表のレプリカを管理するユーザーは、送信者リージョンおよび既存のすべての受信者リージョンに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メカニズムを使用してラグの近似を計算し、レシーバ・リージョンでラグ統計を引き続き使用できます。
「レプリカ・ラグ」メトリックの詳細は、レプリカ・ラグの詳細を参照してください。
グローバル・アクティブ表の作成の概要
グローバル・アクティブ表を作成するプロセスは、シングルトン表を作成し、それをグローバル・アクティブ表に変換することから始まります。
- シングルトン表を作成し、1つの列がJSONであることを確認します。
- 表のスキーマ状態を「変更可能」から「確定済」に変更します。
- 表のリージョナル・レプリカを追加するリージョンを決定します。リージョナル・レプリカを追加する際、「読取り容量」、「書込み容量」および「ストレージ容量」フィールドには、送信者リージョンの対応する値が自動的に移入されます。表の読取り容量および書込み容量を変更できます。
- クラウド・サービスによって、受信側リージョンに表が作成されます。ソース・リージョンの表にデータがある場合、送信者リージョンから受信者リージョンへのデータのコピーが開始されます。送信者リージョンから受信者リージョンにデータがコピーされると、初期化率は0から100に増加します。次に示すように、OCIコンソールの表情報の下に初期化率の値を表示できます。初期化プロセスが完了するまで、新しいリージョナル表レプリカではDML操作は許可されません。
