製造業の大手企業が、AWS上のEC2インスタンス（r5.8xlarge）でセルフマネージドPostgreSQL 13データベースを運用しています。データベースの総サイズは8TBで、そのうち直近2TBがアクティブなデータです。現在の課題は次のとおりです。 ①pg_dumpによるバックアップが6時間かかりI/O競合を発生させている ②フェイルオーバーは手動で20〜30分を要する ③リードレプリカは手動管理でピーク時にレプリカラグが増大する ④スキーマ変更に4時間のメンテナンスウィンドウが必要 ⑤製品カタログ（1,000万アイテム）の全文検索機能の追加が要求されている 定められたSLAはRTO5分・RPO1分です。マネージドサービスへの移行によってすべての課題を解決するアーキテクチャとして最も適切なものはどれですか？
選択肢AのAmazon Aurora PostgreSQLはRDS for PostgreSQLと比較してフェイルオーバー時間が大幅に短く（通常30秒以内）、RTO5分の要件を満たします。Auroraのストレージ層はクラスターボリュームとしてI/Oを最適化しており、バックアップはストレージレイヤーで継続的なインクリメンタル形式で自動実行されます。pg_dumpで6時間かかっていたバックアップはストレージ側で処理されるためアプリケーションのI/O競合が発生せず、AWS BackupのポイントインタイムリカバリによりRPO1分を達成できます。 Aurora Auto Scalingはリクエスト数・CPU使用率に応じてリードレプリカを自動的に追加・削除するため、ピーク時のレプリカラグ問題が解消されます。AuroraのBlue/Greenデプロイメント機能を活用することで、本番トラフィックを維持したままスキーマ変更をステージング環境で実施・検証してから低ダウンタイムで切り替えられるため、4時間のメンテナンスウィンドウを大幅に短縮できます。全文検索についてはAmazon OpenSearch Serviceが1,000万件規模の製品カタログに対する高性能な全文検索・ファセット検索を提供します。Kinesis Data Streams→Lambda→OpenSearchの非同期インデックス同期パイプラインにより、Aurora本体への負荷なしにほぼリアルタイムで検索インデックスを更新できます。 選択肢BのRDS PostgreSQL Multi-AZのデフォルトRPOはトランザクションログ転送間隔の関係で約5分であり、RPO1分の厳格なSLAを満たせない。またCloudSearchはOpenSearchに比べてスケーラビリティ・機能・AWSエコシステム統合が劣る。 選択肢CのEC2リフト&シフトでは手動フェイルオーバー・バックアップI/O競合・手動レプリカ管理という既存課題がAWS移行後も継続し、RTO5分・RPO1分のSLAも達成できない。 選択肢DのAurora Serverless v2は使用パターンが予測困難なワークロードに適しており、8TBの安定した製造業ERPにはプロビジョンドAuroraが適切。KendraはNLPベースのエンタープライズドキュメント検索向けであり、構造化製品カタログの高速全文検索にはOpenSearchがより適している。