データ損失を防ぐためのベストプラクティス：RDB vs AOF設定

Redisの永続化は誤解されやすいです。なぜなら、Redisはデータベースのように感じられますが、まずメモリとして動作するからです。永続化なしで再起動すると、データは失われます。永続化が有効でも、不注意に調整すると、最近の書き込みが失われたり、ディスク負荷時にクライアントが停止したり、障害発生時にデータの唯一のコピーがRedisプロセスと同じ障害ボリュームにあることが判明したりする可能性があります。

適切なRedisデータ損失戦略は、正直な質問から始まります。最後の数秒、数分、数時間の書き込みが消えたらどうなるか？製品ページのキャッシュは通常再構築できます。セッションストアはユーザーを悩ませるかもしれませんが、ビジネスを破壊するわけではありません。キュー、レート制限台帳、カートストア、フィーチャーフラグストアは、より厳密な耐久性が必要な場合があります。RDBとAOFは、Redisが提供する2つのツールであり、それぞれ問題の異なる部分を解決します。

Redis永続化メカニズムの理解

Redisには2つの主要な永続化モードがあります：

RDBスナップショット

RDBはデータセットのポイントインタイムスナップショットをディスクに書き込み、通常はdump.rdbとして保存します。Redisは子プロセスをフォークし、子プロセスがデータセットをシリアライズし、親プロセスはクライアントへのサービスを継続します。これにより、RDBはバックアップ、レプリカ、高速再起動に役立ちますが、明確なトレードオフがあります。最後の成功したスナップショット以降に書き込まれたものは、プロセスまたはホストが障害を起こすと失われる可能性があります。

典型的なRDB設定は次のようになります：

save 900 1       # 15分後に少なくとも1つのキーが変更された場合に保存
save 300 10      # 5分後に少なくとも10のキーが変更された場合に保存
save 60 10000    # 1分後に少なくとも10000のキーが変更された場合に保存
dbfilename dump.rdb
dir /var/lib/redis

これらのsave行は、Redisが正確にそのスケジュールで保存することを約束するものではありません。これらはトリガールールです。間隔中に十分なキーが変更された場合、Redisはバックグラウンド保存を開始します。ディスクが遅い、データセットが巨大、またはホストのメモリが少ない場合、バックグラウンド保存は失敗したり、フォークとコピーオンライトの負荷によってレイテンシを引き起こしたりする可能性があります。

RDBは、コンパクトなスナップショットと高速な復元動作が必要な場合に最も強力です。最近のデータ損失に対する許容度が低い場合に最も弱くなります。

AOFログ

AOF（追記専用ファイル永続化）は、書き込みコマンドを記録し、Redisが再起動時にそれらを再生できるようにします。通常、RDBよりも優れた耐久性を提供します。なぜなら、スナップショットスケジュールよりも頻繁に書き込みをフラッシュできるからです。トレードオフは、より多くのディスクI/O、書き換え前のより大きなファイル、そしてRedisが大きなログを再生する必要がある場合の起動の遅さです。

コア設定は次のとおりです：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

重要な行はappendfsyncです。everysecの場合、Redisはオペレーティングシステムに約1秒に1回AOFをフラッシュするよう要求します。通常のRedisプロセスクラッシュでは、これにより損失は通常約1秒間の書き込みに制限されます。完全なホストクラッシュまたはストレージ障害の場合、正確な損失はOS、ファイルシステム、ディスクキャッシュ、およびストレージの動作に依存するため、数学的な保証として説明しないでください。

appendfsync alwaysはすべての書き込み後にフラッシュし、はるかに高コストです。書き込み量が控えめな小規模で重要なRedisデプロイメントには適しているかもしれませんが、実際のトラフィック下ではレイテンシに深刻な悪影響を与える可能性があります。appendfsync noはOSにフラッシュのタイミングを任せます。高速ですが、損失ウィンドウがはるかに広く、予測不可能になります。

データ損失防止のベストプラクティス

Redisがどのファイルをロードするかを理解している場合にのみ両方を使用する

多くの本番Redisデプロイメントでは、RDBとAOFの両方を有効にしています。これは、Redisが再構築に苦痛を伴うデータを保存する場合、賢明なデフォルトです。RDBはコンパクトなバックアップアーティファクトを提供します。AOFはより小さな最近の損失ウィンドウを提供します。

次のような設定を使用します：

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

復元中に1つの詳細が重要です。AOFが有効な場合、Redisは通常、起動時にAOFデータをロードします。これは、RDBスナップショットよりも完全であると予想されるためです。Redisが最初にRDBをロードしてからAOFにフォールバックすると想定しないでください。Redisのバージョンとデプロイメントレイアウト、特に新しいマルチパートAOF形式を使用するRedisバージョンで、復元パスをテストしてください。

損失ウィンドウから逆算してappendfsyncを選択する

Redisの設定ではなく、ビジネスへの影響から始めてください。

