AWS認定資格 WEB問題集＆徹底解説

ソリューションアーキテクト – アソシエイト

正解 B問題
要復習（もう一度解きたい問題） 1 2 3 4
次の問題前の問題
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある企業はウェブアプリケーションをAWS上でホストしています。このアプリケーションは、Amazon EC2インスタンスのオートスケーリンググループで実行されており、データはAmazon RDSデータベースで管理されています。最近、アプリケーションのパフォーマンスが低下し、ユーザーは遅延を報告しています。調査の結果、参照系クエリ（読み取りトラフィック）が増加してDBインスタンスのCPU使用率が上限に達していることが判明しました。読み取りクエリは検索条件が多岐にわたり同一クエリの繰り返しが少ないため、キャッシュによるヒット率は期待できません。書き込み性能は十分であり、今後もアクセス増加が見込まれます。読み取りパフォーマンスをスケーラブルに向上させる最適な方法はどれでしょうか。
  • RDSインスタンスのタイプをより大きなサイズにスケールアップする。
  • Amazon RDSリードレプリカを作成し、読み取りトラフィックをオフロードする。
  • Amazon ElastiCacheを導入し、頻繁にアクセスされるデータをキャッシュする。
  • マルチAZ配置を有効にして、高可用性を確保する。
解説 頻出度★★★★★
この問題は、「RDS の読み取り負荷増 × キャッシュが効かない × 将来も増える」の要件で、リードレプリカによる読み取りの水平スケールを選べるかがポイント

A. RDSインスタンスのタイプをより大きなサイズにスケールアップする。

インスタンスタイプのスケールアップ（垂直スケール）でも一時的に CPU の余裕は生まれるが、1台の上限に到達すればそこで打ち止めとなり、今後も増え続けるアクセスに対してスケーラブルではない。
スケールアップには再起動を伴うダウンタイムやコスト増も付随するため、読み取り専用トラフィックの受け皿としては最適ではない。

正解

B. Amazon RDSリードレプリカを作成し、読み取りトラフィックをオフロードする。

Amazon RDS リードレプリカは、プライマリからの非同期レプリケーションで読み取り専用のコピーを作る機能。アプリの参照系クエリをレプリカ側へ向けることで、プライマリの CPU 負荷を下げつつ読み取りを水平にスケールできる。本問は「書き込み性能は十分」と明記されており、まさに読み取りだけを逃がせばよい状況。
レプリカは後から追加できる（RDS for MySQL / MariaDB / PostgreSQL なら1つのソースにつき最大15台）ため、今後のアクセス増にもレプリカを足して対応でき、単一インスタンスの上限に縛られない。キャッシュのヒット率に依存しない点でも本要件に最も合致する。

C. Amazon ElastiCacheを導入し、頻繁にアクセスされるデータをキャッシュする。

Amazon ElastiCache は、同じデータが繰り返し読まれる場合に絶大な効果を発揮する。しかし本問では「検索条件が多岐にわたり同一クエリの繰り返しが少なく、キャッシュのヒット率が期待できない」と明記されており、DB の負荷はほとんど下がらない。
キャッシュの導入・無効化ロジックというアプリ改修コストに見合う効果が得られないため不適。

D. マルチAZ配置を有効にして、高可用性を確保する。

マルチAZ 配置は、スタンバイへの同期レプリケーションによる高可用性・障害時の自動フェイルオーバーのための機能。
スタンバイインスタンスは（RDS の標準的なマルチAZ 構成では）読み取りに使えないため、読み取り性能の向上には寄与しない。可用性と性能の要件を混同させる典型的なひっかけ。

これだけ覚える（記憶フック）
読み取りが重い＝リードレプリカ。マルチAZ は可用性であって性能ではない。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
読み取りトラフィックの増加でDBのCPUが上限に達している 読み取りを別のインスタンスへ逃がすのが定石。書き込みは問題ないと明記されている
→選択肢（B）は候補
同一クエリの繰り返しが少なくキャッシュのヒット率が期待できない ElastiCache の前提（同じ読み取りの繰り返し）が崩れているため効果が出ない
→選択肢（C）を消す
今後もアクセス増加が見込まれる／スケーラブルに スケールアップは単一インスタンスの上限で頭打ち。レプリカ追加なら水平に伸ばせる
→選択肢（A）を消す
求められているのは「読み取りパフォーマンス」 マルチAZ は可用性のための機能で、スタンバイは読み取りに使えない
→選択肢（D）を消す
ひっかけポイント
  • マルチAZ とリードレプリカの混同が最頻出。マルチAZ＝可用性、リードレプリカ＝読み取り性能と即答できるようにする
  • スケールアップは「とりあえず効く」ため魅力的に見えるが、将来の増加に対してスケールしない点で選ばれない
  • ElastiCache は万能ではない。キャッシュヒット率が見込めるかという前提条件を問題文から必ず確認する
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「同じ商品情報が何度も参照される／セッション情報を高速に読みたい」 ElastiCache（キャッシュ）が正解軸に変わる。
「書き込みが集中して DB がボトルネックになっている」 スケールアップ、シャーディング、SQS でのバッファリングや Aurora/DynamoDB への移行が正解軸に。
「DB のダウンタイムを最小化し、AZ 障害に耐えたい」 マルチAZ 配置が正解に浮上する。
「グローバルに低レイテンシで参照させたい」 Aurora グローバルデータベースやクロスリージョンリードレプリカが登場する。
関連サービスの解説 Amazon EC2
Amazon EC2 Auto Scaling
Amazon RDS
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
リードレプリカによる読み取りスケーリングと台数上限 DB インスタンスのリードレプリカの操作
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 69%
No.12 解説
ある企業はウェブアプリケーションをAWS上でホストしています。このアプリケーションは、Amazon EC2インスタンスのオートスケーリンググループで実行されており、データはAmazon RDSデータベースで管理されています。最近、アプリケーションのパフォーマンスが低下し、ユーザーは遅延を報告しています。調査の結果、参照系クエリ（読み取りトラフィック）が増加してDBインスタンスのCPU使用率が上限に達していることが判明しました。読み取りクエリは検索条件が多岐にわたり同一クエリの繰り返しが少ないため、キャッシュによるヒット率は期待できません。書き込み性能は十分であり、今後もアクセス増加が見込まれます。読み取りパフォーマンスをスケーラブルに向上させる最適な方法はどれでしょうか。
  • RDSインスタンスのタイプをより大きなサイズにスケールアップする。
  • Amazon RDSリードレプリカを作成し、読み取りトラフィックをオフロードする。
  • Amazon ElastiCacheを導入し、頻繁にアクセスされるデータをキャッシュする。
  • マルチAZ配置を有効にして、高可用性を確保する。

次の問題前の問題


(会員限定)当問題の評価をお願いします。改善に活用します。
広告

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報