2026-09-03（木）復習週＋模試1
1. 【頻出ひっかけパターンTOP5】
ひっかけ①：「Webアプリケーションの参照（SELECT）クエリが集中してデータベース（RDS MySQL）が過負荷でスローダウンしたため、システムの応答性能を高速化・改善する目的で、RDSのコンソール設定から『マルチAZ（Multi-AZ）配置』を有効化して本番デプロイする。」
- 真実: データベースの応答遅延（ボトルネック）は改善されず、むしろ書き込み性能が若干低下します [p.131]。
- 理由: RDSの マルチAZ は、高可用性（耐障害性）の確保を目的とした「アクティブ・スタンバイ（同期複製）」構成です [p.131]。スタンバイ側のDBはパッシブ（待機状態）で眠っているため、クエリ（SQL）を処理することはできません [p.131, p.132]。また、マスターとスタンバイ間でデータを「同期コピー（同時書き込み）」するため、書き込み時のトランザクションオーバーヘッドは逆にわずかに増加します [p.131]。
- 対策: 読み込みクエリの処理能力をスケールアウトさせたい（参照負荷分散）という要件に対しては、必ず 「 リードレプリカ（非同期複製） 」 を作成し、アプリケーションの参照先をレプリカ側へルーティングさせる設計が絶対的な正解です [p.132]。
ひっかけ②：「Amazon Auroraクラスターにおいて、プライマリ（書き込み）インスタンスが物理障害でクラッシュした際、サービスの中断時間を最小限（数秒以内）に抑えるため、アプリケーション側のデータベース接続文字列（ホストFQDN）を直ちに手動で書き換え、昇格したレプリカインスタンスの新IPアドレス宛てにトラフィックを再マッピングさせるコードを走らせる。」
- 真実: 手動による接続先の書き換えや、アプリケーションの再起動は一切不要であり、むしろこれを実行すると復旧遅延（ダウンタイムの長期化）を招くアンチパターンです [p.136]。
- 理由: Amazon Auroraは標準機能として、データベースの接続先エンドポイント（DNS名）を提供しています [p.136]。プライマリインスタンス宛ての接続には、常に 「 クラスターエンドポイント（プライマリ） 」 を指定してアクセスします [p.136]。障害発生時、Aurora内部の自律管理システムが自動的にレプリカインスタンスをプライマリへ昇格させると同時に、クラスターエンドポイントのDNSの解決先（CNAME）を自動で瞬時に書き換えます [p.136]。
- 対策: アプリケーションは常に固定の「クラスターエンドポイント」を向いていればよく、インフラ側の物理的なIP変更を気にする必要はありません [p.136]。
ひっかけ③：「DynamoDBテーブルのアクセスにおいて、特定の属性値に基づいた高速なセカンダリ検索を可能にするため、いつでも追加・削除可能なGSI（グローバルセカンダリインデックス）を追加した。ベーステーブル（本体）へのデータ書き込み処理は極めて多いためWCU（書き込み容量）を『1,000』と高く設定したが、GSI側のWCUはコスト節約のため最小限の『10』に設定してデプロイした。」
- 真実: ベーステーブルへの高速なデータ書き込み自体が、GSI側のスロットリング（詰まり）に巻き込まれてエラー（遅延）になります [p.145]。
- 理由: DynamoDBのGSI（グローバルセカンダリインデックス）は、ベーステーブルへの書き込みを検知して非同期的にインデックスデータを複製・同期します [p.145]。しかし、ベーステーブルへ大量のデータが高速に書き込まれているにも関わらず、GSI側の書き込み許容量（WCU）が極端に低く設計されていると、GSI側の同期レプリケーション処理が限界を迎え、そのスロットリング（制限超過エラー）の影響がベーステーブル本体の書き込みAPI処理に対しても逆流して制限（エラー）をかけるという、DynamoDB特有の連鎖破壊仕様があるためです [p.145]。
- 対策: インデックス（GSI）を定義する際は、ベーステーブルの書き込み量と同等以上にWCUを適切にプロビジョニングするか、またはオンデマンド容量（自動スケール）を適用しておくのが鉄則です [p.144, p.145]。
ひっかけ④：「モバイルゲームのリアルタイム対戦成績を処理するスコアランキングシステム（リーダーボード機能）を構築したい。ミリ秒未満の圧倒的な応答速度と、突然のデータセンター障害時にもデータを物理消失させずに復旧できる可用性・永続性を両立させるため、最もシンプルで処理速度が高速な『Amazon ElastiCache for Memcached』を選択する。」
- 真実: 要求される「ランキング処理機能」も「データの可用性・永続性」も、Memcachedでは物理仕様上1行も実現できません [p.149]。
- 理由: ElastiCache for Memcachedは、データ永続化（物理ディスクへのバックアップ）やマルチAZ、および自動フェイルオーバーを一切サポートしていない揮発性（メモリが飛んだらデータは全消滅する）の極めてシンプルなKVS（キーバリューストア）です [p.149]。また、ソート済みセットなどの複雑なデータ構造も扱えません [p.149]。
- 対策: 「ソート済みセット（Sorted Set）」を用いたランキングロジックの構築や、データの永続レプリケーション、障害時の自動フェイルオーバーを要求される場合は、100% 「 Amazon ElastiCache for Redis 」 を選定するのがアーキテクチャ上の正解マッピングです [p.149, p.151]。
ひっかけ⑤：「Amazon S3内のデータレイクに毎日自動蓄積される数ペタバイト（PB）に及ぶ大量の構造化ログ（CSVやApache Parquet形式）を分析するため、Amazon Redshiftを導入した。アドホック（一時的）な分析クエリを走らせるため、毎朝バッチ処理を組んで『COPY』コマンドを実行し、全ログデータをRedshiftのコンピュートノード（ローカルストレージ）に一度全てロードしてからSQL集計を実行する。」
- 真実: ロード（インポート）のための通信・インフラ実行コストが莫大になり、分析が開始されるまでに何時間も待たされる極めて効率の悪いアンチパターンです [p.142]。
- 理由: 数PBものデータをRedshiftのローカルストレージに都度ロードすることは、多大なI/Oオーバーヘッドとクラスター維持コストを発生させます [p.142]。
- 対策: 「S3上の膨大な生データを、Redshiftクラスターにロード（COPY）することなく、S3上に置いたまま直接超並列SQL集計にかけたい」という要件に対しては、必ず 「 Redshift Spectrum 」 を選択してください [p.142]。これにより、ローカルのストレージコストを極小に抑えたまま、必要なときに瞬時にペタバイト規模のアドホック検索を走らせることができます [p.142]。
2. 【混同しやすいサービスの比較表】
本試験（SAA-C03）で最も点数配分の大きい「データベース（RDB / NoSQL / キャッシュ / 分析）」の機能境界線とユースケースの決定的な違いをマッピングします [p.126-128]。
① クラウドデータ永続化層：RDSマルチAZ vs RDSリードレプリカ vs Amazon Aurora [p.131, p.132, p.135-136]
| 比較項目 | RDS マルチAZ [p.131] | RDS リードレプリカ [p.132] | Amazon Aurora クラスター [p.135] |
|---|---|---|---|
| 主な設計目的 | 高可用性（耐障害性）、ディザスタリカバリ（DR） の担保 [p.131]。 | 読み込みクエリ（SELECT）のスケールアウト（負荷分散） [p.132]。 | 極めて高い可用性・スループットと、高速な自動復旧の両立 [p.135]。 |
| データ複製方式 | 同期レプリケーション（マスターとスタンバイの双方にデータが同時書き込み完了してコミット） [p.131]。 | 非同期レプリケーション（マスターのコミット後に、裏側でレプリカへ遅延同期される） [p.132]。 | 独自の分散ストレージを介した高速なレプリケーション。3つのAZに計6つのコピーを常時自動同期保持する [p.135]。 |
| フェイルオーバー動作 | 完全自動。DNSレコード（FQDN）がスタンバイのIPへ自動的に書き換わる（60〜120秒で完了） [p.131]。 | なし（昇格させて別DB化することは可能だが自動フェイルオーバーはしない） [p.132]。 | 完全自動。障害時は健全なレプリカが自動昇格（最短30秒未満の極小のダウンタイム） [p.136]。 |
| スタンバイ/レプリカの読み書き | スンタバイDBはアクセス不可（パッシブ待機） [p.131]。 | 読み取り（参照）のみ可能 [p.132]。 | プライマリは書き込み可、最大15台のAuroraレプリカで読み取り分散可 [p.135, p.136]。 |
| 試験での決定的な選定シグナル | 「障害時にもデータを消失させず、接続エラーを自動復旧してビジネスを継続させたい」 [p.131]。 | 「売上集約やダッシュボード表示によるマスターDBのCPU高負荷を、読み取り専用コピーで解消したい」 [p.132]。 | 「エンタープライズ級の極めて厳しいRTO（目標復旧時間）を満たし、ストレージ容量（最大128TB）を自動伸縮させたい」 [p.135]。 |
② NoSQL ＆ インメモリキャッシュ：DynamoDB vs ElastiCache (Redis) vs ElastiCache (Memcached) [p.143, p.149]
| 比較項目 | Amazon DynamoDB [p.143] | ElastiCache (Redis) [p.149, p.151] | ElastiCache (Memcached) [p.149, p.150] |
|---|---|---|---|
| データベース分類 | フルマネージドな永続NoSQLデータベース [p.143]。 | 永続・レプリケーション対応型インメモリキャッシュ [p.149, p.151]。 | 完全揮発性の単純インメモリキャッシュ [p.149]。 |
| データの永続性（不揮発） | あり（データはSSDストレージに確実に永久保存・自動複製される） [p.143]。 | あり（メモリ上のデータをディスクへスナップショット保存・復元可能） [p.149]。 | 一切なし（ノードの再起動や障害発生時にメモリ上の全データが消滅する） [p.149]。 |
| 高度なデータ構造 / 可用性 | キーバリュー、ドキュメント。複数AZへの自動保護、マルチリージョン対応 [p.143]。 | ソート済みセット（Sorted Set）、ハッシュ、リスト、Pub/Sub等。自動フェイルオーバー・マルチAZ対応 [p.149, p.151]。 | 文字列などの単純キーバリューのみ。マルチAZ自動フェイルオーバーは非サポート [p.149]。 |
| 主な用途シグナル | 「 大量のユーザープロフィール情報、ECサイトの買い物かご、数億台のIoTセンサーデータの永続格納 」 [p.143]。 | 「 高可用性を備えたWebログインセッション管理、リアルタイムランキング、Redis独自のデータ型処理 」 [p.149]。 | 「 データが消失してもDBから再生成可能なため問題がない、静的Webページの単純クエリ結果キャッシュ 」 [p.149]。 |
3. 【弱点確認クイズ】
問1（○×問題）
自社ECサイトの売上データの参照リクエストが特定のマスターデータベース（RDS MySQL）に集中したため、ソリューションアーキテクトは参照性能のボトルネックを緩和させるために「マルチAZ配置」を有効化して、データを同期レプリケーションさせた。 この設計により、スタンバイDBがマスターと並列して読み取り（SELECT）クエリを分散処理するようになるため、アプリケーションのデータベース応答性能は劇的に改善される。 （○ か × か） [p.131-132]
問2（4択問題）
本番環境でデプロイされている「Amazon Auroraクラスター」において、1台のプライマリインスタンス（書き込み用）と、2台のAuroraレプリカ（読み取り用）が異なる3つのアベイラビリティゾーンに分散稼働しています。 現在、社内のデータサイエンティストが時折実行する「重い売上分析集計SQLバッチ」のせいで、一般ユーザーがスマートフォンアプリから実行する「軽量な売上履歴の参照クエリ」の処理速度が巻き込まれてスローダウンする事象が発生しています。 一般ユーザー用アプリに影響を与えることなく、分析バッチの負荷を完璧に分離・設計するための、最も適切なAuroraエンドポイントの構成マッピングはどれですか。 [p.136`]
- A. 分析バッチとアプリの双方が「読み取りエンドポイント（Reader Endpoint）」へ均等にアクセスするよう接続文字列を一元化する [p.136]。
- B. 新たに「カスタムエンドポイント（Custom Endpoint）」を作成し、分析用の重いレプリカと、一般アプリ用の軽量レプリカのインスタンスグループを論理的に分離マッピングして、それぞれの専用接続先として提供する [p.136]。
- C. 分析バッチの実行時のみ、プライマリインスタンスの「クラスターエンドポイント」に直接接続してSELECTを実行させる [p.136]。
- D. Auroraレプリカを一時的にシャットダウン（停止）し、直接物理ディスクボリュームのS3クローンを作成して分析させる [p.135]。
問3（4択問題）
あるソーシャルネットワーキングアプリにおいて、ユーザー同士が獲得した「本日のリアルタイムポイント数」に基づいて、1秒間に何万回も変動する「動的トップ100ランキング（リーダーボード機能）」をミリ秒以下の超低遅延で提供したいと考えています。 また、物理的なハードウェア障害が発生した場合でも、ランキングデータやセッション情報が完全に揮発して消滅することを回避するための「マルチAZ自動フェイルオーバー」および「永続データのスナップショット保護」が必要です。 この要件を最も満たす、最適なインメモリデータストアの選定マッピングはどれですか。 [p.149, p.151]
- A. Amazon ElastiCache (Memcached) [p.149]
- B. Amazon ElastiCache (Redis) [p.149, p.151]
- C. Amazon DynamoDB（強整合性読み込みオプション） [p.144, p.147]
- D. Amazon RDS (PostgreSQL) [p.129, p.131]
問4（○×問題）
DynamoDBテーブルを設計する際、作成後であってもいつでも自由に追加・削除が可能な「GSI（グローバルセカンダリインデックス）」を作成した。GSIを定義した際、コスト節約のためにGSI側のWCU（書き込み容量ユニット）を非常に低く設定していた場合であっても、DynamoDBは非同期でGSIにデータを自動書き込みするため、ベーステーブル（本体）に対する直接の書き込みAPIリクエスト自体がスロットリングエラーを起こして拒否されることはない。 （○ か × か） [p.145]
問5（4択問題）
データ分析チームにおいて、Amazon S3バケット内に蓄積されている数ペタバイト（PB）に及ぶ過去数年分のParquetデータ（コールドログデータ）に対し、年に数回しか実行しないアドホック（一時的）な監査集計SQLを実行したいと考えています。 Redshiftクラスターのストレージ（コンピュートノード）へのデータロード（COPYコマンド）に伴う莫大なデータ転送時間と、高価なローカルディスクの定常維持費を完璧に「ゼロ」に抑えつつ、S3上のデータに対して超高速な並列分析を実行できる、最も適切な構成はどれですか。 [p.142]
- A. Amazon RDSにCSVとしてインポートし、マルチAZを介して分散処理させる [p.131]。
- B. Amazon Redshift のリーダーノードをスケールアップさせ、データを順次ストリーミングする [p.138]。
- C. Redshift Spectrum をデプロイし、S3上のParquetデータに対して直接並列クエリを実行する [p.142]。
- D. Amazon ElastiCache (Redis) に全ログをキャッシュさせてからクエリを実行する [p.149]。
【解答と解説】
解答1：×
- 解説: 誤りです [p.131-132]。マルチAZ構成における「スタンバイDB」は、通常時はパッシブ（待機）状態で裏側で待機しており、読み取りや書き込みなどのクエリを直接処理することはできません [p.131]。したがって、マルチAZを有効化しても参照性能の向上（負荷分散）には1ミリも貢献しません [p.131-132]。参照クエリの負荷を逃がしたい（参照スケールアウト）という明確な要件シグナルに対しては、必ず 「 リードレプリカ 」 の追加配置を選択してください [p.132]。
解答2：B
- 解説: 正解は B. カスタムエンドポイントの適用 です [p.136]。
- 通常、読み取りエンドポイント（Reader Endpoint）は、配下にあるすべてのレプリカに対してリクエストを均等にラウンドロビン（分散）転送してしまいます [p.136]。そのため、Aのように分析バッチと一般アプリを同じ読み取りエンドポイントに接続させると、分析用の重いクエリを処理しているレプリカインスタンスに一般ユーザーのアクセスもルーティングされてしまい、パフォーマンス劣化を回避できません [p.136]。
- カスタムエンドポイント（Custom Endpoint） を作成すると、レプリカインスタンスを「一般アプリ用のグループ（高性能インスタンス等）」と「分析バッチ用のグループ」に論理的に分離マッピングさせることができ、エンドポイントへの接続文字列（DNS名）を完全に切り分けることが可能となるため、負荷を完璧に分離・隔離する最強の設計ベストプラクティスとなります [p.136]。
解答3：B
- 解説: 正解は B. Amazon ElastiCache (Redis) です [p.149, p.151]。
- 問題文に示されている決定的なキーワード（シグナル）は 「 ミリ秒未満（マイクロ秒）の超低遅延（インメモリデータストア必須） 」、「 ランキング処理（Sorted Setデータ構造が必要） 」、「 データ永続性の担保（スナップショット等） 」、そして 「 マルチAZ自動フェイルオーバー 」 の4点です [p.149]。
- AのMemcachedはソート済みセットなどの複雑なデータ型を扱えず、永続性や自動フェイルオーバーも一切備えていないため不適合です [p.149]。CのDynamoDB、DのRDSはディスクベース（SSD）のデータ永続データベースであり、データ読み出しに応答にミリ秒単位のオーバーヘッドが発生するため、マイクロ秒レベルの極限の低遅延や複雑なリアルタイム集計を要求するリーダーボード設計としては不適合となります [p.143, p.149]。
解答4：×
- 解説: 誤りです [p.145]。DynamoDBの GSI（グローバルセカンダリインデックス） は非同期にデータを同期しますが、GSI側のWCU（書き込み容量ユニット）が枯渇して同期処理にスロットリング（制限）が発生すると、ベーステーブル（本体）に対する直接の書き込みAPI処理自体に対しても、GSIの同期プレッシャーによって自動的にスロットリングエラー（連鎖拒否）を発生させてしまいます [p.145]。GSIを追加する際は、本体の更新負荷に耐えられる十分なWCU容量（または自動スケーリング）を確保することが必須設計要件です [p.144, p.145]。
解答5：C
- 解説: 正解は C. Redshift Spectrum の実行 です [p.142]。 「S3データレイク上の膨大なデータ（数PB）に対し、クラスター側へのデータロード時間をかけず、ディスク追加維持コストも払わずに、一時的（アドホック）なSQLクエリを実行させたい」というシナリオが出た場合は、Redshift Spectrum が100%マッピングされる唯一の正解となります [p.142]。これにより、S3にあるParquet等の構造化データを外部テーブルとして定義し、クラスター側のストレージリソースを消費することなく超高速に集計処理を実行できます [p.142]。
🥇 これでデータベース設計（第5章 RDS, Aurora, Redshift, DynamoDB, ElastiCache）の重要ひっかけ・使い分けの攻略が完全に完了しました！
マルチAZ（可用性）とリードレプリカ（参照負荷）の違い [p.131-132]、GSIのキャパシティ制限罠 [p.145]、RedisとMemcachedの境界線 [p.149]、そしてRedshift Spectrumのコスト最適化仕様 [p.142]。これらは試験において極めて配点比率の高い「高可用かつセキュアな設計」の絶対的な大得点源です。