RedisのRDBスナップショット、AOF記録、復旧条件

RedisはRDBスナップショット、追記専用ファイル（Append Only File、AOF）、両方、または永続化なしで運用できます。RDBは設定条件や手動操作で、ある時点のデータセットをファイルに保存します。バックアップや移行に便利ですが、最後の成功したスナップショット以後の変更は障害後に戻らない可能性があります。AOFは変更コマンドを記録し、起動時に再実行します。両方を有効にした場合の起動時の優先順位やファイル形式はRedisのバージョンと設定に依存するため、利用リリースの文書を確認します。

Redisの技術資料が示す運用上の選択

Redisが公開するRDBとAOFの比較資料は、許容損失と性能要件に応じて永続化方式を選ぶよう説明しています。appendfsync everysecは通常およそ1秒ごとのfsyncを要求するよく使われる折衷案ですが、障害時に損失が必ず正確に1秒以内になる保証ではありません。OSのスケジュール、障害の種類、ファイルシステム、記憶装置のflush動作が影響します。appendfsync alwaysもコマンドの一括処理後、reply前の同期を要求しますが、あらゆるハードウェア・ストレージ障害に対する完全無損失保証ではありません。レプリケーションとバックアップは別の保護策です。

スナップショットとAOFの書き換えの運用コスト

バックグラウンドで実行するBGSAVEとAOFの書き換えは子プロセスをforkする場合があります。親プロセスと子プロセスは最初メモリーページを共有しますが、その後の書き込みでコピーオンライト（Copy-on-Write）が起き、書き込み率や負荷によってメモリー使用量のピークが増えます。fork自体もデータセット量やOS条件に応じてリクエスト処理を一時停止させます。どの環境にも当てはまる安全なメモリー余裕率はありません。代表的な負荷で最大RSS、forkにかかる時間、CoW増加、空きディスク容量を測定してください。AOFの書き換えは現在状態をより簡潔に表すログへ再構成する処理で、全コマンドの不変な監査記録ではありません。

バックアップ、レプリケーション、復旧を実地確認

RDBやAOF ファイルだけでフェイルオーバーや特定時点への復旧まで解決するわけではありません。レプリケーションは可用性向上に役立ちますが、非同期レプリケーションには障害時の遅延・損失可能性が残ります。ファイルの整合性、別ホストへのバックアップ、Redis本体とモジュールのバージョン互換性、復元所要時間、フェイルオーバー手順を試験してください。Redis SoftwareとRedis Open Sourceでは設定可能項目が異なる場合があるため、製品ごとの説明を参照します。目標復旧時点（RPO）を定義してfsyncの頻度とスナップショット間隔を選び、復元訓練で結果を検証します。

復旧時刻を当てはめる仮想例

Redis 7.xの単一インスタンスでRDBのみを使うと仮定します。成功したRDBが表す論理的なデータ時点を12:00、その時点のjob:doneを40と仮定します。バックグラウンドでのファイル保存はその後も続くことがあるため、保存完了時刻とスナップショットが表すデータ時点は区別します。12:02に41、12:04に42へ更新され、次のRDBが完了する前の12:05に障害が起きると、復旧元は論理データ時点が12:00のスナップショットから復旧するため、値は40になります。後の更新41と42はそのファイルに含まれません。数値は時系列を示すための仮想例で、実際の損失はスナップショット完了時刻と障害条件によります（Redis persistence documentation）。

AOFのappendfsync everysecは通常およそ1秒ごとの同期を要求する方針であり、あらゆる障害で損失が正確に1秒以内になる保証ではありません。Redis文書はバッファリング、fsync、OSやストレージの動作を説明しています。この設定を全障害の種類の確定上限として扱わないでください。RPOが重要なら、設定だけで判断せず、隔離した復旧試験で復元キーとアプリケーションの不変条件を照合します。

復旧確認では次の項目を記録できます。

  1. バックアップまたはAOF一式を元データと分離して複製し、チェックサム、サイズ、作成時刻を記録します。Redis 7以降の複数ファイル構成のAOFでは、任意の一部ではなくmanifestが参照するファイル一式を保全します。
  2. 本番を上書きせず、同じRedisのリリースと必要なモジュールを備えた隔離環境で復元します。読み込みエラー、末尾切り詰めの警告、永続化の状態を記録します。
  3. バックアップ時点で期待されるキーと値とアプリケーションの不変条件を検査します。キー総数が一致しても値の正しさまでは証明しません。
  4. 代表的な読み書き経路、復旧所要時間、フェイルオーバー手順を試します。バックアップ時刻と試験で確認した範囲を残します。

これは試験漏れを防ぐ運用チェックリストです。試験なしに整合性や復旧可能性を保証するものではありません。

参考資料