グローバルに展開する金融サービス企業が、ミッションクリティカルな株式取引プラットフォームを運用しています。現在のデータベース構成は以下の通りです。 ・プライマリDB: Amazon RDS for MySQL（db.r6g.16xlarge、Multi-AZ構成）— us-east-1 リージョン ・クロスリージョン読み取りレプリカ: ap-northeast-1（東京）および eu-west-1（アイルランド） ・各リージョンに Amazon RDS Proxy を配置し、コネクションプーリングを実施 NYSE（ニューヨーク証券取引所）の取引時間帯（日本時間 22:30〜05:00）において、以下の問題が継続的に発生しています。 ・ap-northeast-1 読み取りレプリカのレプリケーション遅延: 45〜90 秒 ・eu-west-1 読み取りレプリカのレプリケーション遅延: 60〜120 秒 ・東京とダブリンのトレーダーが古いポートフォリオ評価額を参照するインシデントが頻発 ・プライマリリージョン障害時の手動フェイルオーバーに 15〜30 分を要する 経営層から承認された新要件は以下の通りです。 ・全リージョンへのレプリケーション遅延: 通常運用時 1 秒以内 ・プライマリリージョン完全障害時の RTO（目標復旧時間）: 60 秒以内 ・RPO（目標復旧時点）: ゼロに近いこと（コミット済みトランザクションの損失禁止） ・書き込み操作は us-east-1 のみに限定すること（金融規制上の要件） ・RDS Proxy の統合を維持するか、アプリケーション変更を最小限に抑えた形で移行すること ・現行の RDS コストに対するインフラコスト増加率: 25% 以内 上記すべての要件を最も適切に満たすソリューションはどれですか？
選択肢AのAurora Global Databaseは専用のレプリケーションインフラを使用し、通常1秒未満のクロスリージョン遅延を実現します。プライマリリージョン完全障害時はセカンダリクラスターをデタッチして昇格させるフェイルオーバー操作によりRTO 60秒以内の達成が可能です（「マネージドプランドフェイルオーバー」は計画的な切り替え専用の別機能です）。MySQL互換のためRDS Proxy統合を維持でき、コスト増加も25%以内に収まります。 選択肢BのElastiCacheキャッシュはTTL 30秒によりデータ鮮度を保証できずRPO要件を満たしません。 選択肢CのRDS MySQLからのbinlogによるクロスリージョンレプリケーションでは1秒以内の遅延達成は構造的に困難です。 選択肢DのDynamoDB Global Tablesはマルチアクティブレプリケーション（全リージョンからの書き込みを許可する設計）であるため、書き込みをus-east-1のみに限定するという金融規制要件に根本的に違反します。加えてリレーショナル→NoSQLへの抜本的なアプリ改修も必要であり現実的ではありません。