ReplicaによるRead Scaling

答え：B

Aはプライマリ自体の処理能力を増やせますが、読み取り負荷を別の処理先へ分離しません。Cは繰り返される同一結果には有効ですが、多様なレポートクエリすべてをキャッシュできるとは限りません。Dはレポート処理を分離できますが、数秒程度の古さという鮮度要件には適しません。要件では、

読み取り中心
+
書き込み負荷は低い
+
多少の古さを許容
+
読み取り負荷をプライマリから分離

できるため、リードレプリカへ読み取りを振り分ける方法が最も適切です。

答え：C

リードレプリカは非同期で更新されるため、更新直後に古い値を返す可能性があります。したがって、

最新値必須
→ ライター

古さ許容
→ リードレプリカ

と読み取り要件を分けます。

答え：A

Bはプライマリ自体の処理能力を増やせますが、既に作成したリードレプリカへ読み取り負荷を分散しません。Cもレプリカ容量自体は増やしますが、読み取り接続がプライマリへ向いたままなので追加レプリカを活用できません。Dは接続管理を効率化できますが、読み取りトラフィックの振り分け先自体は変わりません。

書き込み用接続
→ プライマリ

読み取り用接続
→ リードレプリカ

という経路分離が必要です。

答え：D

リーダーエンドポイントは、利用可能なAurora Replicaへ読み取り接続を分散できます。そのため、アプリケーション側で各Aurora Replicaのエンドポイントを個別管理する必要を減らせます。

答え：B

Auroraのリーダーエンドポイントは、

接続

を分散します。個別のクエリを毎回別レプリカへ振り分ける仕組みではありません。したがって、長時間維持される接続の使い方も読み取り分散へ影響します。

答え：C

RDSのリードレプリカでは、ReplicaLagを使用してソースDBインスタンスからのレプリケーション遅延を監視できます。具体的な計算方法はデータベースエンジンによって異なるため、利用エンジンの定義も確認します。

答え：A

Aurora Replicaでは、AuroraReplicaLagを使用してライターからの更新反映の遅れを確認できます。

答え：D

A、B、Cはいずれも読み取り負荷を減らす方向の対策です。しかしこのシナリオでは、

負荷の大部分
=
INSERT / UPDATE

なので、読み取りをさらに減らしても主なボトルネックは残ります。リードレプリカは読み取りスケーリングの手段であり、書き込み側の処理能力や設計を別途評価する必要があります。

答え：C

Aも実際の利用量へ合わせた自動調整が可能な有力な方式ですが、

最小キャパシティ
最大キャパシティ
目標使用率

などの設定を管理します。Bはピーク負荷へ対応できますが、負荷が小さい時間帯も事前確保したキャパシティを維持します。Dは反復読み取りの高速化・負荷削減には有効ですが、すべての読み取りがキャッシュヒットするわけではなく、テーブル本体のスループット管理方式そのものを置き換えません。この問題では、

新規ワークロード
+
予測困難なトラフィック
+
大きな変動
+
キャパシティ管理を減らしたい

ことから、オンデマンドキャパシティモードが最も適切です。