DevOpsナレッジハブ
DevOpsナレッジハブ

最適なRedis永続化戦略の選択：RDB 対 AOF。

Redisの永続化戦略、RDB（Redis Database Backup）とAOF（Append-Only File）の間の重要な選択肢を探ります。この包括的なガイドでは、それぞれの方法の仕組み、利点、欠点、および設定例を詳しく解説します。潜在的なデータ損失、パフォーマンスへの影響、ファイルサイズについて学び、データの耐久性と回復のニーズに最適な戦略を決定してください。最大限の回復力のために両方を組み合わせる力を発見し、Redisデータが常に安全で回復可能であることを保証します。

54 ビュー

最高のRedis永続化戦略の選択：RDB対AOF

Redisは、インメモリデータ構造ストアであり、キャッシュ、セッションストア、メッセージブローカーとしての速度と汎用性で知られています。その主な操作はインメモリで行われますが、プロダクション環境でのデプロイメントにおいては、データの永続性（耐久性）と回復可能性を確保することがしばしば不可欠です。ここでRedisの永続化が登場し、データセットの状態をディスクに保存できるようになります。

適切な永続化戦略を選択することは、データの整合性、回復時間、およびパフォーマンスへの影響のバランスを取る重要な決定です。Redisは、主に2つの永続化メカニズムを提供しています：Redisデータベースバックアップ（RDB）と追記専用ファイル（AOF）です。それぞれの機微、利点、およびトレードオフを理解することで、特定のデータの耐久性と回復のニーズに合わせてRedisを最適に構成できるようになります。

この記事では、RDBとAOFについて深く掘り下げ、それぞれがどのように機能するか、それぞれの長所と短所、実用的な設定例、および堅牢なデータ保護のためにそれらを組み合わせる方法を探ります。読み終えるころには、Redisのデプロイメントについて情報に基づいた意思決定を下せるようになるでしょう。

Redisの永続化の理解

Redisにおける永続化とは、サーバーの再起動またはクラッシュ後に再ロードできるように、インメモリのデータセットをディスクに保存する機能のことです。永続化がない場合、サーバーが停止またはクラッシュすると、Redisに保存されているすべてのデータが失われます。Redisはこれを達成するために、2つの異なる方法を提供しています。

  • RDB (Redis Database Backup): データセットの特定時点のスナップショットです。
  • AOF (Append-Only File): サーバーによって実行されたすべての書き込み操作のログです。

どちらの方法も独自の特性を持っており、異なるシナリオに適しています。

Redisデータベースバックアップ（RDB）

RDB永続化は、指定された間隔でRedisデータセットの特定時点のスナップショットを実行します。RDBの保存操作がトリガーされると、Redisは子プロセスをフォークします。その後、子プロセスはデータセット全体を一時的なRDBファイルに書き込みます。ファイルが完了すると、古いRDBファイルは新しいものに置き換えられます。

RDBの仕組み

  1. フォーク（Forking）: Redisサーバーは新しい子プロセスをフォークします。
  2. スナップショットの取得（Snapshotting）: 子プロセスは、データセット全体を一時的なRDBファイルへの書き込みを開始します。
  3. 完了（Completion）: 子プロセスが書き込みを終了すると、古いRDBファイルを新しい一時的なファイルに置き換えます。
  4. クリーンアップ（Cleanup）: 子プロセスは終了します。

親プロセスは応答性を保つため、このプロセスにより、スナップショットが取得されている間もRedisはクライアント要求の処理を継続できます。

RDBの利点

  • コンパクトなバックアップ: RDBファイルはバイナリ圧縮されており、Redisデータセットの非常にコンパクトな表現を提供します。これにより、バックアップおよび障害回復に理想的です。
  • 高速な再起動: RDBファイルをリロードすることは、特に大規模なデータセットの場合、単一の事前にフォーマットされたバイナリファイルをロードするだけで済むため、AOFファイルをリプレイするよりも著しく高速です。
  • 最小限のディスクI/O: RDBの保存は設定された間隔でのみ発生するため、Redisは保存していないときは最小限のディスクI/Oしか実行しません。これにより、通常の操作中に高いパフォーマンスが得られる可能性があります。
  • 転送が容易: 単一のコンパクトなファイルであるため、RDBバックアップは、障害回復やアーカイブ目的でリモートデータセンターに簡単に転送できます。

RDBの欠点

  • 潜在的なデータ損失: 主な欠点は、データ損失の可能性です。Redisが保存ポイント間でクラッシュした場合、最後の成功したRDB保存以降に書き込まれたすべてのデータが失われます。
  • フォーク時のパフォーマンススパイク: 非常に大きなデータセットの場合、最初のfork()操作は時間がかかり、特にメモリ使用量が高い場合、短時間Redisサーバーをブロックする可能性があります。
  • リアルタイム永続化ではない: RDBはリアルタイムのデータ永続化のために設計されていません。数分間のデータ損失が許容できるシナリオに最も適しています。

RDBの設定

RDB永続化は、redis.confでsaveディレクティブを使用してデフォルトで有効になっています。複数のsaveルールを指定できます。

# Save the database every 900 seconds (15 minutes) if at least 1 key changed
save 900 1

# Save the database every 300 seconds (5 minutes) if at least 10 keys changed
save 300 10

# Save the database every 60 seconds if at least 10000 keys changed
save 60 10000

# Disable RDB persistence (comment out all save directives, or explicitly set below)
# save ""

また、redis-cliでSAVE（ブロッキング）またはBGSAVE（非ブロッキング）コマンドを使用して、RDB保存を手動でトリガーすることもできます。

追記専用ファイル（AOF）

AOF永続化は、Redisサーバーが受け取ったすべての書き込み操作をログに記録します。データセット全体を定期的に保存する代わりに、AOFはデータセットを変更するコマンドを記録します。Redisが再起動すると、これらのコマンドをAOFファイルで再実行し、元のデータセットを再構築します。

AOFの仕組み

  1. コマンドのロギング: Redisによって実行されたすべての書き込みコマンドがAOFファイルに追記されます。
  2. fsyncポリシー: Redisには、AOFバッファがディスクに同期される頻度を制御するためのさまざまなfsyncポリシーがあります。
    • appendfsync always: すべてのコマンドの後に同期します。最高の耐久性を提供しますが、最も遅いです。
    • appendfsync everysec: 1秒に1回同期します。耐久性とパフォーマンスのバランスが取れています（デフォルトで推奨）。
    • appendfsync no: オペレーティングシステムがAOFバッファをディスクにフラッシュすることに依存します。最高のパフォーマンスを提供しますが、耐久性は最も低いです。
  3. AOFのリライト: 時間の経過とともに、冗長なコマンド（例：同じキーを複数回更新）のためにAOFファイルは非常に大きくなる可能性があります。AOFリライトは、現在のデータセットを再構築するために必要なコマンドのみを含む新しい、より小さなAOFファイルを作成することで、AOFファイルを最適化します。このプロセスは、RDBのフォークメカニズムと似ています。

AOFの利点

  • より優れた耐久性: appendfsync alwaysまたはeverysecを使用すると、AOFはRDBと比較して優れたデータ耐久性を提供します。データの損失は最大で1秒分（everysecの場合）または全くデータ損失なし（alwaysの場合）に抑えられます。
  • データ損失が少ない: クラッシュが発生した場合、fsyncポリシーに応じて、データの損失が大幅に少なくなります（あるいは全く失われません）。
  • 人間が読める形式: AOFファイルは人間が読める形式であり、操作の履歴を理解しやすくなります。これは、特定のシナリオでのデバッグやデータ回復に役立ちます。

AOFの欠点

  • ファイルサイズが大きい: AOFファイルは、コンパクトなデータではなくコマンドを格納するため、同じデータセットに対してRDBファイルよりも一般的にかなり大きくなります。
  • 回復が遅い: 起動時に大きなAOFファイルをリプレイすることは、Redisが各コマンドを実行する必要があるため、RDBファイルをロードするよりも遅くなる可能性があります。
  • パフォーマンスへの影響: fsyncポリシーによっては、AOFはより多くのディスクI/Oを引き起こし、書き込みパフォーマンスに影響を与える可能性があります。appendfsync alwaysは特に影響が大きいです。
  • AOFリライトのオーバーヘッド: AOFリライトはファイルサイズの管理に役立ちますが、リライトプロセス自体がCPUとI/Oリソースを消費し、データセットが非常に大きい場合は、RDBのフォークと同様に、一時的にRedisをブロックする可能性があります。

AOFの設定

AOFを有効にするには、redis.confでappendonly yesを設定する必要があります。

# Enable AOF persistence
appendonly yes

# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"

# appendfsync options: always, everysec, no
appendfsync everysec

# Auto-rewrite AOF file when it's twice the size of the base and is at least 64MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB対AOF：比較概要

Feature RDB (Redis Database Backup) AOF (Append-Only File)
Mechanism 特定時点のスナップショット（バイナリファイル） すべての書き込み操作のログ（テキストベースのコマンド）
Data Loss 保存ポイント間のデータ損失の可能性（数分） 最小限のデータ損失（everysecで数秒、alwaysでゼロ）
Performance 通常操作中の高い書き込みパフォーマンス、fork()時のブロックの可能性 強力なfsync設定では書き込みが遅くなるが、I/Oはより一貫している
File Size 非常にコンパクトなバイナリファイル 一般的に大きく、操作とともに増加する
Recovery Time 大規模なデータセットで高速 大規模なデータセットで遅い（コマンドをリプレイするため）
Backup Ease 単一のコンパクトなファイル。バックアップ/障害回復が容易 大きなファイル。リライトなしでは管理が困難になる可能性
Readability 人間が読めない 人間が読める形式（コマンド）
Default in Redis はい（saveディレクティブあり） いいえ（デフォルトでappendonly no）

ハイブリッドアプローチ：RDBとAOFの併用 (Redis 4.0以降)

Redis 4.0以降では、RDBとAOFの永続化を組み合わせることが可能であり、多くの場合推奨されています。両方が有効になっている場合、Redisは起動時にデータセットを再構築するために主にAOFファイルを使用します。これは、AOFの方が優れた耐久性を保証するためです。ただし、Redis 4.0以降のAOFリライトプロセスでは、RDBプリアンブルで始まり、その後AOFコマンドを追記するハイブリッドAOFファイルも作成されます。これにより、両方の利点が組み合わされます。

  • 高速なリライト: ハイブリッドAOFのRDB部分は、リライトプロセス用の初期スナップショットを大幅に高速化します。
  • 高速な再起動（可能性）: Redisが再起動するとき、まずAOFファイルのRDB部分をロードします（これは高速です）次に、後続のAOFコマンドをリプレイします。
  • より優れた耐久性: AOFの最小限のデータ損失という利点を引き続き享受できます。

このハイブリッドモードを有効にするには、appendonly yesとRDBのsaveディレクティブの両方を設定するだけで済みます。

適切な永続化戦略の選択

理想的な永続化戦略は、データの耐久性、パフォーマンス、回復時間に関するアプリケーション固有の要件によって異なります。

1. RDBのみを使用する場合

  • 主な使用例：キャッシュ/非クリティカルなデータ: Redisが主にキャッシュとして使用されており、クラッシュ時に一部のデータが失われても許容できる場合、またはデータが別のソースから容易に再構築できる場合。
  • 高いパフォーマンス要件: 書き込みパフォーマンスが最も重要であり、時折のデータ損失が許容できる場合。
  • 障害回復バックアップ: RDBファイルは、長期アーカイブまたは障害回復のための定期的なスナップショットを作成するのに優れています。BGSAVEをcronで実行し、その後.rdbファイルをオフサイトに移動できます。
  • メモリ効率: ディスク容量が非常に制約されている場合。

2. AOFのみを使用する場合

  • 主な使用例：絶対的な耐久性: すべての単一の書き込み操作が重要であり、数秒のデータ損失さえ許容できない場合（例：金融取引、重要なユーザーデータ）。この場合、大幅なパフォーマンスコストを伴いますが、appendfsync alwaysを検討するかもしれません。
  • デバッグ/監査: AOFの人間が読める形式は、データ変更の履歴を理解するのに役立ちます。

3. RDBとAOFの両方を使用する場合（最もクリティカルなアプリケーションに推奨）

  • バランスの取れた耐久性と回復: これは一般的に、データの耐久性が重要であり、効率的な再起動とバックアップも望むプロダクションシステムに推奨されるアプローチです。
  • 堅牢性: 追加の保護レイヤーを提供します。一方の永続化方法が破損した場合でも、もう一方の方法で回復できる可能性があります。
  • Redis 4.0+: RDBプリアンブルAOF形式を活用して、最適化されたAOFリライトと潜在的な高速回復を実現します。

実用的なヒントとベストプラクティス

  • ディスク使用量の監視: RDBとAOFの両方がかなりのディスク容量を消費する可能性があります。特にAOFリライトやRDB保存の前に容量不足にならないよう、ディスク使用量を監視してください。
  • fsyncポリシー: AOFの場合、appendfsync everysecが最も一般的で推奨される選択肢であり、耐久性とパフォーマンスのバランスが取れています。クリティカルなデータにはappendfsync noの使用を避けてください。
  • AOFリライト: リソースの過剰な消費なしにAOFファイルが定期的に最適化されるよう、auto-aof-rewrite-percentageとauto-aof-rewrite-min-sizeを慎重に構成してください。
  • ディスク/場所の分離: 可能であれば、I/O競合を防ぐために、永続化ファイル（AOFとRDB）をオペレーティングシステムやアプリケーションログとは異なるディスクまたはパーティションに保存してください。
  • 外部バックアップ: 永続化戦略に関係なく、堅牢な障害回復のために、RDBファイルとAOFファイルをオフサイトの場所（例：S3、Google Cloud Storage）に定期的にバックアップしてください。
  • 回復のテスト: 選択した永続化戦略を使用して、データが正常に復元できることを確認するために、定期的に回復プロセスをテストしてください。

結論

Redisの永続化は、信頼性の高いデータ管理の基礎です。RDBとAOFはどちらも明確な利点とトレードオフを提供します。RDBは、高速な再起動とバックアップのためのコンパクトなスナップショットを提供し、重要性の低いデータや定期的なアーカイブに理想的です。AOFは、すべてのコマンドをログに記録することで優れた耐久性を提供し、最小限のデータ損失が最重要であるクリティカルなデータセットに適しています。

ほとんどのプロダクション環境では、RDBとAOFの両方を活用すること（特にRedis 4.0以降のハイブリッド形式）が、最も堅牢なソリューションを提供し、効率的な回復と強力なデータ耐久性の両方を実現します。各永続化方法の特性とアプリケーションの要件を慎重に比較検討することで、貴重なデータを保護し、Redisデプロイメントの回復力を確保するための情報に基づいた決定を下すことができます。