Redis

Redis とは

Redis (Remote Dictionary Server) は、2009 年に Salvatore Sanfilippo が公開したインメモリデータストアである。全データをメモリ上に保持するため、読み書きがマイクロ秒〜ミリ秒単位で完了する。

コマンドの実行は単一スレッドで直列化される。そのため個々のコマンドが割り込まれずに完了する一方、大きなキーを丸ごと走査するコマンドが 1 本入ると、その間ほかの要求はすべて待たされる。io-threads を設定するとネットワークの読み書きとプロトコル解析だけは複数スレッドへ振り分けられるが、既定では無効で、コマンド本体の実行は常に 1 スレッドである。

ライセンスは途中で変わっている。7.2 以前は BSD 3 条項ライセンスだが、Redis 8 以降は Redis Source Available License v2 / Server Side Public License v1 / GNU Affero General Public License v3 の 3 つから選ぶ形式になった (2026 年 8 月時点)。BSD ライセンスのまま開発が続く系統としては Linux Foundation が支援する Valkey があり、同じコマンド体系で使える。「Redis はオープンソース」と一括りにせず、採用時は使うバージョンの条項を確認する。

AWS では Amazon ElastiCache (エンジンを Valkey・Redis OSS・Memcached から選択) と Amazon MemoryDB (Valkey および Redis OSS 互換) として利用できる。

データ構造

Redis の強みは、単純な Key-Value だけでなく多彩なデータ構造をネイティブにサポートする点にある。

データ構造	用途	コマンド例
String	キャッシュ、カウンター	SET key value / INCR counter
Hash	オブジェクトの格納	HSET user:1 name "Alice"
List	キュー、タイムライン	LPUSH queue task1 / RPOP queue
Set	ユニーク集合、タグ	SADD tags "aws" / SMEMBERS tags
Sorted Set	ランキング、スコアボード	ZADD leaderboard 100 "player1"
Stream	イベントログ、メッセージング	XADD events * type "order"

キャッシュ戦略

キャッシュ設計で最初に決めるのは、どこを正データとし、書き込みをいつキャッシュへ反映するかである。代表的な 3 方式を整合性の強さ順に並べる。

戦略	読み取り	書き込み	整合性
Cache-Aside	アプリがキャッシュを確認→ミスなら DB から取得→キャッシュに書く	DB に書く→キャッシュを無効化	結果整合性
Write-Through	キャッシュから読む	キャッシュと DB に同時に書く	強い整合性
Write-Behind	キャッシュから読む	キャッシュに書く→非同期で DB に反映	結果整合性

Lambda + DynamoDB 構成では Cache-Aside が最も一般的。TTL を設定してキャッシュの鮮度を管理する。

ElastiCache vs MemoryDB

どちらも同じコマンド体系を提供するが、データの正をどこに置くかが違う。判断の分かれ目になる 4 観点で並べる。

観点	Amazon ElastiCache	Amazon MemoryDB
用途	キャッシュ (耐久性を有効にすればデータストアとしても使える)	プライマリ DB
耐久性	既定は障害時にデータが失われる前提。Valkey 9.0 以降は Multi-AZ トランザクションログによる耐久性を選択できる (既定はオフ・Graviton 系インスタンスとクラスターモード + Multi-AZ が条件)	Multi-AZ トランザクションログに常時記録
レイテンシ	読み書きともマイクロ秒 (同期書き込みを選ぶと書き込みは 1 桁ミリ秒)	マイクロ秒 (読み取り)、1 桁ミリ秒 (書き込み)
コスト	低い (同期書き込みは追加料金)	高い

元データを取得元から作り直せるキャッシュなら耐久性なしの ElastiCache、失うと処理が壊れるデータを持たせるなら MemoryDB か同期書き込みを有効にした ElastiCache を選ぶ。2026 年 8 月時点では両者の機能が重なってきているため、どちらでも成立する構成では料金と運用の手数で決めることになる。

永続化

インメモリでも再起動でデータが消えるとは限らない。方式は 2 つある。

• RDB (スナップショット): データセット全体を dump.rdb へ書き出す。既定の保存条件は「1 時間で 1 件以上」「5 分間で 100 件以上」「1 分間で 1 万件以上」の変更で、子プロセスを fork して書き出すため親プロセスの応答は止まらない。反面、直近のスナップショット以降の書き込みは障害時に失われる。
• AOF (追記ログ): データを変更したコマンドをファイルへ追記し、起動時に再生して状態を復元する。既定は無効 (appendonly no) で、有効にすると fsync の頻度を「毎コマンド」「1 秒ごと」「OS に任せる」から選ぶ。既定の 1 秒ごとなら失う範囲は最大 1 秒分に収まる。ログは自動で書き換えられ、7.0 以降はベースファイルと増分ファイルの複数構成になっている。

両方を同時に有効にできる。起動時は耐久性の高い AOF が優先して読み込まれるため、バックアップの持ち運びは RDB、障害時の欠損の小ささは AOF という住み分けになる。

Pub/Sub

Redis の Pub/Sub はリアルタイム通知に使える。パブリッシャーがチャンネルにメッセージを送信し、サブスクライバーが受信する。ただし永続化されないため、メッセージの確実な配信が必要な場合は Redis Streams または SQS/SNS を使う。

よくある落とし穴

• メモリ枯渇: 64 ビット環境では maxmemory の既定値が 0 (無制限) で、上限を決めなければホストのメモリを使い切るまで伸びる。上限到達後の挙動は maxmemory-policy が決め、既定の noeviction では新たにメモリを要求する書き込みがエラーになる。キャッシュとして使うなら allkeys-lru (最近使われていないキーから追い出す) か allkeys-lfu (使用頻度の低いキーから追い出す) を明示的に指定し、レプリケーションや永続化を使う場合はバッファの分だけ RAM を空けておく
• ホットキー: 特定のキーにアクセスが集中すると、そのノードがボトルネックになる。キーの分散設計が重要
• 大きな値: 1 つのキーに数 MB のデータを格納すると、ネットワーク帯域とレイテンシに影響する

関連書籍も参考になる。