勝手にAWS教室 8時間目：Aurora・DynamoDB・ElastiCache・DocumentDB・Neptune
情報が古い場合があります。間違っている箇所がありましたらご教授いただけると幸いです。
RDSの回でリレーショナルデータベースの基本を学びましたが、AWSのデータベースサービスはRDSだけではありません。
「RDSよりもっと速いDBはないの？」「キャッシュって何？」「NoSQLって結局どう使い分けるの？」この辺りがモヤモヤしている方、今回でスッキリさせましょう。
先にまとめ
- Aurora：RDSの上位互換。MySQL/PostgreSQL互換で最大5倍高速
- DynamoDB：超高速・超スケーラブルなキーバリュー型NoSQL
- ElastiCache：DBの前に置く超高速キャッシュ層
- DocumentDB：MongoDB互換のドキュメント型NoSQL
- Neptune：人間関係やネットワーク構造を扱うグラフDB
1. Aurora ＝ RDSの上位互換・AWS独自エンジン
Amazon Auroraは、AWSが独自開発したMySQLおよびPostgreSQL互換のデータベースエンジンです。
RDSで選択できるエンジンの1つですが、「同じSQLが使えるのに、中身は全く違うエンジン」というのがポイントです。
なぜAuroraが必要なのか
通常のMySQL on RDSでも十分使えますが、アクセス数が増えてくると「もっと速くしたい」「もっとレプリカを増やしたい」「障害に強くしたい」という要望が出てきます。Auroraはこれらをすべて解決するために作られました。
| 項目 | MySQL on RDS | Aurora |
|---|---|---|
| 性能 | 標準 | MySQL比最大5倍・PostgreSQL比最大3倍 |
| ストレージ | 最大64TB | 最大128TB・自動拡張 |
| レプリカ | 最大5台 | 最大15台 |
| 耐障害性 | マルチAZ | 3AZに6コピー自動複製 |
通常のMySQLが「軽自動車」なら、Auroraは「同じ免許で乗れるスポーツカー」のイメージです。操作方法（SQL）は同じなのに、エンジンの中身が違うので速い。
Auroraのストレージの仕組み
Auroraが高い耐障害性を持つ理由は、ストレージの設計にあります。データは3つのAZに各2コピー、合計6コピーが自動で保存されます。仮にどこかのAZで障害が起きても、残りのコピーで読み書きを継続できます。
❌が何かしらの理由で使えないDBだったとして、⭕️がある限りは情報を取得することができる。
RDSのマルチAZが「予備機を1台用意する」なのに対し、Auroraは「データ自体が最初から6重に分散している」という根本的な違いがあります。
Aurora Serverless
Aurora Serverlessは、アクセスがないときはAuroraを自動停止し、リクエストが来たら自動起動するサーバーレスモードです。
普通のAuroraが「24時間営業のコンビニ」なら、Aurora Serverlessは「お客さんが来たときだけ自動で開く無人販売所」です。誰も来ない深夜にも電気代がかかる、ということがなくなります。
アクセスが不定期な開発・テスト環境や、利用パターンが予測しにくい新規サービスのスタート時に向いています。逆に、常にアクセスがある本番環境では通常のAuroraの方がコスト効率が良い場合が多いです。
2. DynamoDB ＝ 超高速・超スケーラブルなNoSQL
Amazon DynamoDBは、キーバリュー型のフルマネージドNoSQLデータベースです。
RDB（リレーショナルDB）との違い
RDSやAuroraのようなリレーショナルDBは、複数のテーブルをJOINして複雑な検索ができるのが強みです。一方、DynamoDBはキー（名前）を指定してデータを取り出すことに特化しています。複雑な検索は苦手ですが、その分圧倒的に速いです。
RDBが「図書館の検索システム（著者名・出版年・ジャンルなど複雑な条件で検索できる）」なら、DynamoDBは「付箋メモの束（番号を言えば一瞬で取り出せるが、内容で横断検索はしにくい）」です。
DynamoDBの強み
| 項目 | RDS/Aurora | DynamoDB |
|---|---|---|
| レイテンシ | 数ミリ秒〜 | 1桁ミリ秒（常に） |
| スケーリング | スケールアップ（サーバーを大きくする） | スケールアウト（自動で水平拡張） |
| 管理 | インスタンスタイプの選択が必要 | 完全サーバーレス |
| 検索 | SQL・JOIN・複雑なクエリ | キーによるシンプルな取得 |
DynamoDBはサーバーレスなので、インスタンスタイプやストレージ容量を事前に決める必要がありません。アクセスが増えればAWSが自動でスケールしてくれます。
どんなときに使う？
- セッション管理：ユーザーIDをキーにして、ログイン状態を高速に読み書き
- ゲームのスコア管理：プレイヤーIDをキーにして、スコアやアイテムを管理
- IoTデバイスのデータ保存：大量のデバイスから秒単位で送られるデータを保存
- ECサイトのカート：カートIDをキーにして、中身を瞬時に取得
「アクセスが大量」「応答速度が命」「データの構造がシンプル」この3つが揃ったらDynamoDBの出番です。逆に、複雑なJOINや集計が必要ならRDS/Auroraを使いましょう。
3. ElastiCache ＝ 超高速キャッシュ層
Amazon ElastiCacheは、インメモリキャッシュ（MemcachedまたはRedis）をマネージドで提供するサービスです。
なぜキャッシュが必要なのか
データベースへのアクセスは、ディスクからデータを読み取るため、どうしても時間がかかります。「ランキング情報」や「ユーザープロフィール」のように頻繁に読まれるデータを、毎回DBに問い合わせるのは無駄が多いですよね。
ElastiCacheはデータをメモリ上（RAM）に保持することで、DBへのアクセスを減らし、応答速度をミリ秒以下に短縮できます。
図書館に例えると、よく借りられる本をカウンター前に並べておく（キャッシュ）ことで、奥の書庫（DB）まで取りに行く手間を省くイメージです。人気の本が10回リクエストされても、書庫に行くのは最初の1回だけ。
RedisとMemcachedの使い分け
ElastiCacheでは2つのエンジンから選べます。
| 項目 | Redis | Memcached |
|---|---|---|
| データ構造 | 文字列・リスト・セット・ハッシュなど豊富 | 文字列のみ |
| 永続化 | あり（再起動してもデータが残る） | なし（再起動するとデータが消える） |
| レプリケーション | あり | なし |
| マルチスレッド | なし | あり |
| 比喩 | 多機能な付箋ボード | シンプルで高速なメモ帳 |
迷ったらRedisを選んでおけば大抵の場合は問題ありません。Memcachedは「とにかくシンプルに、大量のキーを高速にキャッシュしたい」という場合に向いています。
ElastiCacheの典型的な使い方
- セッション管理：ログイン情報をキャッシュして、毎回DBに問い合わせない
- ランキング：Redisのソート済みセットで、リアルタイムランキングを高速に管理
- APIレスポンスのキャッシュ：同じクエリの結果を一定時間キャッシュ
4. DocumentDB ＝ MongoDB互換のドキュメント型NoSQL
Amazon DocumentDBは、MongoDBと互換性を持つマネージドなドキュメント型データベースです。
RDB（テーブル型）との違い
RDSのようなリレーショナルDBでは、データを「行と列」で管理します。これは構造がカッチリ決まっているデータには最適ですが、「商品ごとに属性が全然違う」ようなケースでは扱いにくくなります。
DocumentDBはJSONライクなドキュメント形式でデータを保存するため、スキーマ（データ構造の定義）を柔軟に変更できます。
Excelの表（RDB）では、すべての商品に同じ列（カラム）が必要です。でもDocumentDBはWordの文書のように、商品ごとに違う情報を自由に書き込めます。
// 例：異なるドキュメントを保存できる
{ "name": "Tシャツ", "size": "M", "color": "白" }
{ "name": "ノートPC", "cpu": "M4", "ram": "16GB", "ports": ["USB-C", "HDMI"] }
どんなときに使う？
- コンテンツ管理：記事やプロフィールなど、構造が変化しやすいデータ
- カタログ管理：商品ごとに属性が異なるECサイト
- モバイルアプリ：JSONでやり取りするバックエンド
すでにMongoDBを使っているシステムをAWSに移行したい場合にも、互換性があるためスムーズに移行できるのが強みです。
5. Neptune ＝ グラフデータベース
Amazon Neptuneは、ノード（点）とエッジ（線）で構成されるグラフ型データベースです。
なぜグラフDBが必要なのか
RDBで「AさんはBさんの友人で、BさんはCさんの同僚で、CさんはDさんのフォロワーで...」という関係を表現しようとすると、JOINが何重にも必要になり、データ量が増えるほど遅くなります。
グラフDBは、このような「関係性」そのものをデータとして保持するため、「Aさんの友人の友人の友人は？」といったクエリを高速に処理できます。
人物相関図をそのままデータベースとして扱えるのがNeptuneです。RDBが「住所録（表形式で人の情報を管理）」なら、Neptuneは「相関図（人と人のつながりを管理）」です。
どんなときに使う？
- SNS：フォロー・フレンド関係の管理、「知り合いかも？」の推薦
- 不正検知：怪しい取引パターンやアカウント間の関係を分析
- ナレッジグラフ：Wikipedia的な「概念と概念のつながり」の管理
- 経路探索：道路ネットワークや鉄道の乗り換え案内
逆に言えば、「データ同士の関係性」が重要でない場合はRDSやDynamoDBの方が適切です。
データベースサービス 全体まとめ
| サービス | 種類 | 比喩 | 向いているデータ |
|---|---|---|---|
| RDS | リレーショナル | Excelの表 | 構造化されたトランザクション |
| Aurora | リレーショナル（高性能） | スポーツカー版MySQL | 高性能が必要なRDB |
| DynamoDB | NoSQL（キーバリュー） | 付箋メモ | 大規模・高速・スケーラブル |
| ElastiCache | インメモリキャッシュ | カウンター前の人気書籍 | 頻繁なDB読み取りの高速化 |
| DocumentDB | NoSQL（ドキュメント） | Wordの文書 | JSONライクな柔軟なデータ |
| Neptune | グラフ | 人物相関図 | 関係・ネットワーク構造 |
| Redshift | データウェアハウス | 分析センター | 大量データの集計・分析 |
最後に
データベースサービスは種類が多くて混乱しますが、ポイントは「何を保存したいか」と「どう検索したいか」です。
ざっくり覚えておくなら：
- 普通のRDBを楽に使いたい → RDS
- RDBをもっと速く・強くしたい → Aurora
- 大量アクセスをシンプルにさばきたい → DynamoDB
- 頻繁に読まれるデータを爆速にしたい → ElastiCache
- 構造が柔軟なJSONデータを扱いたい → DocumentDB
- データ同士の関係性を扱いたい → Neptune
とりあえずデータベースについて聞かれたら「スポーツカーとカウンター前の本と文書と相関図のことですね！」と言ってみてください。これで伝わる人がいればそれはきっと元教員をしていたエンジニアです。
現在までに投稿してきた「勝手にAWS教室」はこちらにまとめてあります。
興味がある方はご覧ください。