AWS SAA(Solutions Architect - Associate)対策
データベース総合選定
このレッスンでできるようになること
要件の文に出てくる言い回しから、どのデータベース種別を選ぶかを1枚の対応表で判断できるようになります。この章の総まとめにあたる回です。
要件の文から入る
ある企業が複数のシステムを AWS へ移行します。基幹システムはテーブル間の結合と厳密なトランザクションを使います。IoT の計測値は時刻とともに大量に届き、時間帯ごとの集計をします。マーケティングは数年分の履歴を横断して集計クエリを回します。SNS 機能では利用者どうしのつながりを何段もたどる必要があります。既存の社内ツールはMongoDB 互換の API を前提に書かれています。
SAA のデータベース設問は、こうした要件語がそのままサービス名に対応しています。逆に言えば、対応表を持っていれば読むだけで解けます。
まず3つに大きく割る
| 種別 | 何を求められているか | 代表 |
|---|---|---|
| リレーショナル | 結合、厳密なトランザクション、既存の SQL 資産 | RDS、Aurora |
| 非リレーショナル | 単純なキーでの高速な読み書き、桁違いの規模、柔軟な項目 | DynamoDB |
| 分析用 | 大量の履歴を横断する集計、列単位の集約 | Redshift |
ここを外すと、その先の選択がすべて無駄になります。「結合」「トランザクション」があればリレーショナル、「一桁ミリ秒」「スキーマが項目ごとに違う」があれば DynamoDB、「数年分」「集計」「BI」があれば Redshift と割ってください。
要件語からデータベース種別への対応表
| 要件の言い回し | 選ぶもの |
|---|---|
| 結合と厳密なトランザクションが要る | RDS |
| 上に加えて読取レプリカを多数、復旧も速く | Aurora |
| 別リージョンからも低遅延で読みたい | Aurora Global Database |
| 利用が間欠的で容量を読めない | Aurora Serverless |
| キー指定で一桁ミリ秒、規模が読めない | DynamoDB |
| DynamoDB の読取をさらに速く、アプリは変えない | DAX |
| 数年分の履歴を横断して集計、BI から参照 | Redshift |
| S3 上のデータに SQL を投げたいだけ | Athena(サーバー不要の都度クエリ) |
| 利用者どうしのつながりを何段もたどる | Neptune(グラフ) |
| MongoDB 互換の API をそのまま使いたい | DocumentDB |
| 時刻に紐づく計測値を大量に入れて時系列で集計 | Timestream |
| 台帳のように変更履歴を改ざん不能に残したい | QLDB |
| ミリ秒未満の応答、キャッシュとして使いたい | ElastiCache |
冒頭のシナリオはこれで全部片付きます。基幹は RDS または Aurora、IoT の計測値は Timestream、履歴の集計は Redshift、つながりの探索は Neptune、MongoDB 互換は DocumentDB です。
線引きが紛らわしいところ
Redshift と Athena。 どちらも大量データへの SQL ですが、Redshift はクラスターを持って繰り返し重い集計を回す用途、Athena は S3 に置いたデータへ必要なときだけ問い合わせる用途です。「日次のダッシュボードから常時参照」なら Redshift、「たまにログを調べたいだけ」で「基盤を管理したくない」なら Athena になります。
DynamoDB と RDS。 「規模が急激に伸びる」「キーで引くだけ」なら DynamoDB ですが、「複数テーブルの結合レポートが必要」と書かれていたら DynamoDB では素直に書けません。結合という語が出た時点でリレーショナルに寄せます。
Neptune と DocumentDB。 どちらもリレーショナルではありませんが、Neptune は関係のたどり方そのものが目的、DocumentDB は文書の格納と MongoDB 互換が目的です。「友達の友達」「推薦」「不正の関連を追う」は Neptune、「既存の MongoDB アプリを動かす」は DocumentDB です。
よくある引っ掛け
引っ掛け1、時系列データを何でも DynamoDB に寄せる。 保存はできますが、「時間帯ごとに集計する」という語があれば Timestream の方が要件に合います。時刻という語と集計という語が並んでいるかを見てください。
引っ掛け2、分析要件に読取レプリカで応じる。 レプリカは同じ行指向のエンジンなので、数年分を横断する集計の重さは本質的に変わりません。「BI ツールから」「全期間を集計」と書かれていれば Redshift へ寄せます。
まとめ
- まずリレーショナル、非リレーショナル、分析用の3つに割る
- 結合とトランザクションはリレーショナル、キー引きと規模は DynamoDB
- 履歴の横断集計は Redshift、都度の問い合わせだけなら Athena
- つながりは Neptune、MongoDB 互換は DocumentDB、時刻つき計測値は Timestream
復習ミニクイズ
ある物流企業が、配送車両から1秒ごとに届く位置情報と温度の計測値を蓄積し、車両ごと・時間帯ごとの推移をダッシュボードで表示したいと考えています。データ量は今後さらに増え、運用の手間は最小にしたいという要件があります。最も適したデータベースはどれですか。