Redis永続化メカニズムの詳細ガイド

AOF永続化

Redisはメモリベースであるため、Redisサーバーがクラッシュするとデータが失われます。データ損失を防ぐために、RedisはRDBとAOFという2つの永続化メカニズムを提供しています。まずはAOFからご紹介します。

AOF（Append Only File）永続化は、すべての書き込み操作を追記専用方式でAOFファイルの末尾に記録します。デフォルトでは、AOFはRedisで無効になっています。再起動時に、RedisはAOFファイル内のコマンドを再実行してデータを復元します。これは主にリアルタイムのデータ永続化の問題に対処します。

AOFログは、コマンドが実行された後にのみ書き込まれます。コマンドを最初にログに記録してから実行しないのはなぜでしょうか？これは、RedisがAOFログへの書き込み時に構文チェックを行わないためです。最初にコマンドをログに記録してから実行すると、無効なコマンドをログに記録するリスクがあり、RedisがAOFログからデータを復元しようとするときにエラーが発生する可能性があります。

ログ記録はコマンド実行後に行われるため、現在の書き込み操作をブロックしません。ただし、2つのリスクがあります。

• コマンドが実行された後、ログが書き込まれる前にシステムがクラッシュした場合、データが失われます。
• AOFは現在のコマンドをブロックしませんが、次の操作をブロックする可能性があります。

これらのリスクを軽減する最良の方法は、appendfsync設定で提供される3つのAOF書き込み戦略を利用することです。

• always: 同期書き込み。各コマンドの実行後、ログはすぐにディスクに書き込まれます。
• everysec: 各コマンドの後、ログはAOFメモリバッファに書き込まれ、1秒ごとにディスクに同期されます。
• no: ログはAOFメモリバッファにのみ書き込まれ、オペレーティングシステムがディスクにフラッシュするタイミングを決定します。

always戦略は、データ損失を最小限に抑えますが、パフォーマンスは低下します。no戦略はパフォーマンスが向上しますが、データ損失のリスクが高まります。一般的に、everysecは良い妥協案です。

時間の経過とともに多数のコマンドが受信されると、AOFファイルは増え続け、パフォーマンスの問題を引き起こす可能性があります。ログファイルが大きすぎるとどうなるでしょうか？そこでAOFリライトが登場します！時間の経過とともに、AOFファイルには、無効または期限切れのものなど、冗長なコマンドが蓄積されます。AOFリライトメカニズムは、これらを単一のコマンド（バッチコマンドなど）にマージして、ファイルサイズを削減および圧縮します。

AOFリライトはブロッキングを引き起こしますか？AOFログはメインスレッドによって書き込まれますが、リライトは異なり、bgrewriteaofと呼ばれるバックグラウンドサブプロセスによって実行されます。

• AOFの利点：より高いデータ一貫性と整合性。データ損失は数秒に制限されます。
• 欠点：同じデータセットの場合、AOFファイルはRDBファイルよりも大きくなります。リカバリも遅くなります。

RDB永続化

AOF永続化では、操作ログが多数ある場合にリカバリが非常に遅くなる可能性があるため、クラッシュ後のリカバリを高速化する方法はありますか？はい、RDBです！

RDBは、メモリ内のデータをスナップショットの形式でディスクに保存することで機能します。各操作を記録するAOFとは異なり、RDBは特定の時点でのデータ状態を記録します。

スナップショットとは何ですか？これは、現在のデータの写真を撮ってその画像を保存することと考えることができます。

RDB永続化とは、指定された間隔で、および指定された数の書き込み操作の後、Redisがメモリ内のデータセットのスナップショットをディスクに書き込むことを意味します。これはRedisのデフォルトの永続化方法です。操作が完了すると、指定されたディレクトリにdump.rdbファイルが生成されます。Redisが再起動すると、dump.rdbファイルをロードしてデータを復元します。RDBはいくつかの方法でトリガーできます。

• save: 手動でトリガーされる同期保存。現在のRedisサーバーをブロックします。
• bgsave: 手動でトリガーされる非同期保存。Redisプロセスは子プロセスをフォークします。
• save m n: 自動的にトリガーされます。データセットが_m_秒以内に_n_回変更された場合、自動的にbgsaveがトリガーされます。

bgsaveコマンドを使用して完全なスナップショットを実行することで、Redisはメインスレッドのブロッキングを回避します。bgsaveコマンドは子プロセスをフォークしてRDBファイルを作成し、サーバープロセスはコマンドの処理を続行します。

スナップショットの作成中にデータを変更できますか？RedisはオペレーティングシステムのCopy-On-Write（COW）メカニズムを使用しているため、スナップショットの作成中に書き込みの処理を続行できます。

bgsaveはメインスレッドをブロックしませんが、頻繁な完全なスナップショットは依然としてパフォーマンスのオーバーヘッドを伴います。たとえば、forkを介して子プロセスを作成する必要があります。これにより、作成中にメインスレッドがブロックされます。この場合、増分スナップショットの方が適している可能性があります。

• RDBの利点：AOFと比較して、大規模なデータセットのリカバリが高速になり、バックアップや完全なレプリケーションなどの大規模なデータリカバリシナリオに適しています。
• 欠点：リアルタイムまたは秒レベルの永続化を実現できません。

Redis 4.0以降では、RDBとAOFのハイブリッド永続化がサポートされています。メモリのスナップショットは定期的に作成され、スナップショットの間には、すべてのコマンド操作がAOFを使用して記録されます。

RDBとAOFのどちらを選択するか

• データ損失が許容できない場合は、RDBとAOFの組み合わせを使用します。
• Redisがキャッシュとしてのみ使用され、数分間のデータ損失を許容できる場合は、RDBのみを使用するだけで十分です。
• AOFのみを使用する場合は、everysec書き込み戦略を使用することをお勧めします。

---

Leapcellは、バックエンドプロジェクトをホストするための最適な選択肢です。

Leapcellは、Webホスティング、非同期タスク、およびRedis向けの次世代サーバーレスプラットフォームです。

多言語サポート

• Node.js、Python、Go、またはRustで開発します。

無制限のプロジェクトを無料でデプロイ

• 使用量に応じてのみ支払い — リクエストや料金はかかりません。

比類のないコスト効率

• アイドル料金なしの従量課金制。
• 例：$25で、平均応答時間60msで694万リクエストをサポートします。

合理化された開発者エクスペリエンス

• 簡単なセットアップのための直感的なUI。
• 完全に自動化されたCI/CDパイプラインとGitOps統合。
• 実用的な洞察を得るためのリアルタイムのメトリクスとロギング。

簡単なスケーラビリティと高いパフォーマンス

• 高い並行処理を容易に処理するための自動スケーリング。
• 運用上のオーバーヘッドなし — 構築に集中するだけです。

詳細については、ドキュメントをご覧ください。

Xでフォローしてください：@LeapcellHQ