「Redisは単なるキャッシュだ。消えてもいいデータを入れる場所だ」――もし君のチームにそんな甘い認識のエンジニアがいたら、即座にこの記事を突きつけてやってほしい。
私はこれまで、数多のミッションクリティカルな現場でRedisの崩壊と再生を見てきた。結論から言おう。Redisの永続化（Persistence）を制する者は、インメモリデータベースの圧倒的な速度と、RDBMSに匹敵する信頼性の「両取り」ができる。
今日は、ドキュメントの表面をなぞるだけでは決して辿り着けない、Redis永続化の極限の最適解を伝授する。
—
1. RDBとAOF：二項対立ではなく「役割の分担」
Redisの永続化にはRDB（Redis Database）とAOF（Append Only File）の2種類がある。初心者はよく「どちらを使うべきか？」と問うが、その問い自体がナンセンスだ。プロフェッショナルは「どう組み合わせるか」を考える。
RDB：ポイント・イン・タイムの「静止画」
RDBは指定した間隔でメモリ上の全データをバイナリとしてダンプする。
- メリット: 復旧速度が圧倒的に速い。ファイルサイズがコンパクト。
- リスク: 最後にダンプした瞬間からクラッシュするまでのデータは「完全に」消える。
- アーキテクトの視点: RDBは「バックアップ」および「災害復旧（DR）」のためのものだ。
AOF：書き込み履歴の「台帳」
実行されたコマンドを逐次追記していく。
- メリット: データ損失を最小限（デフォルト設定で最大1秒）に抑えられる。
- リスク: ファイルが巨大化し、再起動時の読み込み（リプレイ）に時間がかかる。
- アーキテクトの視点: AOFは「直近のデータ保護」のためのものだ。
—
2. 結論：ハイブリッド戦略こそが現代のスタンダード
Redis 4.0以降、我々が選ぶべき道は一つしかない。「RDBとAOFの併用、かつAOFの先頭にRDBを埋め込む（aof-use-rdb-preamble）」設定だ。
redis.conf の核心設定
1. AOFを有効化
appendonly yes
2. 書き込み同期タイミング（パフォーマンスと安全性のベストバランス）
everysec: 1秒ごとにfsync。OSのクラッシュでも最大1秒の損失で済む
appendfsync everysec
3. ハイブリッド・パーシステンス（これが最重要）
AOFリライト時に、ベース部分を高速なRDB形式で書き出す
aof-use-rdb-preamble yes
4. AOFリライトの自動実行閾値
サイズが100%増加、かつ最低64MB以上でリライト
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
この設定により、AOFの「堅牢性」を維持しつつ、再起動時にはRDB並みの「高速ロード」が可能になる。これが現代のRedis設計における「正解」だ。
—
3. パフォーマンスの地雷源：`fork()` と Copy-on-Write
ここからがシニアエンジニアの領域だ。永続化を設定した瞬間、君のRedisは「シングルスレッドの楽園」ではなくなる。
RDBの保存やAOFのリライト時、Redisは `fork()` システムコールを発行し、子プロセスを生成する。この時、Copy-on-Write (COW) が発生する。
- 罠: `fork()` した瞬間にメモリ使用量が理論上「最大2倍」に膨れ上がる可能性がある。
- 対策: OSレベルで `vm.overcommit_memory = 1` を設定するのは当然として、書き込みが激しい時間帯にリライトが重ならないよう、トラフィックのサージ（急増）を予測した設計が必要だ。
OSの設定確認。0や2なら、即刻 1 に変更せよ
sysctl vm.overcommit_memory=1
また、`latest_fork_usec` メトリクスを監視しろ。これが数百ミリ秒を超え始めたら、Redisが「停止」しているのと同義だ。インスタンスのメモリサイズを巨大化させすぎず、適切にシャーディング（水平分割）することで、1プロセスあたりの `fork()` コストを抑えるのが定石だ。
—
4. バックアップ運用指針：AOFがあるからと安心するな
AOFは「壊れる」ことがある。ディスクフルやハードウェア障害、あるいはバグによって。
「永続化設定をしているからバックアップはいらない」というのは、素人の発想だ。
プロフェッショナルなバックアップ・ルーチン
1. 定期的なRDBの外部退避:
1時間に1回、あるいは1日に1回、RDBファイルをS3やGCSなどのオブジェクトストレージへ転送せよ。
2. Point-in-Time Recoveryの準備:
RDBは「過去の特定の時点」に戻るためのタイムマシンだ。AOFではこれはできない（AOFは常に最新の状態を目指すため）。
3. 検証:
バックアップファイルが「本当に読み込めるか」を、別環境のRedisで定期的にリストアテストせよ。
—
5. まとめ：君が明日から守るべき鉄則
テクニカルリードとして、メンバーにはこう指示してほしい。
1. キャッシュ用途でもAOF/RDBを完全に切るな。 再起動時にウォームアップなしで全データが消えるリスクを許容できるケースは稀だ。
2. `appendfsync everysec` をデフォルトとせよ。 `always` は遅すぎ、`no` は危険すぎる。
3. `aof-use-rdb-preamble yes` は必須。 復旧時間の短縮は、SLA（サービス品質保証）に直結する。
4. 監視項目に `latest_fork_usec` と `aof_delayed_fsync` を加えろ。 パフォーマンス劣化の予兆はここに現れる。
Redisは、正しく設定すれば岩のように堅牢なシステム基盤となる。だが、デフォルト設定のまま放置すれば、高負荷時に牙を剥く。
アーキテクチャの細部に魂を込めろ。それが、我々エンジニアの責務だ。
コメント