NoSQL(DynamoDB・Redis・ElastiCache) - AWS

最終更新日: 2026-07-27

TOP(About this memo)) > 一覧(AWS) > NoSQL(DynamoDB・Redis・ElastiCache)

DynamoDB

KVSであり、ドキュメントデータベースでもある。
NoSQLについて
- Amazon Auroraを含むRDBMSでは、トランザクションや排他制御などデータの一貫性を保つための機能が充実している一方、スケーラビリティが犠牲になりやすい。
- 小規模なシステムではスケーラビリティの低さは問題になりにくいが、規模が大きくなるにつれコストパフォーマンスが悪化し、最終的には性能の限界を迎える。
- このRDBMSのスケーラビリティ課題を解決するため、MongoDBなどの新方式のデータベース管理システムが次々と登場した。これらはNoSQL(not only SQL)と呼ばれ、その多くはRDBMSと比べて高いスケーラビリティや可用性を特徴とする。
- AWSもNoSQLサービスとしてAmazon DynamoDBやAmazon DocumentDBなどを提供しており、JSON形式でデータを保管できる。
- ただしNoSQLはスケーラビリティを高めるためにデータの一貫性を少なからず犠牲にしており、RDBMSであれば当たり前に備えている表の結合などの機能を欠くなど、制限も少なくない。RDBMSとNoSQLはどちらか一方が優れているわけではなく、使いどころの見極めが大切。

NoSQL、Redis、ElastiCache

NoSQLの基本

ビッグデータの登場により、従来のRDBだけでは十分な処理ができなくなってきたことがNoSQL登場の背景にある。ビッグデータの定義は様々あるが、ここでは3V(Volume/Velocity/Variety)を満たすものをビッグデータと呼ぶ。
Volume(大量データ)とVelocity(秒単位で発生する大量データ)への対処には、スケールアップ(メモリ増加、コア数増加、SSD化)とスケールアウトの2通りの方法があるが、スケールアップには物理的な限界があり、RDBのスケールアウトは一般的に難しい。NoSQLは一般的にRDBよりもスケールアウトが容易(AWSのAuroraのようにスケールしやすいRDBも出てきているが(?))。
Variety(非リレーショナルな多様なデータ)をRDBで扱うのはそもそも辛い。
4つの種類と代表的なOSS
- KVS(キーバリューストア): キーとバリューの組み合わせ。Redis、memcachedなど
- ドキュメント指向データベース: キーに対してJSONやXMLを格納する。mongoDBなど
- カラム指向データベース: 列方向のデータのまとまりをファイルシステム上の連続した位置に格納し効率的にアクセスする。cassandra、HBaseなど
- グラフ指向データベース: グラフ理論に基づいて関連性を持たせる
トランザクション処理ができない(ACID特性でない)ものが多いが、この点は年々変化してきている(?)。
RDBとの使い分け
- サービスがビッグデータを扱う性能を求めるか、データがNoSQLで扱えるものかを自問自答する。Yesであれば採用を検討する。
  - どうしてもリレーショナルデータにできないデータか
  - トランザクション管理が不要なデータか
  - 最悪揮発しても問題ないデータか
- そうでなければRDBで管理する。RDBで管理できるものは極力RDBに寄せる、という考え方もある(この点は人によって考え方が違う(IME))。
- 不必要にNoSQLを採用するとシステムの複雑性が上がるため、慎重に採用を判断する。

Redis(Remote Dictionary Server)

