フィンテック企業が、Amazon EC2インスタンス（c5.4xlarge × 20台、Application Load Balancer配下）とAmazon RDS for MySQL（db.r5.8xlarge、Multi-AZ構成）を使用してリアルタイム決済処理システムを運用しています。データベースのサイズは8TBで、ピーク時には毎秒5,000トランザクションを処理しています。過去6ヶ月間で以下のパフォーマンス問題が深刻化しています。ピーク時の平均クエリ応答時間が10msから450msに悪化し、RDSインスタンスのCPU使用率がピーク時に常時95%に達しています。また、既存のリードレプリカのレプリケーション遅延が常時30秒を超えており、実質的に利用不可能な状態です。アプリケーションの整合性要件として、決済バリデーションクエリはコミット済みの最新データを読む必要があり（強い整合性が必須）、レポーティング・分析クエリは最大100msの遅延であれば許容されます。アプリケーション開発チームはコード変更を最小限にとどめたいと述べており、接続先エンドポイントの変更やキャッシュ呼び出しの追加程度は許容されますが、データモデルの再設計や大規模なアプリケーション書き換えは困難です。コスト増加は許容されますが、可能な限り抑制したいと考えています。Solutionsアーキテクトが推奨すべきソリューションはどれですか？
Aurora MySQLのストレージ共有型のクォーラムベースレプリケーションにより通常100ms未満のレプリカ遅延を実現し、レポーティングの100ms要件を確実に満たします。ライターエンドポイントによる決済バリデーションは強い整合性を保証し、ElastiCacheで繰り返しレポートクエリをキャッシュすることでAurora負荷をさらに削減できます。接続エンドポイントの変更とキャッシュ呼び出し追加のみでアプリケーション変更を最小化できます。 選択肢Bはスケールアップで一時的改善は可能ですが標準MySQLのバイナリログレプリケーション遅延問題は解決せず、ライトスルーキャッシュ全適用は決済バリデーションの強い整合性要件に反します。 選択肢CのGlobal Databaseはリージョン間レプリケーション遅延（通常1秒以下だが状況により数秒超）が100ms要件を超えるリスクがあり過剰設計です。 選択肢DのDynamoDB移行はシングルテーブル設計へのデータモデル再設計が必須であり、コード変更最小の要件に根本的に違反します。