【実務・中級編】障害復旧プロセス – Redis

Redisクラッシュからの生還：RDBとAOF、その「読み込み」の哲学と実践

皆さん、こんにちは。テクニカルリードの[あなたの名前]です。
本日は、Redisの運用において避けては通れない、しかし、その深淵に踏み込む者は少ない「障害復旧プロセス」、特にRedisクラッシュからのデータ復旧、すなわちRDBとAOFの読み込み戦略について、皆さんのシステムを磐石にするための知見を共有したいと思います。

「Redisが落ちた？大丈夫、バックアップからリストアすればいい」
そう思っているあなた。その「大丈夫」の裏側、Redisがどのようにしてメモリを再構築しているのか、その優先順位と手順を深く理解していますか？
単なるリファレンスではなく、実戦で磨き上げた「なぜそうなるのか」という哲学と、具体的な「どうやるのか」という実践を、今回は徹底的に掘り下げていきましょう。

1. Redisの「記憶」：RDBとAOFの役割再確認

まず、基本に立ち返りましょう。Redisの永続化メカニズムは、大きく分けてRDB (Redis Database) とAOF (Append Only File) の二つです。

RDB: スナップショットという「過去の証拠」
指定した間隔で、Redisのデータセット全体をバイナリ形式でディスクに保存します。
メリット：コンパクトで、リストアが高速。
デメリット：保存間隔によっては、最新のデータが失われる可能性がある。障害発生直前のデータが失われるリスクは、RDBの保存頻度と比例します。

AOF: 操作ログという「記録の連続」
Redisへの書き込みコマンドを逐次ログファイルに記録します。
メリット：データ損失のリスクがRDBより低い（`everysec`でも通常1秒以内のデータは復旧可能）。
デメリット：ファイルサイズが大きくなりやすく、リストアに時間がかかる場合がある。コマンドによっては、同一キーへの複数回書き込みのログが蓄積されるため、最適化（rewrite）が必要。

どちらも「データを失わないための仕組み」であることに変わりはありませんが、その「記憶の仕方」と「再生の仕方」が異なります。この違いが、クラッシュ後の復旧プロセスにおける優先順位と手順に決定的な影響を与えます。

2. クラッシュからの「目覚め」：Redisの再起動と永続化ファイルの読み込み

Redisサーバーがクラッシュし、再起動を試みる際、Redisは永続化ファイル（RDBとAOF）の存在を検知すると、それらを読み込んでメモリ状態を再構築しようとします。ここで重要なのは、Redisがどのような優先順位でこれらのファイルを読み込むか、という点です。

2.1. AOFが有効な場合の「絶対的優位性」

結論から申し上げます。AOFが有効になっており、かつAOFファイルが存在する場合、RedisはRDBファイルよりもAOFファイルを優先して読み込みます。

なぜでしょうか？

それは、AOFが「操作の連続性」を記録しているからです。Redisの設計思想として、障害発生時のデータ損失を最小限に抑えることが最優先されます。AOFは、RDBよりも粒度の細かい操作ログであるため、より最新の状態に近いデータを復旧できる可能性が高いのです。

Redisは、起動時に以下の手順で永続化ファイルを処理します。

1. AOFファイルが存在し、有効になっているか確認する。
2. もしAOFファイルが存在し、有効であれば、AOFファイルを読み込み、そこに記録されているコマンドを順次実行してメモリ状態を再構築する。
3. AOFファイルが存在しない、あるいは無効な場合、RDBファイルが存在するか確認する。
4. もしRDBファイルが存在すれば、RDBファイルを読み込み、そのスナップショット時点のメモリ状態を再現する。
5. どちらのファイルも存在しない、あるいは読み込みに失敗した場合は、空のメモリ状態で起動する。

このロジックは、Redisのソースコード（`loadData`関数など）にも明確に記述されています。

2.2. RDBとAOFの「併用」における現実

RDBとAOFを併用している構成は非常に一般的です。しかし、この併用構成でクラッシュが発生した場合、RedisはAOFを優先するため、RDBファイルは事実上、AOFの読み込みが完了した後に、その整合性を確認するために使われる、という位置づけになります。

具体的には、AOFの読み込みが完了し、Redisが正常に起動した後に、RedisはRDBファイルと比較して、両者の間で整合性が取れているか（例えば、AOFの最終書き込み時刻がRDBの生成時刻よりも後であるかなど）をチェックすることがあります。しかし、これはあくまで後続のチェックであり、起動時のデータ復旧プロセスにおいてはAOFが「主役」です。

3. 堅牢な設計パターン：障害復旧の「哲学」と「実装」

では、このRedisの「読み込み」の優先順位を理解した上で、どのような設計パターンを適用すべきでしょうか。

3.1. 漆黒の闇からの「希望」：AOFの「fsync」設定の選択

AOFのデータ損失リスクを最小限にするためには、`appendfsync` の設定が極めて重要です。

`appendfsync always`:
哲学: 「一瞬たりともデータを失わない」という究極のデータ保全。
実装: 全ての書き込みコマンドの後に `fsync` を実行します。
メリット: ほぼゼロデータロス。
デメリット: パフォーマンスへの影響が最も大きい。ディスクI/Oがボトルネックになりやすい。
適用シーン: 金融取引、リアルタイムオークションなど、一瞬のデータ損失も許されないシステム。

`appendfsync everysec`:
哲学: 「許容できる範囲でのパフォーマンスとデータ保全のバランス」。
実装: 1秒に1回、バッファリングされた書き込みコマンドをディスクに `fsync` します。
メリット: パフォーマンスとデータ保全のバランスが良い。多くのユースケースで推奨される設定。
デメリット: 最大で1秒程度のデータ損失の可能性。
適用シーン: ほとんどのWebアプリケーション、キャッシュ、セッション管理など。

