AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
- はい。キャッシュノードに障害が発生すると RDS インスタンスが負荷を処理しきれなくなるため、2 つの Memcached ElastiCache クラスターを異なる AZ にデプロイする必要があります。
- いいえ。キャッシュノードに障害が発生した場合でも、可用性に影響を与えることなく DB から常に同じデータを取得できます。
- いいえ。キャッシュノードに障害が発生しても、ElastiCache のノード自動復旧機能により可用性への影響は回避されます。
- はい。1 つのキャッシュノードに障害が発生しても負荷を処理できるよう、RDS のマスターインスタンスと同じ AZ に 2 ノード構成の Memcached ElastiCache クラスターをデプロイする必要があります。
A. はい。キャッシュノードに障害が発生すると RDS インスタンスが負荷を処理しきれなくなるため、2 つの Memcached ElastiCache クラスターを異なる AZ にデプロイする必要があります。
DB はすでに CPU 80% 超で、読み取りの多くをキャッシュが肩代わりしている状態。Memcached はノード間でデータをレプリケーションしないため、単一ノードが失われるとキャッシュヒットが一気にゼロになり、その読み取りが丸ごと RDS に流れ込んで処理しきれなくなる。
さらにワークロードが 30% 増える前提であり、キャッシュ層の可用性確保は必須。キャッシュを複数の AZ に分散して配置すれば、1 つの AZ／ノードが失われても残りがキャッシュを提供し続け、DB への流入を部分的に抑えられる。
選択肢の中で唯一、「キャッシュの単一障害点」と「AZ 障害」の両方に手を打っているため正解。
B. いいえ。キャッシュノードに障害が発生した場合でも、可用性に影響を与えることなく DB から常に同じデータを取得できます。
「DB から同じデータを取得できる」こと自体は事実だが、それはデータの正しさの話であって、可用性・性能の話ではない。
本問の DB はすでに CPU 80% 超で、しかも I/O の 90% が読み取り。キャッシュが失われればその読み取りが DB に集中し、30% の負荷増も相まって応答遅延やタイムアウト＝実質的なサービス断を招く。
「変更不要」と判断する根拠にはならない。
C. いいえ。キャッシュノードに障害が発生しても、ElastiCache のノード自動復旧機能により可用性への影響は回避されます。
ElastiCache は障害ノードを検知して置き換えるが、Memcached には永続化もレプリケーションも無いため、置き換わったノードのキャッシュは空（コールドキャッシュ）になる。
ノードが復旧してキャッシュが再び温まるまでの間、読み取りはすべて RDS に向かい、まさにその時間帯に DB が過負荷になる。
「自動復旧があるから大丈夫」は、キャッシュのデータそのものが失われるという Memcached の性質を見落とした誤り。
D. はい。1 つのキャッシュノードに障害が発生しても負荷を処理できるよう、RDS のマスターインスタンスと同じ AZ に 2 ノード構成の Memcached ElastiCache クラスターをデプロイする必要があります。
2 ノードにしてキャッシュ容量と分散性を上げる方向性は悪くないが、両ノードを RDS マスターと同じ 1 つの AZ に集約している点が誤り。
その AZ に障害が起きるとキャッシュが全滅し、残った AZ の Web／アプリケーションサーバーはキャッシュなしで DB を叩くことになる。アプリ層・DB 層をマルチ AZ にしている設計思想とも矛盾する。
高可用性を維持するにはキャッシュも AZ をまたいで分散する必要がある。
Memcached はレプリケーションしない。ノードが落ちればキャッシュは空、その負荷は全部 DB に降ってくる。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| DB の CPU 使用率が常時 80% 超・ワークロードは 30% 増の見込み | DB にはもう余力がない。キャッシュが失われた瞬間に読み取りが流れ込めば処理しきれない＝「変更不要」はあり得ない →選択肢（B・C）を消す |
| DB の I/O の 90% が読み取り | 読み取りをキャッシュが肩代わりしている＝キャッシュ層の可用性がそのまま DB の生死を左右する →選択肢（A・D）は候補 |
| キャッシュが単一ノードの Memcached | Memcached はレプリケーション・永続化を行わないため、ノード障害＝キャッシュ全消失。自動復旧してもキャッシュは空 →選択肢（C）を消す |
| アプリ層・DB 層は 2 つの AZ で高可用性を確保している | キャッシュだけ単一 AZ／単一ノードでは設計の一貫性が崩れる。AZ をまたいで冗長化する案を選ぶ →選択肢（D）を消す／選択肢（A）が正解 |
ひっかけポイント
- 「キャッシュが落ちても DB から取れるから問題ない」（選択肢 B）はデータの整合性の話にすり替えたひっかけ。問われているのはDB が捌けるかどうかで、CPU 80% 超という数字が答えを決めている
- 「ElastiCache のノード自動復旧」（選択肢 C）は実在する動作だが、Memcached では復旧したノードのキャッシュは空。Redis のレプリケーション／自動フェイルオーバーと混同させる罠
- 選択肢 D は「2 ノードに増やす」で正しそうに見えるが、配置先が単一 AZ（RDS マスターと同じ AZ）。「ノード数」ではなく「どの AZ に置くか」が高可用性の分かれ目
- 本来の理想解は「リードレプリカで読み取りをオフロードする」だが、選択肢に無いものは選べない。与えられた選択肢の中で要件（HA ＋ 負荷増）を最も満たすものを選ぶ
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「キャッシュにフェイルオーバーと永続化が必要」 | Redis（レプリケーショングループ＋マルチ AZ 自動フェイルオーバー）が正解軸に。Memcached では実現できない。 |
| 「読み取り負荷そのものを根本的に減らしたい」 | RDS リードレプリカを追加し、参照クエリを振り分ける構成が正解軸に。 |
| 「書き込みがボトルネックになっている」 | インスタンスのスケールアップ、シャーディング、Aurora への移行が正解軸に（キャッシュでもリードレプリカでも解決しない）。 |
| 「Web サーバーのセッション情報を共有したい」 | Redis や DynamoDB によるセッションストア外出しが問われる（Memcached の単一ノードは消失リスクあり）。 |
| 「マルチ AZ RDS があるので読み取りをスタンバイに逃がしたい」 | 誤り。マルチ AZ のスタンバイは読み取りに使えない（Multi-AZ DB クラスターやリードレプリカが必要）という論点で問われる。 |
- はい。キャッシュノードに障害が発生すると RDS インスタンスが負荷を処理しきれなくなるため、2 つの Memcached ElastiCache クラスターを異なる AZ にデプロイする必要があります。
- いいえ。キャッシュノードに障害が発生した場合でも、可用性に影響を与えることなく DB から常に同じデータを取得できます。
- いいえ。キャッシュノードに障害が発生しても、ElastiCache のノード自動復旧機能により可用性への影響は回避されます。
- はい。1 つのキャッシュノードに障害が発生しても負荷を処理できるよう、RDS のマスターインスタンスと同じ AZ に 2 ノード構成の Memcached ElastiCache クラスターをデプロイする必要があります。