大規模な SaaS 企業が、マルチテナント型 SaaS アプリケーションのパフォーマンス問題を調査しています。現在の構成は以下の通りです。 ①フロントエンド：CloudFront + ALB + ECS Fargate（Auto Scaling）。 ②バックエンド API：API Gateway + Lambda（Node.js）。 ③データベース：Amazon Aurora MySQL（マルチ AZ）プロビジョニング済みクラスター、r6g.4xlarge（プライマリ 1 台、リーダー 2 台）。 ④キャッシュ：ElastiCache Redis クラスター。監視データから以下の問題が判明しました。 ①特定のテナント（全体の 5%）が全クエリの 70% を発行している（ノイジーネイバー問題）。 ②Aurora のバッファプールヒット率が 65% まで低下している（正常値 95%以上）。 ③Lambda のコールドスタートが p99 レイテンシーを 8 秒まで押し上げている。 ④データベース接続数が上限（max_connections）に達している（Fargate コンテナが直接接続）。 ⑤月次バッチ処理（全テナントのレポート生成）が本番トラフィックに影響を与えている。これらの問題を解決するための優先度の高い改善策はどれですか？（2つ選択）
RDS Proxy は Lambda のような短命なコンピューティングリソースが多数の DB 接続を生成する問題（接続枯渇）を解決する最重要対策です。Lambda の Provisioned Concurrency はコールドスタートの p99 レイテンシーを劇的に改善します。API Gateway の使用量プランによるテナントスロットリングはノイジーネイバー問題への即効性が高い対策です。Aurora Serverless v2 はバッファプール問題よりも柔軟なスケーリングに有効で、ElastiCache Query Cache との組み合わせでヒット率改善が期待できます。 選択肢Aはmax_connections パラメータの増加には物理的な上限があり、Lambda が大量にスポーン（spawn：並列起動）されると各インスタンスが個別に DB 接続を消費するため根本解決になりません。上位 5% テナントの専用クラスター移行は運用コストと複雑さが著しく増加し即効性に欠けます。 選択肢DはAurora クローンによるスナップショット環境の構築はリーダーエンドポイント活用より複雑・高コストで、接続枯渇やコールドスタートなど他の重要問題への対策が含まれていません。選択肢Cが提供する Provisioned Concurrency によるコールドスタート解消と ElastiCache によるバッファプールヒット率改善が欠けています。