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

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

RDBスナップショットとAOF永続化を習得し、Redisデータの損失から保護します。この包括的なガイドでは、両方の方法を比較し、`redis.conf`での設定を詳しく説明し、ベストプラクティスを概説します。RDBとAOFの組み合わせ方、最適な`appendfsync`ポリシーの選択方法、AOFのリライト管理、および障害発生後のデータ永続性と高速な復旧を保証するための監視の実装方法を学びます。

43 ビュー

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

人気のインメモリデータ構造ストアであるRedisは、障害からデータを保護するための堅牢な永続化メカニズムを提供します。これらのメカニズム（Redis Database (RDB) スナップショットとAppend-Only File (AOF) ロギング）を理解し、正しく設定することは、データ損失を最小限に抑え、迅速なリカバリを確保するために不可欠です。この記事では、RDBとAOFのニュアンスを掘り下げ、回復力の高いRedisデプロイメントを構築するためのベストプラクティスを説明します。

適切な永続化戦略またはその組み合わせを選択することは、データの耐久性、リカバリ時間、およびシステムパフォーマンスに直接影響します。RDBは時点のスナップショットを提供しますが、AOFはすべての書き込み操作をログに記録します。それぞれに長所と短所があり、最適な設定は、多くの場合、特定のアプリケーションのデータ損失許容度とパフォーマンス要件に依存します。

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

Redisは、データをディスクに永続化するための2つの主要な方法を提供しており、サーバーの再起動またはクラッシュ後にデータセットをリカバリできます。

1. Redis Database (RDB) スナップショット

RDBは、Redisデータセットの時点のスナップショットです。これは、メインのRedisプロセスをフォークし、子プロセスがデータセット全体をdump.rdbファイルに書き込むことで機能します。このプロセスは、バックアップと災害復旧に効率的です。

RDBの仕組み：

  • フォーク: Redisはfork()システムコールを使用して子プロセスを作成します。親プロセスはクライアントリクエストの処理を続行し、子プロセスはフォーク時のメモリ状態にアクセスします。
  • シリアライズ: 子プロセスは、データセット全体をコンパクトなバイナリ形式にシリアライズします。
  • ディスクへの保存: シリアライズされたデータは、指定されたファイル（デフォルトはdump.rdb）に書き込まれます。

RDB設定（redis.conf）：

# 秒数と変更されたキーの数が指定された値を少なくとも満たしている場合、DBを保存します。
# フォーマット: save <秒数> <変更数>
save 900 1       # 15分後に1つ以上のキーが変更された場合、保存
save 300 10      # 5分後に10個以上のキーが変更された場合、保存
save 60 10000    # 1分後に10000個以上のキーが変更された場合、保存

# ダンプファイルの名前。
dbfilename dump.rdb

# RDBファイルを保存するディレクトリ。
dir /var/lib/redis

RDBの利点：

  • コンパクトなファイルサイズ: RDBファイルは通常AOFファイルよりも小さいため、転送とロードが高速です。
  • 高速な再起動: 大規模なデータセットの場合、AOFログを再生するよりも単一のRDBファイルをロードする方が高速です。
  • シンプルなバックアップ戦略: RDBスナップショットは、時点のバックアップを作成するのに理想的です。

RDBの欠点：

  • データ損失の可能性: 保存の間隔でRedisがクラッシュした場合、最後のスナップショット以降に書き込まれたデータは失われます。保存の頻度が、潜在的なデータ損失ウィンドウを決定します。

2. Append-Only File (AOF)

AOFは、Redisサーバーが受信したすべての書き込み操作をログに記録します。Redisが再起動すると、AOFファイル内のコマンドを再実行してデータセットを再構築します。これはRDBよりもはるかに高い耐久性を提供します。

AOFの仕組み：

  • コマンドロギング: すべての書き込みコマンドがAOFファイルに追加されます。
  • 追記モード: ファイルは追記モードで書き込まれます。
  • fsyncポリシー: RedisがAOFバッファをディスクにフラッシュする頻度（fsync）を設定できます。これは耐久性にとって重要です。

AOF設定（redis.conf）：

# Append Onlyモードを有効にします。
aof yes

# AOFファイルの名前。
aof-rewrite-incremental-fsync yes

# AOFを有効にした場合、以下のリライトモードはサポートされません。
# AOF永続化はappendfsync () に依存します。オプションは以下の通りです。
# no: fsync() を実行しない。OSにデータバッファをフラッシュさせるだけ。高速だが、クラッシュ時にデータが失われる可能性がある。
# everysec: 1秒ごとにfsync() を実行。平均レイテンシは約30msだが、クラッシュ時に一部のデータが失われる可能性がある。
# always: 書き込み操作ごとにfsync() を実行。より安全だが、それほど高速ではない。
appendfsync everysec

# AOFファイルが大きくなりすぎた場合に自動的にリライトします。
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

AOFの利点：

  • 高い耐久性: appendfsync alwaysまたはappendfsync everysecを使用すると、AOFはデータ損失のリスクを大幅に軽減します。
  • 再構築: Redisはコマンドを再生することでデータセットを再構築できます。

AOFの欠点：

  • 大きなファイルサイズ: AOFファイルは、すべての操作をログに記録するため、時間が経つにつれて非常に大きくなる可能性があります。
  • 遅い再起動: 大きなAOFファイルを再生するには、RDBスナップショットをロードするよりも時間がかかる場合があります。
  • AOFリライト: Redisは、サイズを管理するために、AOFファイルを定期的にリライトしてよりコンパクトな形式にします。このプロセスはリソースを消費する可能性があります。

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