Redisが使い捨てキャッシュの場合、RDBのみで十分かもしれません。アプリケーションが安全に再生成できる場合は、永続化さえ不要です。Redisがセッションを含む場合、appendfsync everysecはしばしば実用的なバランスです。Redisが、承認された書き込みの損失が実際のビジネス損害を生み出すワークフローの一部である場合、Redisの永続化だけでは適切な耐久性の境界ではないかもしれません。プライマリデータベース、耐久性のあるキュー、またはRedis外部のアプリケーションレベルの先行書き込み動作が必要になる場合があります。

ほとんどの運用Redis使用では、次から始めてください：

appendonly yes
appendfsync everysec

その後、レイテンシ、ディスク書き込み時間、AOF書き換え動作、再起動時間を監視してから、alwaysに移行するか、AOFから離れるかを決定してください。

RDBスナップショットを維持するが、過度に積極的にしない

頻繁なRDB保存は、スナップショット間で失われるデータ量を減らしますが、フォークの頻度も増加させます。大規模なRedisプロセスをフォークするのはコストがかかる可能性があり、子プロセスの保存中の書き込みはコピーオンライトメモリ負荷を生み出します。Redisインスタンスが40 GBのデータセットを持ち、書き込みレートが高い場合、毎分保存すると、ホストがメモリとディスク負荷の下で過剰な時間を費やすため、信頼性が低下する可能性があります。

妥当なRDB保存ルールは、書き込みレートと復旧期待値に依存します。小さなキャッシュは問題なく頻繁にスナップショットを取ることができます。大規模なセッションストアは、最近の耐久性のために、より少ないRDBスナップショットとAOFを必要とする場合があります。Redis設定ファイルだけでなく、BGSAVE中のINFO persistence、Redisログ、ホストメモリを監視してください。

AOF書き換えを緊急時ではなく通常のメンテナンスとして扱う

AOFファイルは書き込みを記録するため成長します。Redisはそれらをバックグラウンドでコンパクトな表現に書き換えます。デフォルトは多くの場合、適切な出発点です：

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

これは、AOFが前回の書き換え後のサイズと比較して大幅に成長し、かつ最小サイズ以上になった場合に、Redisが書き換えを検討することを意味します。書き換えが絶えず発生する場合は、最小サイズを増やすか、ノイズの多い書き込みパターンを調査してください。AOFが長期間書き換えられずに成長する場合は、ログ、ディスク容量、INFO persistenceを確認してください。

手動で書き換えをトリガーできます：

redis-cli BGREWRITEAOF

可能であれば、静かな期間中に実行してください。書き換えはファイルを永久に成長させ続けるよりも安全ですが、それでもCPU、ディスク帯域幅、およびコピーオンライトメモリを消費します。

永続化ファイルを別の場所にバックアップする

永続化はバックアップではありません。同じホスト上の永続化ファイルは、Redisプロセスの再起動から保護します。ディスクの損失、誤った削除、データディレクトリを上書きする不良デプロイ、またはFLUSHALLを実行するオペレーターのミスからは保護しません。

RDBおよびAOFファイルを別のストレージにコピーしてください。ファイルシステムスナップショットまたはクラウドボリュームスナップショットを使用する場合は、別のインスタンスで復元をテストしてください。RDBコピーの場合は、書き込み中のファイルではなく、完了したスナップショットファイルをコピーすることをお勧めします。AOFの場合は、ファイル名に基づいてバックアップスクリプトを作成する前に、Redisバージョンのファイルレイアウトを理解してください。

データ損失を予測するシグナルを監視する

インシデント中に役立つコマンドは次のとおりです：

redis-cli INFO persistence

失敗したバックグラウンド保存、AOF書き換えステータス、最終保存時間、遅延fsyncインジケーターを確認してください。それをホストメトリクス（ディスクレイテンシ、空きディスク容量、メモリ余裕、カーネルOOMイベント）と組み合わせてください。BGSAVEが何時間も失敗し、誰も気づかない場合、Redis設定は安全に見えても、実際の復旧ポイントはどんどん古くなっていきます。

可用性のためにレプリケーションまたはSentinelを使用するが、唯一のバックアップとしてではない

レプリカ、Redis Sentinel、Redis Clusterは可用性に役立ちます。それらは自動的にすべてのデータ損失問題を解決するわけではありません。不正な書き込み、誤った削除、またはアプリケーションバグは急速にレプリケートされる可能性があります。また、フェイルオーバーは、レプリケーションラグが存在する場合、最近の書き込みが欠落しているレプリカを昇格させる可能性があります。設計に永続化、バックアップ、および復元テストを含めてください。

多くのチームにとって実用的なセットアップは、appendfsync everysecのAOF、妥当な頻度のRDBスナップショット、外部バックアップ、永続化障害の監視、およびテスト済みの復元手順書です。Redisはその形で信頼性が高くなりますが、それは永続化をチェックボックスではなく運用システムとして扱う場合に限ります。