プロビジョンドAurora MySQLクラスターにwriterと少なくとも1台のreaderがあり、すべて利用可能である。読み取り需要が変動するため、readerの平均CPUを目標50%へ近づけ、reader数を1〜5台の範囲で増減したい。
アプリは書き込みをwriterへ、読み取りの新規接続をreader endpointへ送る。新しいreaderへ接続でき、Auto Scalingの必要な権限とcooldownも準備する。各クエリを別readerへ自動移動することは求めない。
最も適切な構成はどれか。
Aurora Auto Scalingでreader数を容量範囲内で調整し、reader endpointで新規読み取り接続を分散する。
詳細解説
readerがないとreader平均CPUのメトリクスを評価できない。少なくとも1台のreaderを維持する前提が必要となる。
reader endpointは接続を分散するが、readerを作成・削除するスケーリングポリシーの代わりにはならない。
このAuto Scalingはreader数を調整する機能であり、writerのサイズ変更を行わない。readerの平均CPUという判断軸とも異なる。
reader数を負荷に応じて調整し、reader endpointで新規接続を分散できる。writerサイズの自動調整ではない。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料で保存・接続・スケーリングの範囲と前提を確認する。
参考にした公式資料
確認できる内容
誤答の運用上の限界と、設定後にアプリで確認する内容を説明できる。
理解のポイント
- Aurora Auto Scaling
- Aurora Replicas
- Reader endpoint
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
reader数を調整する範囲と前提
Aurora Auto Scalingはwriterの負荷を対象にせず、readerを増減する。reader平均CPUは手動作成したreaderも含め、writerを除いて評価する。少なくとも1台のreader、利用可能なクラスター、容量範囲、scale-in、cooldownを確認する。自動削除の対象はAuto Scalingが作成したreaderであり、手動作成したreaderではない。追加には準備時間があり、目標CPUの常時一致を保証しない。
reader endpointは接続単位で分散する
reader endpointは利用可能なreaderへ新規接続を分散し、同じ接続内の各クエリを別readerへ自動振り分けしない。既存の長時間接続や接続プールがある場合は、新規readerへの接続を取り込めるよう管理する。readerが1台もないクラスターではwriterへ接続するため、endpoint名だけで読み取り専用性が保証されるとはみなさない。