Redisの永続化オプション：RDB vs. AOFの解説
Redisは、その高速性からインメモリデータ構造ストアとして知られ、キャッシュやメッセージブローカーとして頻繁に利用されます。しかし、データは速度のために主にRAMに存在しますが、本番環境でのデプロイでは、再起動やクラッシュ時にデータが失われないようにするメカニズムが必要です。ここで永続化が重要になります。Redisは、2つの主要な組み込み永続化メカニズムを提供しています。それはRedis Database Backup (RDB)とAppend-Only File (AOF)です。これら2つのトレードオフを理解することは、アプリケーションの耐久性とパフォーマンスのニーズに合わせてRedisを適切に構成するために不可欠です。
このガイドでは、RDBとAOFがどのように機能するかを詳細に説明し、それぞれの長所と短所を比較し、各戦略をいつ使用すべきかについてのガイダンスを提供します。
Redisの永続化の理解
Redisにおける永続化とは、インメモリのデータセットの現在の状態をディスクに書き込むプロセスを指します。これにより、サーバーが再起動したときにRedisがデータを再ロードできるようになります。永続化が有効になっていない場合、シャットダウン時にすべてのデータが失われます。
RedisはRDBとAOFの両方を同時にサポートしており、両方の利点を組み合わせたハイブリッドなアプローチを提供します。
1. Redisデータベースバックアップ (RDB)
RDB (Redis Database Backup) は、Redisのデフォルトの永続化メカニズムです。これは、指定された間隔でデータセット全体の定期的なスナップショットを作成します。
RDBの仕組み
RDBは、メインのRedisプロセスをフォークし、現在のメモリ内容をdump.rdbという名前の圧縮されたバイナリファイルとしてディスクに書き込む子プロセスを作成することで動作します。これはスナップショットであるため、特定の時点のデータを取得します。
設定とスナップショット
RDBの設定は、redis.confファイル内のsaveディレクティブを通じて管理されます。これらのディレクティブは、自動保存が行われる条件を定義します。
# Save the DB if 1000 keys changed in 1 minute
save 600 1000
# Save the DB if 10 keys changed in 10 minutes
save 300 10
# Save the DB if 10000 keys changed in 1 second
save 1 10000
RDB永続化を完全に無効にするには、すべてのsaveディレクティブをコメントアウトするか、SAVEコマンドを手動でのみ使用します。
RDBの利点
- コンパクトなファイル: RDBファイルは高度に最適化され、圧縮されており、コンパクトであるため、バックアップや高速な転送に最適です。
- 高速なリカバリ: 単一のスナップショットファイルであるため、再起動時のデータロードが非常に高速です。
- パフォーマンス: 保存はプロセスをフォークすることで非同期に行われるため、書き込み操作中にメインスレッドがブロックされることはありません（ただし、フォーク自体がわずかなレイテンシースパイクを引き起こす可能性があります）。
RDBの欠点
- データ損失のリスク: スケジュールされた保存ポイントの間にRedisがクラッシュした場合、最後のスナップショット以降に発生したすべての書き込みは失われます。
- フォークのオーバーヘッド: 非常に大きなデータセットでは、スナップショットを作成するために必要なフォーク操作が、かなりのシステムリソースを消費し、一時的なレイテンシーを引き起こす可能性があります。
2. Append-Only File (AOF)
AOF (Append-Only File) は、より高いレベルのデータ耐久性を提供します。スナップショットとは異なり、AOFはサーバーが受け取ったすべての書き込み操作をアペンドオンリー形式でログに記録します。
AOFの仕組み
永続化が有効になっている場合、Redisはすべての書き込みコマンド（例：SET、LPUSH）をディスク上のAOFファイルにリダイレクトします。Redisが再起動すると、これらのコマンドを順番にリプレイして、シャットダウン前の状態とまったく同じデータセットを再構築します。
AOFの設定
AOF永続化はデフォルトで無効になっており、redis.confで明示的に有効にする必要があります。
appendonly yes
重要なことに、AOFはfsyncポリシーの設定を可能にし、書き込みがどのくらいの頻度でディスクに強制されるかを決定します。
| fsyncポリシー | 説明 | 耐久性 vs. パフォーマンス |
|---|---|---|
no |
OSが同期を処理します（最も頻度が低い）。 | 最速、損失のリスクが最も高い。 |
everysec |
1秒に1回同期します（デフォルトかつ推奨）。 | 良いバランス。最大で1秒間のデータが失われます。 |
always |
すべてのコマンドの後に同期します。 | 最高の耐久性、パフォーマンスに大きな影響を与える可能性あり。 |
AOFの利点
- 高い耐久性:
fsyncをalwaysに設定することで、ほぼゼロのデータ損失を達成できます。 - ログのリプレイ: AOFファイルには操作の時系列ログが含まれており、潜在的なデータ破損のデバッグが容易になります。
AOFの欠点
- ファイルサイズの増大: AOFファイルは、最終的なデータ状態ではなくコマンドを格納するため、通常、対応するRDBファイルよりもはるかに大きくなります。
- 再起動の遅延: 起動時に数千ものコマンドをリプレイすることは、単一のRDBスナップショットをロードするよりも時間がかかります。
- 書き込み増幅: コマンドは個別にログに記録されるため、RDBのスナップショット作成と比較して、わずかに高い書き込みオーバーヘッドが発生する可能性があります。
AOFのリライト
ファイルサイズの増大に対処するため、RedisはAOFのリライトを実装しています。このプロセスは、非同期的に新しい最適化されたAOFファイルを作成し、現在の状態に到達するために必要なコマンドのみを含め、冗長なコマンドや古いコマンド（同じキーに対する複数の更新など）を効果的に破棄します。
RDB vs. AOF: 直接比較
RDB、AOF、または両方を選択するかどうかは、リカバリ時間とデータ損失許容度に関するアプリケーションの要件に完全に依存します。
| 機能 | RDB (スナップショット) | AOF (アペンドオンリーファイル) |
|---|---|---|
| 耐久性/データ損失 | 潜在的なデータ損失が大きい（最後の保存以降）。 | 最小限のデータ損失（最大1秒、またはfsync=alwaysでゼロ）。 |
| ファイルサイズ | 非常にコンパクトで最適化されている。 | コマンドのログ記録により大きい。 |
| 再起動時間 | スナップショットのロードが非常に高速。 | 遅い、コマンドのリプレイが必要。 |
| 複雑さ | シンプル、時間間隔で設定。 | fsyncポリシーの慎重な設定が必要。 |
| ユースケース | 最近のデータ損失が許容されるバックアップ、災害復旧。 | 高い耐久性を必要とする主要な永続化メカニズム。 |
ベストプラクティス：RDBとAOFの組み合わせ
ほとんどの最新の本番環境でのデプロイでは、RDBとAOFの両方の永続化を同時に有効にすることが推奨されるアプローチです。
両方が有効になっている場合：
1. AOFは、主要な高耐久性ログを提供します。
2. RDBは、高速でコンパクトなバックアップスナップショットを提供します。
再起動時、Redisは完全な耐久性のためにAOFファイルのロードを優先します。AOFファイルが見つからないか破損している場合、RDBファイルのロードにフォールバックします。さらに、AOFのリライトプロセスは、RDBファイルを効率的な開始点として使用することが多く、両方のメソッドの利点を融合させます。
両方を有効にする方法
redis.confで両方の設定がされていることを確認してください：
# Enable AOF
appendonly yes
# Keep RDB configuration (e.g., autosave every hour)
save 3600 1
# Recommended fsync policy for AOF
appendfsync everysec
AOFリライトに関するヒント:
BGREWRITEAOFコマンドを使用すると、いつでも手動でAOFリライトをトリガーできます。これは、大量のデータロード後や大規模なパージ操作後に、AOFファイルのサイズをすぐに縮小するために特に役立ちます。