(参考) https://qiita.com/gold-kou/items/966d9a0332f4e110c4f8
OSS(BSDライセンス)のKVS。
豊富なデータ型(String/List/Set/Sorted Set/Hash)を持つ。
シングルスレッドで動作し、自動的に排他的になる。
インメモリDBのため高速。
レプリケーション
- マスターのデータをスレーブにコピーすることで、読み取り処理の負荷分散と耐障害性を高める方法。
- マスターは読み書き両方ができるが、スレーブは読み込み専用。マスターは複数のスレーブを持てる。レプリケーションは非同期に行われる。
- AWSのElastiCacheサービスでは、マスターを”プライマリノード”、スレーブを”リードレプリカ”と呼ぶ。
バックアップ
- RDBとAOFの2種類の方式が存在する。
- ElastiCacheではAOFも利用可能だが、そもそもバックアップ機能を利用せずMulti-AZのレプリカ構成にすることが推奨される。
- RDB(スナップショット): デフォルト
- AOF(Append Only File): 更新処理ごとにその処理内容を保存し続ける。パフォーマンスは低下する。
使いどころ
- 有効期限のあるデータを扱う場合(セッション、ワンタイムトークンなど。保存時にexpireを指定できる)
- ランキングデータを扱う場合(Sorted Set(ユーザーID/スコアなど)を利用。RDBのORDER BYより速い)
- IoTデータの一時保存先として使う場合
- Pub/Subを使う場合(RedisはKVS的な使い方以外にPub/Sub機能も持つ)
  - Pub/Subパターンは、イベント駆動型プログラミングのデザインパターンの1つ。Publisher(発行者)が発行したイベントをBroker(仲介者)が取りまとめ、Subscriber(購読者)に伝達する。イベントはBrokerが管理するため、PublisherとSubscriberは疎結合になる。
  - 同じイベント駆動のデザインパターンにObserverパターンがある。両者の大きな違いはイベントをどこで管理するかで、Observerパターンは観測者と観測対象が直接イベントをやり取りするのに対し、Pub/SubパターンはEvent Chanelがイベント管理を行い、発信者と購読者同士が直接やり取りすることはない。
- Redisとmemcachedの使い分け(IME): とりあえずRedisのほうが多機能だと思っておけば、初心者のうちは判断に困らない。
Macでのインストール

brew install redis
redis-server
redis-cli  # クライアント起動

代表的なコマンド: set, get, flushall, ttl, mset, mget, incr, decr, lpush, lrange, lpop, rpush, rpop, lrem, sadd, smembers, srem, zadd, zrange, zrem, hset, hget, hgetall, hdelなど
pub/subの例
1. サーバーを起動(redis-server)
2. クライアントAを起動し、チャンネルをsubscribeする
```
redis-cli
SUBSCRIBE sample_channel
```
1. クライアントBを起動し、チャンネルにPUBLISHする
```
redis-cli
PUBLISH sample_channel "Hello! World!"
```
1. クライアントA側で、クライアントBがPUBLISHしたメッセージが確認できる

ElastiCache

AWSのインメモリキャッシュに関するマネージドサービス。キャッシュエンジンはRedisとmemcachedが選択可能。ノード、シャード、クラスタの単位が存在する。
- ノード(Node): キャッシュサーバー。ElastiCacheの最小単位。選択したノードタイプによって性能(メモリやCPUなど)が異なる。
- シャード(Shard): ノードをまとめるグループ。1つのシャードにプライマリノード(読み書き可)1個と、リードレプリカ(読み込み専用)0〜5個を持つ。
- クラスタ(Cluster): シャードをまとめるグループ。クラスタごとにキャッシュエンジンを選択可能。クラスタモードは有効/無効を選択できる。
クラスタノード(レプリケーションも有効にした場合の構成)
- クラスタモード有効: クラスタ1つにシャード1〜15個。スケールアウト/スケールイン(シャード数を増減させる)。
```
クラスタ
  └Shard
    └Primary Node
      └Replica Node-1
      └Replica Node-n
  └Shard
    └Primary Node
      └Replica Node-1
      └Replica Node-n
```
- クラスタモード無効: クラスタ1つにシャード1個を持つ。
```
クラスタ
  └Shard
    └Primary Node
      └Replica Node-1
```
- スケールダウン(インスタンスタイプの変更など)はできない。
Multi-AZ
- t2以外のノードタイプであればMulti-AZが選択可能。ノードをMulti-AZに配置できる。
- 以前はmemcachedがMulti-AZに対応していなかったが、現在はmemcachedも対応したため、この点でのRedisの優位性は薄れている(?)。
障害発生時
- 障害発生時には自動フェイルオーバー(故障ノードから新しいノードへの切り替え)する機能が用意されている。
- プライマリノードが故障した場合: リードレプリカの1つ(複数ある場合は最も新しいデータを持つものが自動選択される)がプライマリノードに昇格する。フェイルオーバー中はプライマリノードへの書き込みは不可。昇格して減った分のリードレプリカは新しく補填される。
- リードレプリカが故障した場合: 新しいリードレプリカノードを自動生成し、故障したノードから切り替える。フェイルオーバー中の読み込み処理は他のノードに負荷が集中する。
- クラスタ全体が故障した場合: シャードもノードも自動で再作成される。永続化していない場合データは失われる(永続化は非推奨とされているため、どうしても永続化したいデータは定期的にRDBに格納する必要がある)。

レプリカノード・複数シャードを持つメリット

レプリカノードを持つメリット
- 可用性の向上: プライマリノード障害時にリードレプリカを昇格させ自動フェイルオーバーできる。プライマリ1台のみだと障害時にサービス全体が停止する。
- 読み取りの負荷分散: 読み取り専用クエリをレプリカに振り分けてプライマリの負荷を下げられる。
- 運用作業の分離: バックアップ取得など重い処理をレプリカ側で実行し、本番トラフィックが集中するプライマリへの影響を避けられる。
- データ消失リスクの低減: プライマリのみで永続化を無効にしている場合、ノード障害でメモリ上のデータが失われるが、レプリカがあれば直前までのデータを引き継げる(ただし非同期レプリケーションのため、障害直前の一部の書き込みは失われうる)。
複数シャードを持つ(クラスタモード有効時の)メリット
- メモリ容量の水平スケーリング: データを複数のプライマリに分散配置することで、1ノードのメモリ上限を超えるデータ量を扱える。
- 書き込みスループットの向上: 書き込みも各シャードのプライマリに分散されるため、シャード1つ(クラスタモード無効)ではレプリカを増やしても解決できない「書き込みの集中」を緩和できる。

読み書き時の内部動作(ハッシュスロット)

クラスタモード有効時、Redis Clusterはキー空間全体を16384個の「ハッシュスロット」に分割し、各シャードがその一部の範囲を担当する。
書き込み: CRC16(key) % 16384 でスロットを算出し、該当スロットを担当するシャードのプライマリに書き込む。プライマリは非同期でシャード内のレプリカへ複製する。
読み込み: 基本はプライマリから読むことでデータの一貫性を保証できる。クライアントをREADONLYモードにするとレプリカからも読めるが、非同期複製の遅延分だけ古いデータを読む可能性がある(結果整合性)。
クラスタモード無効の場合はシャードが1つのため上記のスロット計算は不要。「プライマリエンドポイント」に書き込み、「リーダーエンドポイント」(内部でレプリカへ自動的に振り分け)から読み取るだけのシンプルな構成になる。

スケールインとスケールダウンの違い

スケールイン: サーバーの台数を減らしてリソースを最適化すること。
スケールダウン: サーバーのCPUやメモリのスペックを下げて最適化すること。

クラスターモードの有効/無効とクライアントの対応

クラスターモードを有効にするとデータが複数シャードに分散し、キーの配置によってどのシャードにアクセスすべきかが変わる。Redis互換クライアントの多くはこの「シャード間のリダイレクト」(MOVEDエラー)に対応した専用のクラスタークライアントを使わないと正しく通信できない。
アプリ側が単純な単一ノードクライアントしか使っていない場合、クラスターモードを有効にすると接続エラーになる。クラスターモードを有効化する前に、アプリ側のクライアントライブラリがクラスター対応かどうかを必ず確認する。
クラスターモード無効のままでも、レプリカを配置してMulti-AZ自動フェイルオーバーを構成することは可能(スケールアウトはできないが高可用性は確保できる)。

RDBのレプリケーションとの比較

