翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Keyspaces でのマルチリージョンレプリケーションの仕組み

このセクションでは、Amazon Keyspaces マルチリージョンレプリケーションの仕組みの概要を説明します。料金の詳細については、「Amazon Keyspaces (for Apache Cassandra) pricing (Amazon Keyspaces (Apache Cassandra 向け) の料金)」を参照してください。

Amazon Keyspaces でのマルチリージョンレプリケーションの仕組み

Amazon Keyspaces マルチリージョンレプリケーションは、データを独立した地理的分散型に分散するデータ耐障害性アーキテクチャを実装します AWS リージョン。アクティブ-アクティブレプリケーションを使用しているため、ローカルで低レイテンシーを実現し、各リージョンが個別に読み取りと書き込みを実行できます。

Amazon Keyspaces マルチリージョンキー空間を作成すると、データの複製先になる追加リージョンを最大 5 つ選択できます。マルチリージョンのキー空間に作成するテーブルは、Amazon Keyspaces に 1 つの単位と認識される複数のレプリカテーブル (リージョンごとに 1 つ) で構成されます。

すべてのレプリカは、同じテーブル名と同じプライマリキーのスキーマを持っています。アプリケーションによって 1 つのリージョンのローカルテーブルにデータが書き込まれると、データはその LOCAL_QUORUM 整合性レベルを使用して永続的に書き込まれます。Amazon Keyspaces は、データを他のレプリケーションリージョンに自動的に非同期で複製します。リージョン間のレプリケーション遅延は通常 1 秒未満なので、アプリケーションのパフォーマンスやスループットには影響はありません。

データが書き込まれると、LOCAL_ONE/LOCAL_QUORUM 整合性レベルが設定された別のレプリケーションリージョンのマルチリージョンテーブルからデータを読み取ることができます。サポートされる設定の詳細については、「Amazon Keyspaces マルチリージョンレプリケーションの使用に関する注意事項」をご参照ください。

マルチリージョンレプリケーションの競合の解決

Amazon Keyspaces のマルチリージョンレプリケーションはフルマネージド型です。つまり、データ同期の問題をクリーンアップするために定期的に修復オペレーションを実行するなど、レプリケーションタスクを実行する必要はありません。Amazon Keyspaces は、競合を検出して修復 AWS リージョン することで異なる のテーブル間のデータ整合性を監視し、レプリカを自動的に同期します。

Amazon Keyspaces では、最終ライターが勝者となる方法を使用してデータ調整を行います。この競合解決メカニズムでは、マルチリージョンキー空間内のすべてのリージョンが最新の更新を受け入れ、すべてのリージョンで同一のデータが保存される状態に収束します。調整プロセスはアプリケーションのパフォーマンスには影響しません。競合解決をサポートするため、マルチリージョンテーブルではクライアント側のタイムスタンプが自動的にオンになります。オフにすることはできません。詳細については、「Amazon Keyspaces でのクライアント側のタイムスタンプ」を参照してください。

マルチリージョンレプリケーションのディザスタリカバリ

Amazon Keyspaces マルチリージョンレプリケーションでは、書き込みは各リージョンで非同期的にレプリケートされます。まれに、単一リージョンの劣化や障害が発生した場合、マルチリージョンレプリケーションは、アプリケーションにほとんど、またはまったく影響することなく、災害から回復するのに役立ちます。災害からの復旧は通常、目標復旧時間 (RTO) と目標復旧時点 () の値を使用して測定されますRPO。

目標復旧時間 – 災害発生後にシステムが動作状態に戻るのにかかる時間。 RTOは、ワークロードが許容できるダウンタイムの量を時間単位で測定します。マルチリージョンレプリケーションを使用して影響を受けていないリージョンにフェイルオーバーするディザスタリカバリプランの場合、 はほぼゼロRTOになります。RTO は、アプリケーションが障害状態を検出し、トラフィックを別のリージョンにリダイレクトできる速度によって制限されます。

目標復旧時点 - 損失するおそれのあるデータの量 (時間単位)。マルチリージョンレプリケーションを使用して影響を受けていないリージョンにフェイルオーバーするディザスタリカバリプランの場合、 は通常 1 桁の秒RPOです。RPO は、フェイルオーバーターゲットレプリカへのレプリケーションレイテンシーによって制限されます。

Amazon Keyspaces のレプリケーションはアクティブ-アクティブなので、リージョンの障害または機能低下が発生しても、セカンダリリージョンの昇格や、データベースのフェイルオーバー手順の実行は必要ありません。代わりに、Amazon Route 53 で、最も近くにある正常なリージョンにアプリケーションをルーティングできます。Route 53 の詳細については、「Amazon Route 53 とは?」を参照してください。 。

単一の AWS リージョン が分離または低下した場合、アプリケーションは Route 53 を使用してトラフィックを別のリージョンにリダイレクトし、別のレプリカテーブルに対して読み取りと書き込みを実行できます。また、カスタムビジネスロジックを適用すれば、リクエストを他のリージョンにリダイレクトするタイミングを決定できます。一例として、使用可能な複数のエンドポイントをアプリケーションに認識させるケースが考えられます。

リージョンがオンラインに戻ると、Amazon Keyspaces はそのリージョンから他のリージョンのレプリカテーブルへの保留中の書き込みの伝播を再開します。また、他のレプリカテーブルから現在オンラインに戻っているリージョンへの書き込みの伝播も再開します。

マルチリージョンレプリケーションとリカバリと point-in-timeの統合 (PITR）

Point-in-time リカバリは、マルチリージョンテーブルでサポートされています。でマルチリージョンテーブルを正常に復元するにはPITR、次の条件を満たす必要があります。

restore ステートメントは、ソーステーブルが使用可能であれば、どのリージョンからでも実行できます。Amazon Keyspaces は、各リージョンのターゲットテーブルを自動的に復元します。PITR の詳細については、「Amazon Keyspaces point-in-timeでの復旧の仕組み」を参照してください。

マルチリージョンテーブルを作成すると、作成プロセス中に定義したPITR設定が、すべてのリージョンのすべてのテーブルに自動的に適用されます。を使用してPITR設定を変更するとALTER TABLE、Amazon Keyspaces は更新をローカルテーブルにのみ適用し、他のリージョンのレプリカには適用されません。

マルチリージョンレプリケーションと AWS サービスとの統合

Amazon CloudWatch メトリクスを使用して AWS リージョン 、異なる のテーブル間のレプリケーションパフォーマンスをモニタリングできます。次のメトリクスでは、マルチリージョンキー空間を継続的にモニタリングできます。

CloudWatch メトリクスのモニタリング方法の詳細については、「」を参照してくださいAmazon による Amazon Keyspaces のモニタリング CloudWatch。