Redis永続化オプション：RDB vs AOFの解説

Redisの永続化は、サーバー再起動やクラッシュ後にRedisサーバーがどれだけのデータを復元できるかを決定します。主なオプションはRDBスナップショットとAOFログの2つで、適切な選択はアプリケーションが失っても許容できる最新データの量に依存します。

Redisは速度のためにデータをメモリに保持します。永続化は、Redisが後でデータを再構築できるように、十分な状態をディスクに書き込みます。RDB、AOF、両方、またはどちらも使用しないことができますが、本番システムでは意図的に選択する必要があります。

Redisの永続化を理解する

Redisにおける永続化とは、メモリ内データセットの現在の状態をディスクに書き込むプロセスを指します。これにより、サーバー再起動時にRedisがデータを再読み込みできます。永続化を有効にしないと、シャットダウン時にすべてのデータが失われます。

RedisはRDBとAOFを同時にサポートしており、両方の最良の機能を組み合わせたハイブリッドアプローチを提供します。

RDBスナップショット

RDBはデータセットの特定時点のスナップショットを作成し、一般的にdump.rdbという名前のコンパクトなバイナリファイルに書き込みます。

RDBの仕組み

RDBは通常、Redisプロセスをフォークすることで動作します。子プロセスがデータセットをディスクに書き込む間、親プロセスはクライアントへのサービスを続けます。RDBはスナップショットであるため、ある瞬間のデータをキャプチャします。

設定とスナップショット作成

RDBの設定はredis.confのsaveディレクティブで管理されます。これらのディレクティブは、Redisが自動スナップショットを作成するタイミングを定義します：

# 1分間に1000個のキーが変更された場合にDBを保存
save 600 1000
# 10分間に10個のキーが変更された場合にDBを保存
save 300 10
# 1秒間に10000個のキーが変更された場合にDBを保存
save 1 10000

自動RDBスナップショットを無効にするには、saveディレクティブを削除するか、次のように設定します：

save ""

必要に応じて、BGSAVEで手動でバックグラウンドスナップショットをトリガーすることもできます。

RDBの利点

コンパクトなファイル： RDBファイルはバックアップ、コピー、災害復旧アーカイブに効率的です。
高速な復元： 1つのスナップショットをロードするのは、通常、長いコマンドログを再生するよりも高速です。
安定した書き込みオーバーヘッドの低さ： Redisはすべてのコマンドを永続化ファイルに書き込むわけではありません。

RDBの欠点

データ損失のリスク： スナップショット間にRedisがクラッシュすると、最後の成功したスナップショット以降の書き込みが失われます。
フォークのオーバーヘッド： 大規模なデータセットではfork()が高コストになり、レイテンシのスパイクを引き起こす可能性があります。
完全な監査ログではない： RDBは最終状態を保存しますが、それに至るすべての書き込みは保存しません。

AOFログ

AOF（追記専用ファイル）は、より高いレベルのデータ耐久性を提供します。スナップショットの代わりに、AOFはサーバーが受信したすべての書き込み操作を追記専用形式でログに記録します。

AOFの仕組み

AOFが有効な場合、RedisはSET、HSET、LPUSHなどの書き込みコマンドを追記専用ファイルに記録します。再起動時に、Redisはそのファイルを再生してデータセットを再構築します。

AOF設定

AOF永続化はデフォルトで無効になっており、redis.confで明示的に有効にする必要があります：

appendonly yes

重要なのは、AOFではfsyncポリシーを設定でき、書き込みをディスクに強制する頻度を決定することです：

fsyncポリシー	説明	耐久性 vs パフォーマンス
`no`	OSが同期を処理（最も頻度が低い）。	最速、損失リスクが最も高い。
`everysec`	約1秒ごとに同期。	良いバランス。通常、サーバークラッシュ時の損失を約1秒に制限。
`always`	すべてのコマンドの後に同期。	最高の耐久性、パフォーマンスに大きな影響を与える可能性あり。

AOFの利点

より高い耐久性： appendfsync everysecは一般的な本番バランスです。alwaysはより厳格ですが低速です。
読み取り可能な意図： AOFは書き込みコマンドを保存するため、RDBバイナリファイルよりも検査が容易です。
自動圧縮： AOFの書き換えにより、大きなログを現在の状態を再構築するために必要な最小限のコマンドに縮小できます。

AOFの欠点

より大きなファイル： AOFファイルはコマンドを保存するため、RDBスナップショットよりも大きくなることが多い。
再起動が遅い： 長いAOFを再生するのは、RDBスナップショットをロードするよりも時間がかかることがあります。
書き込みオーバーヘッドが大きい： Redisは書き込みコマンドを追加し、appendfsync設定に従って同期する必要があります。

AOF書き換え

ファイルサイズの増大に対抗するため、RedisはAOF書き換えを実装しています。このプロセスは非同期で、現在の状態に到達するために必要なコマンドのみを含む、新しい最適化されたAOFファイルを作成し、冗長または廃止されたコマンド（同じキーへの複数の更新など）を効果的に破棄します。

RDB vs AOF：直接比較

RDB、AOF、または両方の選択は、復旧時間とデータ損失許容度に関するアプリケーションの要件に完全に依存します。

機能	RDB（スナップショット）	AOF（追記専用ファイル）
耐久性/データ損失	潜在的なデータ損失が大きい（最後の保存以降）。	データ損失が最小限（1秒以下、`fsync=always`ではゼロ）。
ファイルサイズ	非常にコンパクトで最適化されている。	コマンドログのため大きい。
再起動時間	スナップショットのロードが非常に高速。	遅い、コマンド再生が必要。
複雑さ	シンプル、時間間隔で設定。	`fsync`ポリシーの注意深い設定が必要。
ユースケース	バックアップ、最近のデータ損失が許容される災害復旧。	高い耐久性が必要な主要な永続化メカニズム。

ベストプラクティス：RDBとAOFの組み合わせ

多くの本番デプロイメントでは、RDBとAOFの両方を有効にすることで、有用なセーフティネットが得られます。

両方が有効な場合：

AOFが主要で高耐久性のログを提供します。
RDBが高速でコンパクトなバックアップスナップショットを提供します。

両方が有効な場合、Redisは再起動時にAOFをロードします。これは通常、最後のRDBスナップショットよりも完全だからです。RDBは、コピー、テスト、アーカイブが容易なコンパクトなバックアップファイルを提供します。

両方を有効にする方法

redis.confで両方の設定が行われていることを確認します：

# AOFを有効にする
appendonly yes

# RDB設定を維持（例：1時間ごとに自動保存）
save 3600 1

# 推奨されるAOFのfsyncポリシー
appendfsync everysec

AOF書き換えのヒント：BGREWRITEAOFコマンドを使用して、いつでも手動でAOF書き換えをトリガーできます。これは、大規模なバルクデータロードや重要なパージ操作の後、AOFファイルサイズを即座に縮小するのに特に便利です。

まとめ

RDBは、コンパクトなバックアップが必要で、最後のスナップショット以降の最近の書き込みを失っても許容できる場合に使用します。AOFは、Redisがクラッシュしても最小限の損失で生き残るべきデータを保持する場合に使用します。重要な本番データには、appendfsync everysecでAOFを有効にし、バックアップ用にRDBスナップショットを保持し、障害が問題を強制する前に復元時間をテストしてください。