MySQLやPostgreSQLなどのRDBにも「プライマリ→レプリカへの非同期/準同期レプリケーション」「読み取りをレプリカに振り分けるリードレプリカ」という仕組みがあり、考え方自体はRedisと共通している。
大きく異なるのは処理の置き場所と得意分野。
- Redis/ElastiCache: 基本的にメモリ(RAM)上で完結する処理のため、単純なGET/SETはサブミリ秒(0.1〜1ミリ秒程度)で応答することが多い。
- RDB: ディスクI/Oを伴い、JOINやトランザクションなど複雑な処理が可能な代わりに、インデックスが効いた単純なSELECTでも数ミリ秒程度かかることが多い。
- (?) 具体的な数値はインスタンススペックやワークロードによって大きく変わるためあくまで目安だが、体感として1桁〜数十倍程度Redisの方が速いことが多い。
Redisが速いからRDBが劣っているわけではなく役割が異なる(RDBは複雑なデータ操作とデータの整合性・永続性の保証が主目的、Redisは単純なデータへの高速アクセスが主目的)。実務では「正のデータはRDBに置き、頻繁にアクセスされる一部だけRedisにキャッシュする」という併用が一般的。

保管時/転送時の暗号化

ElastiCacheは保管時の暗号化(ディスク上のデータ)と転送時の暗号化(クライアント-ノード間通信のTLS化)を別々に設定できる。転送時の暗号化を有効にする場合、接続文字列のスキームをredis://ではなくrediss://(TLS)にする必要がある。
自動フェイルオーバーを有効にするには、プライマリノードに対してレプリカが最低1台必要(レプリカが無いと切り替え先が無いため)。

ElastiCache Serverless

(?) 2023年以降に登場した比較的新しいモード。ノードタイプ・シャード数・レプリカ数を自分で設計する必要がなく、データ量とトラフィックに応じてAWS側が自動でスケールする。課金は使用したメモリ量とデータ処理量に応じた従量課金。
Aurora Serverless v2と発想が近い(容量を意識せず、使った分だけ課金される)。
デメリットとして、細かいパラメータグループのカスタマイズ余地が少ない、極端に大規模・高スループットな場合はプロビジョンド型(ノード/シャードを自分で指定する従来型)の方がコスト効率が良いことがある。
(IMO) 要件が固まっていない・まず動かしてみたい段階ではServerlessから始め、コストやパフォーマンス要件が明確になった段階でプロビジョンド型への切り替えを検討する、という進め方が現実的。

Valkeyについて

Redisのライセンス変更を受けて登場したOSSのフォークが「Valkey」。AWS ElastiCacheはRedis互換エンジンとしてValkeyを提供しており、既存のRedisクライアントライブラリからそのまま接続できる(プロトコル互換)。(執筆時点の情報のため、その後の状況変化に注意(?))

構成のユースケース例

クラスタモード無効で十分なケース
- 小規模Webアプリのセッションストア: データ量が数GB程度でノードのメモリに余裕で収まり、可用性さえ確保できれば良い場合。プライマリ1+レプリカ1(Multi-AZ)程度で足りる。
- 中規模ECサイトの商品情報・ランキングキャッシュ: データ量がまだ1ノードのメモリに収まり、読み取りが書き込みより多い場合。レプリカを2〜3台に増やして読み取りを分散するだけで十分にスケールする。
シャードが大量に必要なケース
- 大規模ソーシャルゲーム・SNSのリアルタイムデータ: データ量が数百GB〜TB級になり単一ノードのメモリ上限を超える、かつ書き込みも大量な場合。数十シャードに分割し、各シャードにプライマリ+レプリカを配置する。
- IoT・センサーデータのリアルタイム集計: 書き込みが常に大量でボトルネックになりやすい場合。シャード数がそのまま書き込みの並列度になるため、必要な書き込みスループットから逆算してシャード数を決める。
判断の目安
- 「全データが1台のメモリに収まるか」「書き込みが1台のプライマリで捌ける量か」がYesならクラスタモード無効で十分なことが多い。
- 要件が固まっていない場合はElastiCache Serverlessから始めるのも一案。

This site is open source. Improve this page.