ディザスタリカバリや最寄りアクセスのために、複数のリージョンやアベイラビリティゾーンにわたってアプリケーションとデータベースをデプロイする際、同時書き込みによって生じるデータ競合の処理が中心的な課題となります。Global Distributed Network (GDN) は、この問題に対処するためのアクティブ/アクティブパターンを提供します。GDN はプライマリインスタンスとセカンダリインスタンス間の双方向のデータ書き込みをサポートしており、これにより 2 拠点でのアクティブ/アクティブデータベースサービスを構築できます。これにより、業務継続性とユーザーアクセス体験が向上します。双方向書き込み時におけるデータ整合性を確保するためには、中核となるデータ定義言語 (DDL) の同期ルールとデータ競合の処理ポリシーを理解し、設定する必要があります。
適用範囲
GDN のアクティブ/アクティブパターンを使用する前に、ご利用のビジネスシナリオと技術アーキテクチャが以下の条件を満たしていることを確認してください。
アーキテクチャの制限：サポートされているのは、1 つのプライマリ、1 つのセカンダリ構成のアクティブ/アクティブアーキテクチャのみです。
DDL 操作の制限：テーブルスキーマの作成や変更など、すべての DDL 操作はプライマリインスタンスで実行する必要があります。セカンダリインスタンスでは DDL 操作を実行しないでください。実行した場合、データ同期エラーが発生します。
DDL 同期ルール
DML 同期：双方向同期。どちらかのインスタンスで実行された
INSERT、UPDATE、DELETEなどのデータ操作言語 (DML) 操作は、もう一方のインスタンスに同期されます。DDL 同期：一方向同期。プライマリインスタンスで実行された
CREATE/ALTER TABLEなどのテーブルスキーマの変更のみが、セカンダリインスタンスに同期されます。プライマリインスタンスは、クラスター全体の構造的な整合性を確保するために、スキーマ進化のための単一のエントリポイントとして機能します。
データ競合の処理ポリシー
データ競合は、プライマリインスタンスとセカンダリインスタンスが、同じ一意キー (UK) に対する書き込みリクエストを同時に受信したときに発生します。アクティブ/アクティブインスタンスを作成する際に、データベースがこれらの競合を自動的に解決する方法を定義する競合処理ポリシーを指定できます。
このポリシーは、INSERT、UPDATE、DELETE などの DML 操作にのみ適用されます。CREATE/ALTER TABLE などの DDL 操作は、引き続き一方向同期のルールに従います。
競合ポリシー | 説明 | シナリオ |
INTERRUPT (同期の中断) | 一意キーの競合が発生した場合、データ同期は直ちに停止し、手動介入を待ちます。 | 金融取引システムなど、極めて高いデータ整合性と競合の正確な監査が求められるサービス向け。 |
IGNORE (競合の無視) | 一意キーの競合が発生した場合、ソースインスタンスからの書き込み操作は無視され、宛先インスタンスの既存データが保持されます。 | ログレコードなど、軽微なデータの不一致を許容できる非コアサービス向け。 |
OVERWRITE (競合の上書き) | 一意キーの競合が発生した場合、ソースインスタンスのデータが宛先インスタンスの既存データを上書きします。 | ユーザーステータスの更新やキャッシュプリフェッチなど、最新の書き込みレコードを保持する必要があるサービス向け。 |
DIRECT_OVERWRITE (強制上書き) | このポリシーは | データ修正や注文ステータスの同期など、データの強制的な統一が必要なシナリオ向け。 |
ベストプラクティスの推奨事項
INTERRUPT (同期の中断)：包括的な監視およびアラートシステムを使用して、同期が停止した場合に迅速に通知を受け取り、対応できるようにしてください。
OVERWRITE (競合の上書き)/DIRECT_OVERWRITE (強制上書き)：上書き操作が予期せぬ結果を引き起こすのを防ぐため、ビジネスロジックレイヤーでべき等設計を実装してください。
IGNORE (競合の無視)：このポリシーを使用する前に、ご利用のサービスがデータ損失をどの程度許容できるかを慎重に評価してください。このポリシーは、非コアサービスのテーブルにのみ使用してください。