AWS Certified Solutions Architect - Associate (SAA-C03) #12 Domain 3-4 高性能アーキテクチャ — DB の選択
#11 ストレージ に続いて、高性能ドメインの最後として データベースの選択 を扱います。SAA の DB 問題で最も頻繁に、最も決定的に分かれる地点は RDS の Multi-AZ とリードレプリカの違い です。ここから整理します。
RDS — マネージドリレーショナルデータベース #
RDS は MySQL・PostgreSQL・MariaDB・Oracle・SQL Server をマネージドで提供します。バックアップ・パッチ・復旧を AWS が担います。核心となるのは 2 つの拡張/可用性のメカニズムであり、目的がまったく異なります。
| 項目 | Multi-AZ | リードレプリカ (Read Replica) |
|---|---|---|
| 目的 | 高可用性/障害切り替え | 読み取り負荷の分散 |
| 複製方式 | 同期 (synchronous) | 非同期 (asynchronous) |
| 待機インスタンス | 平常時はトラフィックを受けない (standby) | 読み取りトラフィックを受ける |
| 障害時 | 自動 failover | 手動の昇格 (promote) が必要 |
| クロスリージョン | 通常は同じリージョン | クロスリージョン可能 |
- Multi-AZ — 別の AZ に 同期複製された standby を置き、主インスタンスの障害時に 自動的に切り替え ます。高可用性のためのものであって 読み取り性能のためのものではありません。 standby は平常時にトラフィックを受けません。
- リードレプリカ — 非同期の複製 を置いて 読み取りクエリを分散 します。読み取り負荷の大きいワークロードの拡張手段であり、クロスリージョンにも置けるため DR とグローバル読み取りにも活用されます。ただし、自動 failover ではありません。
この区別が試験の常連です。「読み取り負荷の分散」はリードレプリカ、「高可用性/自動 failover」は Multi-AZ です。両方を組み合わせて可用性と読み取り拡張を同時に押さえることもあります。
Aurora — クラウドネイティブなリレーショナル #
Aurora は AWS がクラウドに合わせて作り直したリレーショナル DB で、MySQL・PostgreSQL と互換 です。特徴は次のとおりです。
- ストレージの自動拡張 — データが増えるとストレージが自動的に大きくなります。
- 6 つの複製を 3 つの AZ に分散 保存して高い耐久性と可用性。
- 最大 15 個のリードレプリカ で読み取り拡張。
- Aurora Global Database — 複数のリージョンに 1 秒未満の遅延で複製 (#7 DR で活用)。
- Aurora Serverless v2 — 負荷に応じてキャパシティを自動調整 (変動・間欠ワークロード)。
「MySQL/PostgreSQL 互換でありながら、より高い性能と自動ストレージ拡張」が手がかりなら Aurora です。
DynamoDB — マネージド NoSQL #
DynamoDB は完全マネージドの NoSQL key-value/document データベースです。サーバーレスであり事実上無制限に拡張し、1 桁ミリ秒 (DAX でマイクロ秒) の応答を出します。
- キャパシティモード — On-Demand (トラフィック予測不可・管理不要) vs Provisioned (予測可能・コスト効率)。
- グローバルテーブル — マルチリージョンの active/active 複製。
- DynamoDB Streams — データ変更イベントをキャプチャ (例: Lambda トリガー)。
- TTL — 項目の自動有効期限切れ。
- DAX — #10 のマイクロ秒キャッシュ。
「key-value、ミリ秒応答、無制限拡張、サーバー管理なし」なら DynamoDB です。ただし 複雑な結合やトランザクション中心のリレーショナルモデルには不適切 です。そのようなワークロードは RDS/Aurora です。
目的別のデータベース #
リレーショナル・NoSQL のほかにもワークロード専用の DB があります。試験に登場するものです。
| ワークロード | サービス |
|---|---|
| 分析/データウェアハウス (OLAP) | Redshift |
| インメモリキャッシュ | ElastiCache (#10) |
| グラフ (関係データ) | Neptune |
| MongoDB 互換のドキュメント DB | DocumentDB |
| 時系列 | Timestream |
「大規模データの 分析/集計クエリ (OLAP)」はトランザクション用の RDS ではなく Redshift です。この区別 (OLTP vs OLAP) がよく出ます。
試験の出題パターン #
- 「リレーショナル DB の 読み取り負荷の分散。」 → リードレプリカ (Read Replica)
- 「リレーショナル DB の 高可用性/自動 failover。」 → Multi-AZ
- 「MySQL 互換 + 高性能 + ストレージの自動拡張。」 → Aurora
- 「マルチリージョンの active/active リレーショナル。」 → Aurora Global Database
- 「key-value、ミリ秒、無制限拡張、サーバーレス。」 → DynamoDB
- 「トラフィック 予測不可 の NoSQL、キャパシティ管理を回避。」 → DynamoDB On-Demand
- 「大規模な 分析/データウェアハウス。」 → Redshift
よく出会う落とし穴 #
1) Multi-AZ で読み取りを拡張しようとする #
Multi-AZ の standby はトラフィックを受けません。読み取り拡張は リードレプリカ です。
2) リードレプリカで自動 failover を期待する #
リードレプリカは非同期であり自動切り替えではありません。自動 failover は Multi-AZ です。
3) DynamoDB で複雑な結合を処理する #
DynamoDB は NoSQL です。複雑なリレーショナル結合・トランザクションは RDS/Aurora が適切です。
4) 分析クエリを RDS で処理する #
大規模分析 (OLAP) は RDS ではなく Redshift です。RDS はトランザクション (OLTP) 用です。
まとめ #
この記事で押さえたこと:
- RDS — Multi-AZ (高可用性・自動 failover) vs リードレプリカ (読み取り拡張・非同期・クロスリージョン可能)。目的が異なる
- Aurora — MySQL/PostgreSQL 互換、ストレージの自動拡張、Global、Serverless v2
- DynamoDB — NoSQL key-value、サーバーレス・無制限拡張、On-Demand/Provisioned、グローバルテーブル。複雑な結合には不適切
- 目的別 — 分析は Redshift (OLAP)、グラフは Neptune、ドキュメントは DocumentDB
これで 高性能ドメイン (24%, #9~12) を終えます。コンピューティング → キャッシング → ストレージ → データベースと、性能を引き上げる選択肢を整理しました。
次へ — Domain 4-1 コスト最適化 #
最後のドメインは コスト最適化 (20%) です。同じ結果をより安く出す設計へ移ります。
#13 Domain 4-1 価格モデル では、EC2 購入オプションのコスト観点での再整理 (Reserved・Savings Plans・Spot)、S3・ストレージのコスト構造、データ転送コスト、そしてコストを削減するアーキテクチャの選択を整理します。