データ損失を効果的に防止するために、以下のベストプラクティスを検討してください。

1. RDBとAOFの両方を使用する（推奨）

最も堅牢なアプローチは、RDBとAOFの両方の永続化を有効にすることです。これにより、両方の方法の利点が組み合わされます。

  • バックアップのためのRDB: 災害復旧と高速な再起動のための便利な時点バックアップを提供します。
  • 耐久性のためのAOF: RDBスナップショットの間でRedisがクラッシュした場合でも、失われるデータは最小限（appendfsync設定による）になります。

設定例（redis.conf）：

# RDB永続化を有効にします
save 900 1
save 300 10
save 60 10000

# AOF永続化を有効にします
aof yes
appendfsync everysec

なぜこれが良いのか: サーバーがクラッシュした場合、RedisはまずRDBファイルをロードしようとします。RDBファイルが破損しているか見つからない場合、AOFファイルにフォールバックします。appendfsync everysec設定は、パフォーマンスと耐久性の間で良いバランスを取り、最悪のシナリオでも最大1秒のデータしか失わないことを保証します。

2. 適切なappendfsyncポリシーを選択する

これはAOF耐久性にとって最も重要な設定です。選択は、アプリケーションのデータ損失許容度によって異なります。

  • appendfsync no: 最も高いパフォーマンスですが、データ損失のリスクが最も高くなります（最後のOSフラッシュ以降のすべての書き込み）。
  • appendfsync everysec: ほとんどのユースケースで推奨されます。最小限のデータ損失（最大1秒）で良好なパフォーマンスを提供します。
  • appendfsync always: 最も高い耐久性ですが、頻繁なディスク同期により書き込みパフォーマンスが大幅に低下する可能性があります。

推奨: appendfsync everysecから開始します。書き込みパフォーマンスとデータ損失許容度を監視して、appendfsync alwaysが必要かどうか、またはそれほど重要でないデータに対してnoで十分かどうかを判断します。

3. RDB保存ポイントを賢く設定する

RDBの場合、許容できるデータ損失ウィンドウに一致する保存ポイントを選択します。頻繁な保存はデータ損失を減らしますが、CPU負荷を増加させます。

  • 例: 5分間のデータ損失が許容できない場合、その期間内にトリガーされる保存ポイントがあることを確認します。例：save 300 10。
  • バランス: CPU負荷を増加させる可能性があるため、絶対に必要な場合を除き、過度にアグレッシブな保存ポイント（例：save 10 100）は避けてください。

4. AOFリライトを効果的に管理する

AOFリライトは、AOFファイルサイズを管理可能に保つために不可欠です。ファイルが大幅に大きくなったときにリライトをトリガーするようにauto-rewrite-percentageとauto-rewrite-min-sizeを設定します。

  • デフォルト: aof-auto-rewrite-percentage 100は、AOFファイルが前回のリライトサイズの2倍になったときにリライトすることを意味します。aof-auto-rewrite-min-size 64mbは、小さいファイルではリライトが頻繁に発生しないようにします。
  • 監視: AOFファイルサイズに注意してください。過度に大きくなる場合は、これらのパラメータを調整するか、BGREWRITEAOFを使用して手動リライトをトリガーすることを検討してください。

5. 永続化ファイルの定期的なバックアップを実装する

永続化が有効になっていても、dump.rdbおよびAOFファイルを別の場所にバックアップすることは賢明です。これにより、ハードウェア障害、誤った削除、またはRedisインスタンス全体のストレージの破損から保護されます。

  • 戦略: 外部ツールまたはスクリプトを使用して、これらのファイルを定期的にネットワークストレージまたはクラウドバケットにコピーします。

6. RedisのヘルスとディスクI/Oを監視する

プロアクティブな監視は、データ損失を防ぐための鍵です。以下に注意してください。

  • Redisログ: 永続化、ディスクフルエラー、または書き込み遅延に関連する警告を探します。
  • システムメトリクス: ディスクI/O（特に書き込みレイテンシとスループット）、CPU使用率、およびメモリ消費量を監視します。
  • Redis INFO persistence: このコマンドは、最後の保存時間やAOFリライトステータスなど、RDBとAOFの状態に関する貴重な洞察を提供します。

7. 高可用性のためにRedis SentinelまたはClusterを検討する

厳密には永続化設定ではありませんが、Redis SentinelとRedis Clusterは、マスターノードが利用できなくなった場合にレプリカに自動的にフェイルオーバーすることにより、高可用性を提供します。これにより、ダウンタイムが大幅に削減され、結果として、永続化メカニズムも配置されている場合の潜在的なデータ損失のウィンドウが短縮されます。

結論

Redisでのデータ損失防止は、信頼性の高いアプリケーションを維持するための重要な側面です。RDBとAOF永続化の長所と短所を理解し、両方のメカニズムを使用する、適切なappendfsyncポリシーを選択する、AOFリライトを管理するなどのベストプラクティスを実装することにより、Redisデプロイメントの耐久性を大幅に向上させることができます。これらの設定に定期的なバックアップとプロアクティブな監視を組み合わせることで、データ損失に対する堅牢な防御が提供され、ビジネス継続性が確保されます。