SOA信頼性とビジネス継続性複数選択
Amazon RDS for MySQL（Multi-AZ有効）を本番環境で運用している。RDS Performance Insightsの分析でSELECTクエリのI/O待ちがピーク時の主因と判明し、同時接続数もMax Connectionsの80%に達してエラーが散発している。書き込みは全体の20%未満。既存のMulti-AZ構成を変えずに読み取り負荷の分散と接続数の削減を同時に実現する方法を2つ選べ。
ARDS Read Replicaを作成し、アプリケーションのSELECT接続先をリードエンドポイントへ変更する
✓ 正解
RDS Read ReplicaはSELECTクエリを非同期レプリカに分散し、プライマリのI/O負荷と接続集中を軽減できる。
BRDS Proxyを導入してコネクションプールを管理し、DBへの実接続数を削減する
✓ 正解
RDS ProxyはアプリとDB間でコネクションプールを管理し、DBへの実接続数を大幅に削減してエラーを防止できる。
CMulti-AZ DB Cluster（3ノード）に切り替えて、スタンバイインスタンスからも読み取りをオフロードする
Multi-AZ DB Clusterへの切り替えは既存のMulti-AZ構成を変更することになり、「構成を変えず」という条件に違反する。
DElastiCache for Redisをフロントエンドに配置し、頻繁なSELECTクエリの結果をキャッシュで返す
ElastiCache for Redisはキャッシュ層の追加でアプリ改修が必要であり、DB同時接続数の増加問題そのものを根本解決しない。
ECloudWatchのDatabaseConnectionsにアラームを設定し、閾値超過時にEventBridgeでRDSを自動再起動するルールを作成する
RDSの自動再起動はフェイルオーバーを引き起こしてダウンタイムが発生し、読み取り分散や接続管理の解決策にならない。
解説
Read ReplicaはSELECTを非同期レプリカに分散してプライマリのI/O負荷を軽減し、RDS ProxyはコネクションプールでDB実接続数を削減する。既存のMulti-AZ構成を変更せず2つの課題を同時解決できる。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →