解説

なぜ永続化が必要なのか

インメモリの特性

プロセス停止でデータ消失

永続化

メモリ上のデータをディスクに保存する仕組み

2 つの方式

RDB スナップショットと AOF

RDB

AOF

比較と選択

まとめ

解説

RDB スナップショットとは

RDB スナップショット

ある時点のデータセット全体をバイナリファイルに保存

保存先: dump.rdb

定期的に自動実行、または手動で実行

RDB

AOF

比較と選択

まとめ

解説

RDB の仕組み — fork と copy-on-write

fork

Redis が子プロセスを作成

copy-on-write

親子でメモリページを共有し、書き込み時だけコピー

子プロセスがデータをファイルに書き出す間、親プロセスはリクエスト処理を継続

RDB

AOF

比較と選択

まとめ

図解

RDB スナップショットの仕組み

fork と copy-on-write によるバックグラウンド保存

RDB

AOF

比較と選択

まとめ

コマンド

redis.conf の save ディレクティブ

redis.conf で RDB スナップショットの自動保存条件を設定する

save <秒数> <変更数>

save 3600 11 時間に 1 回以上の変更で保存

save 300 1005 分に 100 回以上の変更で保存

save 60 100001 分に 10000 回以上の変更で保存

save "" で RDB を無効化

RDB

AOF

比較と選択

まとめ

コマンド

BGSAVE と SAVE

$ BGSAVE
$ SAVE

BGSAVEバックグラウンドでスナップショットを実行（推奨）

SAVEフォアグラウンドで実行（全クライアントをブロック）

LASTSAVE最後にスナップショットが保存された時刻を返す

自動保存も内部的には BGSAVE と同じ仕組み

RDB

AOF

比較と選択

まとめ

実演

RDB スナップショットの確認

目的BGSAVE を実行し、dump.rdb が生成されることを確認する

実行する
コマンド

$ BGSAVE
$ LASTSAVE

確認する
ポイントBGSAVE が即座に応答を返し、バックグラウンドで完了すること

RDB

AOF

比較と選択

まとめ

解説

RDB のメリットとデメリット

メリット

コンパクトなバイナリ / 復元が高速 / パフォーマンス影響が小さい

デメリット

スナップショット間のデータ損失 / 大規模データで fork に時間がかかる

RDB

AOF

比較と選択

まとめ

解説

AOF とは

AOF（Append Only File）

すべての書き込みコマンドをログとして追記

再起動時にコマンドを再実行してデータを復元

redis.conf で appendonly yes を設定して有効化

RDB

AOF

比較と選択

まとめ

解説

redis.conf の appendfsync 設定

redis.conf で AOF の fsync タイミングを制御する

appendfsync always

毎コマンド後に fsync（最も安全・最も遅い）

appendfsync everysec

1 秒ごとに fsync（デフォルト・推奨）

appendfsync no

OS に任せる（最も速い・最大 30 秒のデータ損失）

RDB

AOF

比較と選択

まとめ

解説

AOF の書き換え（リライト）

AOF ファイルは追記し続けるため、肥大化する

BGREWRITEAOF

現在のデータセットを再現する最小限のコマンド列に書き換え

redis.conf で自動リライトの条件を設定

auto-aof-rewrite-percentage / auto-aof-rewrite-min-size

RDB

AOF

比較と選択

まとめ

解説

Redis 7.0 以降の AOF 構造

Redis 7.0 以降: マルチパート AOF

ベースファイル / インクリメンタルファイル / マニフェストファイル

3 種類のファイルで構成

redis.conf の appenddirname で指定したディレクトリにまとめて格納

RDB

AOF

比較と選択

まとめ

図解

マルチパート AOF 構造

ベース・インクリメンタル・マニフェストの連携

RDB

AOF

比較と選択

まとめ

実演

AOF の有効化と確認

目的AOF を有効にしてコマンドがログに記録されることを確認する

操作appendonly yes で起動 → SET / INCR → AOF ファイルを確認

確認する
ポイント実行したコマンドが AOF ファイルに追記されていること

RDB

AOF

比較と選択

まとめ

実演

BGREWRITEAOF の実行

目的AOF のリライトでファイルが最適化されることを確認する

実行する
コマンド

$ BGREWRITEAOF

確認する
ポイントリライト後、冗長なコマンドが除去されてファイルが小さくなること

RDB

AOF

比較と選択

まとめ

解説

AOF のメリットとデメリット

メリット

データ損失が最小（everysec で最大 1 秒）/ 可読性が高い / 破損リスクが低い

デメリット

RDB より復元が遅い / ファイルサイズが RDB より大きい

RDB

AOF

比較と選択

まとめ

図解

RDB と AOF の比較

観点

RDB

AOF（everysec）

データ損失

最後のスナップショット以降

最大 1 秒

ファイルサイズ

コンパクト

大きい

復元速度

高速

やや遅い

パフォーマンス影響

fork 時のみ

継続的な書き込み

バックアップ

ファイルコピーのみ

リライト中は注意

RDB

AOF

比較と選択

まとめ

図解

RDB と AOF の特性比較

RDB と AOF の得意分野の違い

RDB

AOF

比較と選択

まとめ

解説

ハイブリッド構成（RDB + AOF）

redis.conf: aof-use-rdb-preamble yes（デフォルト有効）

AOF リライト時のベースファイルを RDB 形式で保存

起動時: RDB 部分を高速読み込み → 差分の AOF コマンドを再実行

RDB の復元速度と AOF の安全性を両立

RDB

AOF

比較と選択

まとめ

図解

ハイブリッド構成の復元フロー

RDB 読み込み + AOF 差分再実行の復元フロー

RDB

AOF

比較と選択

まとめ

図解

永続化戦略の選択基準

用途

推奨構成

理由

一般的な本番環境

RDB + AOF

安全性と復元速度の両立

バックアップ重視

RDB + AOF

RDB でバックアップ、AOF で安全性

純粋なキャッシュ

なし or RDB のみ

データ損失が許容できる

最大限のデータ保護

AOF（always）

パフォーマンスを犠牲に安全性最優先

RDB

AOF

比較と選択

まとめ

実演

Docker Compose で永続化設定

目的RDB + AOF のハイブリッド構成でデータが永続化されることを確認する

操作appendonly yes で起動 → SET → コンテナ再起動 → GET で確認

確認する
ポイントコンテナ再起動後もデータが保持されていること

RDB

AOF

比較と選択

まとめ

解説

永続化を無効にする場合

キャッシュ専用なら永続化は不要

redis.conf: save "" + appendonly no

メリット: ディスク I/O がなくなり、パフォーマンスが最大化

RDB

AOF

比較と選択

まとめ

補足

RDB と AOF の同時有効化時の動作

RDB と AOF が両方有効な場合、再起動時は AOF が優先される

AOF の方がデータの完全性が高いため

RDB と AOF の保存処理は同時に実行されない

Redis が制御

RDB

AOF

比較と選択

まとめ

この章のまとめ

✓RDB はスナップショット方式。コンパクトで復元が速い

✓AOF はコマンドの追記ログ。データ損失が最小限

✓ハイブリッド（RDB + AOF）が推奨構成

✓永続化なしはキャッシュ専用で許容できる場合のみ

次章: キャッシュ設計パターン

RDB

AOF

比較と選択

まとめ