無限ノック › SAP 練習問題一覧 › 問題SAP 既存のソリューションの継続的改善
フィンテック企業がAmazon Aurora PostgreSQL（1ライター・3リーダー、db.r6g.4xlarge）でオンライン決済処理を運用しています。
各アプリサーバー（20台）が独自のPgBouncerプールを保有し合計接続数が8,000本を超え「too many connections」エラーが頻発しています。
平日ピーク時にはライターのCPU使用率が95%に達し、データ量が500GBから3TBに増加したことでレポーティングクエリのレイテンシが300%悪化しています。
アプリケーションコードの変更なし・
RPO 15分・
RTO 30分の既存SLAを維持したまま、パフォーマンスを改善する最適な方法を選択してください。
A Amazon RDS ProxyでPgBouncerを置き換えて接続多重化を実現し（接続先を設定変更のみで移行）、Aurora Auto ScalingでCPU 70%閾値によるリーダーレプリカを自動追加、レポーティング用接続をRDS Proxyリーダーエンドポイントへ設定変更、Performance Insightsで上位SQLを特定・最適化し、既存Auroraバックアップ機能でRPO/RTOを維持する。
✓ 正解
RDS Proxyの接続多重化でPgBouncer分散問題を解消し、Aurora Auto ScalingとRDS Proxyリーダーエンドポイントの組み合わせでライターCPUボトルネックとレポーティング遅延を同時解決できます。コード変更不要かつ既存AuroraバックアップでRPO/RTOを維持するため、すべての制約を満たす最適解です。
B ライターインスタンスをdb.r6g.16xlargeへアップグレードしてCPUを直接解消、全アプリのPgBouncerをNLB配下の集中コネクションフリートに統合してコネクション数を管理、Auroraバックトラックを24時間ウィンドウで有効化してRPO要件を達成し、Auroraリーダーエンドポイントをレポーティング専用に割り当てる。
Aurora PostgreSQLはバックトラック機能に対応していないため（Aurora MySQL専用機能）、バックトラックによるRPO達成は不可能です。
インスタンスアップグレードは即効性があるものの根本的な接続数問題は解消されず、
NLBフリートによるPgBouncer集約は追加管理コストが発生します。
C Aurora Serverless v2へ移行して0.5〜128 ACUで自動スケーリングしCPUピークを吸収、RDS Proxyで全コネクションを集約、レポーティングをリーダーエンドポイントへ向けるためアプリケーションコード内の接続先を修正し、Aurora Global Databaseをセカンダリリージョンに構築してRPO/RTOを確実に達成する。
Aurora Serverless v2自体は有効な改善策ですが、アプリケーションコード内の接続先を修正する操作はコード変更に該当し「コード変更なし」の制約に違反します。
Aurora Global Databaseは要件を超えた過剰なDR強化であり不適切です。
D レポーティングワークロードをAmazon Redshift RA3クラスターへ移行してAWS DMSで継続レプリケーションを設定し、OLTP処理はAuroraに残してAmazon RDS Proxyで接続管理を集約、AWS BackupでクロスリージョンバックアップからRPO/RTOを満たしつつライターCPU負荷を分散する。
レポーティングをRedshiftへ移行することは既存ソリューションの大規模再設計を意味し継続的改善の範囲を超えます。
DMSによるAurora→Redshiftの継続レプリケーションはレイテンシを伴いリアルタイム性が保証されず、移行コストも多大になります。
解説 RDS ProxyはAurora PostgreSQLに対して接続多重化（connection multiplexing）を提供し、20台のアプリサーバーが持つ分散したPgBouncerプールを一元化することで8,000本超の接続問題を根本解決できます。RDS Proxyへの移行はPgBouncerのホスト設定変更のみで実現でき、アプリケーションコードの変更は不要です。
Aurora Auto Scalingはリーダーレプリカ数をCPU使用率に基づいて動的に追加し、3TBへ増大したデータへのレポーティング負荷をスケールアウトで吸収します。RDS Proxyのリーダーエンドポイントへレポーティング接続先を設定変更することでライターへの読み取り負荷も軽減されます。Performance Insightsは上位SQL・待機イベントを可視化し継続的なクエリ最適化を支援します。AuroraのPITR（1分間隔）はRPO 15分を、リーダーへの自動フェイルオーバーはRTO 30分以内を満たします。
選択肢BのAuroraバックトラックはAurora MySQL専用機能であり、Aurora PostgreSQLでは使用できません。NLB配下のPgBouncerフリートは管理複雑度とコストが増大します。
選択肢CのAurora Serverless v2は有効ですが、「アプリケーションコード内の接続先を修正」はコード変更に該当し「コード変更なし」の制約に違反します。Aurora Global Databaseは現行SLAを超える過剰なDR設計です。
選択肢DのRedshiftへの移行は大規模なアーキテクチャ変更を伴い既存ソリューションの継続改善の範囲を超えます。DMSによる継続レプリケーションはレイテンシを伴い整合性管理が複雑になります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →