Redisの永続化：メモリという「揮発性」への挑戦と、データ整合性の深淵
Redisを単なる「高速なキャッシュ」と呼ぶ者は、その真のポテンシャルを理解していない。Redisの真髄は、インメモリの速度を維持しながら、いかにして現代のストレージサブシステムと協調し、計算機科学的な「整合性」を担保するかに集約される。
本稿では、RDBとAOFという二つの永続化スキームを、単なる設定項目としてではなく、カーネルレベルのプロセス管理とファイルI/Oの最適化という観点から解体する。
—
1. RDB (Redis Database Backup)：Copy-on-Writeの魔術
RDBは、指定された間隔でデータセットのポイントインタイムスナップショットを作成する。多くのエンジニアが「`BGSAVE`を叩けばOK」と信じているが、その裏側で何が起きているかを理解せねばならない。
`fork()` と Copy-on-Write (CoW) の代償
`BGSAVE`が実行されると、Redisは `fork()` を呼び出す。ここで重要なのは、親プロセス（Redisメイン）のメモリ空間がコピーされるわけではないという点だ。OSレベルでのページテーブルの複製が行われる。
- CoWの罠: 書き込みが頻発するワークロードで `BGSAVE` を実行すると、親プロセスがページを更新するたびに、OSはページを物理的にコピーする。これがメモリ消費を急増させ、最悪の場合、OSのOOM Killerによるプロセス殺害を招く。
- アーキテクトの視点: 大規模データセットにおいて、RDBの頻繁な実行は、物理メモリの断片化とレイテンシスパイクを引き起こす。スナップショットの間隔は、単なる「復旧ポイントの許容度」ではなく、「システムのI/O帯域とメモリ変動率」の関数として設計すべきだ。
—
2. AOF (Append Only File)：ログ構造の正義
AOFは、すべての書き込みコマンドを順次追記する。これはデータベースエンジンの歴史において最も堅牢な手法の一つだ。
fsyncの戦略的選択
AOFの肝は `appendfsync` 設定にある。
- `always`: 全コマンドの完了を待ってディスク同期。整合性は最強だが、I/O待ちによるスループットの崩壊は避けられない。
- `everysec`: 1秒ごとのバックグラウンド同期。パフォーマンスと堅牢性のスイートスポット。
- `no`: OSのカーネルバッファに委ねる。Redisの性能は極大化するが、システムクラッシュ時に最大数秒のデータを喪失するリスクを負う。
極限の知見: `everysec` を選択した場合、ディスクのI/O遅延が1秒を超えると、Redisのメインループは書き込みをブロックする。これはRedisのシングルスレッドモデルにおける「隠れたボトルネック」だ。SSDの性能選定は、AOFの書き込みレイテンシがメインスループットに干渉しない限界値を算出することから始まる。
—
3. リストアの「真実」：データ回復のロジック
障害発生時、Redisは起動時に以下の優先順位でデータを読み込む。
1. AOFが存在する場合: AOFを再生し、メモリ上の状態を再構築する。
2. AOFが存在しない場合: RDBファイルをロードする。
リストア時の最適化と罠
リストアにおいて最も見落とされがちなのが、AOFリライト（`BGREWRITEAOF`）の重要性だ。
AOFファイルが肥大化した際の復旧時間の見積もり
AOFはログの蓄積であるため、長期間運用すると肥大化し、再起動時の読み込みに数十分を要する可能性がある。
以下の設定で、自動リライトを適切にトリガーさせる必要がある。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
復旧時間を最小化したいなら、RDBの定期実行とAOFの組み合わせが最強だ。RDBは高速な「ベースライン」を提供し、AOFは最後の数秒間の「デルタ」を埋める。
—
4. チーフアーキテクトからの提言
Redisにおけるバックアップとは、「データを保存すること」ではない。「計算機資源の制約の中で、ビジネスが許容するRPO（目標復旧時点）を最小のレイテンシペナルティで実現すること」である。
1. メモリオーバーコミットを無効化せよ: `/proc/sys/vm/overcommit_memory` を `1` に設定し、`fork()` が物理メモリ不足で失敗しないようにせよ。
2. I/O分離: RDBとAOFの書き出し先は、OSのメインディスクとは物理的に別のNVMe SSDにマウントせよ。
3. レプリケーションとの併用: 永続化に依存するな。Redis SentinelやClusterによる冗長化を前提とし、永続化はあくまで「最後の手札」と捉えるのが、高可用性設計の定石だ。
Redisは単なるデータストアではない。それはメモリ上で動く精密なエンジンだ。そのメカニズムを深く理解し、意図を持って設定を追い込んだとき、初めてエンジニアはRedisという兵器の真の力を引き出すことができる。
議論は以上だ。次は、君の現場の「I/O Wait」を見てから話をしよう。
コメント