Redis Persistence
Redisはデータをメモリに保存します。永続化はそのデータをディスクに保存します。このレッスンでは、RDBとAOFの永続化方法について解説します。
なぜ永続化が必要か
Redisはインメモリデータベースです：
- 問題：サーバーの再起動やクラッシュにより、メモリ内のデータが失われます
- 解決策：永続化により、メモリ内のデータをディスクに保存し、再起動後に復旧できます
メモリデータ → 永続化 → ディスクファイル
ディスクファイル → 復旧 → メモリデータ
Redisは2つの永続化方法を提供します：
- RDB：スナップショット — ある時点のデータを保存します
- AOF：ログ — すべての書き込み操作を記録します
RDB永続化
RDBとは
RDB（Redis Database）は、特定の時点のデータをバイナリスナップショットファイルとして保存します。
特徴：
- ある時点の完全なデータを保存
- コンパクトなファイル、バックアップと転送に適している
- 復旧速度が速い
- 最後のスナップショット以降のデータが失われる可能性がある
RDBの設定
redis.conf で設定：
CONF
# スナップショットのトリガー条件
# save <秒数> <変更数>
save 900 1 # 900秒以内に少なくとも1つの変更 → スナップショットをトリガー
save 300 10 # 300秒以内に少なくとも10の変更 → スナップショットをトリガー
save 60 10000 # 60秒以内に少なくとも10000の変更 → スナップショットをトリガー
# RDBを無効にする（saveをコメントアウトするか、空に設定）
# save ""
# RDBファイル名
dbfilename dump.rdb
# RDBファイルの保存ディレクトリ
dir /var/lib/redis
# RDB圧縮（オンを推奨）
rdbcompression yes
# RDBチェックサム（オンを推奨）
rdbchecksum yes
手動RDBトリガー
REDIS
# SAVE：ブロッキングスナップショット（本番環境では注意して使用）
SAVE
OK # スナップショット完了、この間Redisはブロックされていた
# BGSAVE：バックグラウンドスナップショット（推奨）
BGSAVE
Background saving started # すぐに返り、バックグラウンドで実行
⚠️ 補足： SAVEはスナップショットが完了するまでRedisをブロックします。BGSAVEはバックグラウンドで実行され、ブロックしません。
RDBファイルの場所
BASH
# デフォルトの場所
/var/lib/redis/dump.rdb
# または設定で指定されたディレクトリ
dir /data/redis
dbfilename dump.rdb
RDBの復旧
Redisは起動時に自動的にRDBファイルをロードします：
BASH
# 1. RDBファイルを設定されたディレクトリに配置
cp dump.rdb /var/lib/redis/
# 2. Redisを起動
redis-server
# Redisは自動的にdump.rdbをロードしてデータを復旧
RDBのメリットとデメリット
メリット：
- コンパクトなファイル、バックアップに適している
- 復旧速度が速い
- パフォーマンスへの影響が最小限（BGSAVEはバックグラウンド）
デメリット：
- 最後のスナップショット以降のデータが失われる可能性がある
- スナップショット間隔内のデータ損失
- 大規模データのスナップショットに時間がかかる
AOF永続化
AOFとは
AOF（Append Only File）はすべての書き込みコマンドを記録します。復旧時には、Redisがこれらのコマンドを再実行します。
特徴：
- すべての書き込み操作を記録、より安全なデータ
- 人間が読めるファイル、分析と修復が容易
- データの肥大化の可能性（書き換えが必要）
- 復旧速度が遅い
AOFの設定
CONF
# AOFを有効化
appendonly yes
# AOFファイル名
appendfilename "appendonly.aof"
# AOF同期戦略
appendfsync everysec
# AOF書き換え中にfsyncを無効化
no-appendfsync-on-rewrite no
# AOFファイルサイズが書き換えをトリガー
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
AOF同期戦略
| 戦略 | 説明 | パフォーマンス | 安全性 |
|---|---|---|---|
| always | 書き込みごとに同期 | 最も遅い | 最も安全 |
| everysec | 1秒ごとに同期 | 中程度 | 適度に安全（最大1秒のデータ損失） |
| no | OSに任せる | 最も速い | 最も安全でない |
💡 推奨：
appendfsync everysec — パフォーマンスと安全性のバランスが取れています。
AOFの書き換え
AOFファイルは継続的に大きくなります。書き換えにより圧縮します：
REDIS
# 手動でAOF書き換えをトリガー
BGREWRITEAOF
Background append only file rewriting started
書き換えの原則：
- 現在のメモリ内データを読み取る
- そのデータを復元するための最小限のコマンドセットを生成
- 古いAOFファイルを置き換える
書き換えのトリガー条件：
CONF
# 前回の書き換えからAOFファイルサイズが100％増加
auto-aof-rewrite-percentage 100
# AOFファイルが少なくとも64MB以上で書き換えをトリガー
auto-aof-rewrite-min-size 64mb
AOFの復旧
Redisは起動時に自動的にAOFファイルをロードします：
BASH
# 1. AOFファイルを設定されたディレクトリに配置
cp appendonly.aof /var/lib/redis/
# 2. Redisを起動
redis-server
# Redisは自動的にappendonly.aofをロードしてデータを復旧
AOFファイルの修復
BASH
# AOFファイルをチェック
redis-check-aof appendonly.aof
# AOFファイルを修復
redis-check-aof --fix appendonly.aof
AOFのメリットとデメリット
メリット：
- より安全なデータ、最大1秒のデータ損失
- 人間が読めるファイル、分析が容易
- 破損したファイルの修復をサポート
デメリット：
- ファイルサイズが大きい
- 復旧速度が遅い
- パフォーマンスへのある程度の影響
RDB vs AOFの比較
| 項目 | RDB | AOF |
|---|---|---|
| ファイルサイズ | 小さい（コンパクトなバイナリ） | 大きい（テキストコマンド） |
| 復旧速度 | 速い | 遅い |
| データ安全性 | 数分のデータ損失の可能性 | 最大1秒の損失 |
| パフォーマンス影響 | 低い（バックグラウンドスナップショット） | 中程度（頻繁なfsync） |
| ファイル可読性 | 読めない | 読める |
| 使用例 | バックアップ、レプリケーション | 高いデータ安全性要件 |
ハイブリッド永続化
Redis 4.0+はハイブリッド永続化をサポートしており、RDBとAOFの両方の利点を組み合わせます。
ハイブリッド永続化の設定
CONF
# AOFを有効化
appendonly yes
# ハイブリッド永続化を有効化
aof-use-rdb-preamble yes
ハイブリッド永続化の原則
AOF書き換え中：
- 最初に現在のデータをRDB形式で書き込む（高速、コンパクト）
- 次に新しい書き込み操作をAOF形式で追加する
AOFファイル構造：
[RDB形式のスナップショットデータ] + [AOF形式の増分コマンド]
ハイブリッド永続化の利点
- 高速な復旧（RDB部分）
- 安全なデータ（AOF部分）
- 適度なファイルサイズ
💡 推奨： Redis 4.0+では、パフォーマンスと安全性の両方を考慮してハイブリッド永続化を使用すべきです。
永続化のベストプラクティス
シナリオ1：キャッシュのみ
CONF
# キャッシュには永続化は不要、またはRDBのみ
save 900 1
appendonly no
シナリオ2：データストレージ
CONF
# データストレージにはAOFまたはハイブリッド永続化
save 900 1
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
シナリオ3：高可用性
CONF
# RDBとAOFの両方を有効化
save 900 1
save 300 10
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
バックアップ戦略
BASH
# 定期的にRDBとAOFファイルをバックアップ
# 1. cronを使用してファイルをコピー
0 2 * * * cp /var/lib/redis/dump.rdb /backup/dump-$(date +\%Y\%m\%d).rdb
0 2 * * * cp /var/lib/redis/appendonly.aof /backup/aof-$(date +\%Y\%m\%d).aof
# 2. BGSAVEでスナップショットを作成してからバックアップ
redis-cli BGSAVE
sleep 10 # スナップショット完了を待つ
cp /var/lib/redis/dump.rdb /backup/
復旧戦略
BASH
# RDBとAOFの両方が存在する場合、RedisはAOFを優先
# 1. Redisを停止
redis-cli SHUTDOWN NOSAVE
# 2. ファイルを復元
cp /backup/appendonly.aof /var/lib/redis/
# 3. Redisを起動
redis-server
永続化の監視
永続化状態の確認
REDIS
# RDBの状態を表示
INFO persistence
# 主要なメトリクス：
# rdb_last_save_time：最後のスナップショット時刻
# rdb_changes_since_last_save：最後のスナップショットからの変更数
# aof_enabled：AOFが有効かどうか
# aof_rewrite_in_progress：AOF書き換えが進行中かどうか
永続化パフォーマンスの監視
BASH
# RDBスナップショットの実行時間を監視
redis-cli INFO persistence | grep rdb_last_bgsave_time_sec
# AOF書き換えの実行時間を監視
redis-cli INFO persistence | grep aof_last_rewrite_time_sec
❓ よくある質問
Q RDBとAOFを同時に有効にできますか？
A はい。Redisは両方の方法を使用し、復旧時にはAOFを優先します。
Q 永続化方法の選び方は？
A キャッシュの場合はRDBまたは永続化なし。データストレージの場合はAOFまたはハイブリッド永続化。
Q AOFファイルが大きくなりすぎた場合は？
A BGREWRITEAOFを使用するか、自動書き換え条件を設定します。
Q 永続化はパフォーマンスに影響しますか？
A ある程度の影響があります。RDBの影響は小さく（バックグラウンドスナップショット）、AOFの影響は中程度です（頻繁なfsync）。
Q データ損失を最小限にするにはどうすればよいですか？
A appendfsync everysecのAOFを使用します。最大1秒のデータ損失です。
📖 まとめ
- RDBはスナップショット — ある時点のデータを保存
- AOFはログ — すべての書き込み操作を記録
- RDBは復旧が速くファイルが小さいが、データ損失の可能性がある
- AOFはより安全だが、ファイルが大きく復旧が遅い
- ハイブリッド永続化は両方の利点を組み合わせる（Redis 4.0+）
- キャッシュにはRDB、データストレージにはAOFまたはハイブリッド
- 永続化ファイルを定期的にバックアップし、パフォーマンスを監視
📝 練習問題
- RDB設定： 自動RDBスナップショット条件を設定し、手動でBGSAVEをトリガーしましょう
- AOF設定： AOFを有効にし、同期戦略間のパフォーマンスの違いをテストしましょう
- AOF書き換え： AOF書き換えをトリガーし、ファイルサイズの変化を観察しましょう
- データ復旧： RDB/AOFファイルをバックアップし、データ復旧をシミュレートしましょう
次のレッスン
次のレッスンでは、Redis Securityについて学びます。セキュリティ設定とアクセス制御を解説します。