勝手に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教室」はこちらにまとめてあります。
興味がある方はご覧ください。

参考