`appendfsync no`:
哲学: 「パフォーマンス最優先。OSのディスクキャッシュに委ねる」。
実装: `fsync` を定期的に実行しません。OSがバッファリングしたデータを、OSの判断でディスクに書き込みます。
メリット: パフォーマンスが最も良い。
デメリット: Redisプロセスがクラッシュしたり、OSがクラッシュしたりすると、ディスクに書き込まれる前のデータはほぼ確実に失われます。
適用シーン: 完全に失われても問題ない一時的なデータ、またはRDBで定期的にバックアップを取っており、AOFは「保険」程度にしか考えていない場合。ただし、この設定は推奨されません。

実務上の推奨:
特別な理由がない限り、`appendfsync everysec` を推奨します。これにより、ほとんどのクラッシュシナリオで、失われるデータは最大でも1秒分に抑えられます。`always` は、そのパフォーマンスコストに見合うだけの、データ損失に対する絶対的な耐性が求められる場合にのみ検討すべきです。

3.2. AOF Rewriteによる「スリム化」と「高速化」

AOFファイルは、操作ログを蓄積していくため、時間とともに肥大化します。これを放置すると、ディスク容量を圧迫するだけでなく、起動時のAOF読み込み時間が長くなり、復旧プロセスが遅延する原因となります。

Redisは、この問題を解決するために AOF Rewrite という仕組みを提供しています。
AOF Rewriteは、現在のメモリ状態を代表する最小限のコマンドセットを、新しいAOFファイルとして再生成するプロセスです。

手動実行: `BGREWRITEAOF` コマンド
自動実行:
`auto-aof-rewrite-percentage`: AOFファイルのサイズが、前回のRewrite時（または初期状態）から指定した割合以上増加した場合に自動でRewriteを実行します。
`auto-aof-rewrite-min-size`: Rewriteを実行する最低限のAOFファイルサイズを設定します。

堅牢な設計パターン:

1. AOFを有効にし、`appendfsync everysec` を設定する。
2. `auto-aof-rewrite-percentage` と `auto-aof-rewrite-min-size` を適切に設定し、AOF Rewriteが定期的に（またはサイズに応じて）実行されるようにする。

例えば、`auto-aof-rewrite-percentage 100`（サイズが倍になったらRewrite）や、`auto-aof-rewrite-min-size 64mb`（最低でも64MB以上になったらRewrite）といった設定が考えられます。

3. RDBスナップショットも定期的に取得する。

RDBは、AOFファイルが破損した場合の「最終防衛線」としての役割や、リストアの高速化（AOFファイルが非常に大きい場合、RDBからのリストア＋AOFの適用の方が高速になることがある）にも貢献します。

この「AOFによる高頻度なデータ保全」と「RDBによる定期的なスナップショット」、そして「AOF Rewriteによるファイルサイズの最適化」の組み合わせが、Redisの障害復旧プロセスを極めて堅牢にします。

4. パフォーマンス上の注意点：犠牲になるもの、得るもの

「AOFを有効にするとパフォーマンスが落ちる」という話を聞いたことがあるかもしれません。これは、特に `appendfsync always` の場合、あるいはディスクI/Oがボトルネックになっている環境では事実です。

しかし、`appendfsync everysec` を使用する場合、そのパフォーマンスへの影響は限定的であることがほとんどです。 多くの現代的なストレージ（SSDなど）では、1秒間に1回の `fsync` は、システム全体のスループットに深刻な影響を与えるほどではありません。

注意すべき点:

ディスクI/O: RedisサーバーのディスクI/O性能が低い場合、AOFの書き込みがボトルネックになる可能性があります。その場合は、より高速なストレージへの移行や、AOF Rewriteの頻度調整（Rewrite中にI/O負荷が増大するため）を検討する必要があります。
Redisのメモリ使用量: AOF Rewriteは、新しいAOFファイルを生成するために、ある程度のメモリを一時的に消費します。また、RedisはRewrite中に元のAOFファイルを保持し、変更を差分として記録するため、一時的にメモリ使用量が増加する可能性があります。
RDBとAOFの併用: 両方を有効にすると、Redisは両方の永続化処理を実行するため、わずかにCPUやI/Oリソースを消費します。しかし、そのトレードオフとして得られるデータ保全性の向上は、多くの場合、そのリソース消費に見合う価値があります。

5. まとめ：Redisクラッシュからの「生還」は「設計」で決まる

Redisがクラッシュした際、RDBとAOFのどちらが優先されるか。それは、AOFが有効であればAOFが優先される、というシンプルな事実です。しかし、その背後にあるRedisの「データ保全」という哲学、そしてAOFの`fsync`設定やRewriteといった詳細なメカニズムを理解することが、皆さんのシステムを真に堅牢にする鍵となります。

AOFを有効にし、`appendfsync everysec` を基本とする。
AOF Rewriteを適切に設定し、ファイルサイズの肥大化を防ぐ。
RDBスナップショットも併用し、多層的なデータ保護を行う。

これらの実践に加えて、RedisのレプリケーションやSentinel、Clusterといった高可用性構成を組み合わせることで、障害発生時のダウンタイムを最小限に抑え、サービスレベルを維持することが可能になります。

Redisの永続化は、単なる「バックアップ」ではありません。それは、データベースとしての「記憶」であり、「信頼」そのものです。本日の知見が、皆さんのシステム設計、そして障害復旧プロセスに、確かな光をもたらすことを願っています。

ご質問やご意見があれば、お気軽にどうぞ。