DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

最適なRedis永続化戦略の選び方：RDB vs AOF

RedisのRDBとAOFの永続化を比較：データ損失のトレードオフ、復旧速度、書き込みオーバーヘッド、本番環境での設定選択肢。

最適なRedis永続化戦略の選び方：RDB vs AOF

Redisはデータをメモリに保存するため、簡単に再構築できないものに依存する前に永続化戦略が必要です。RDBとAOFの選択は、失う可能性のあるデータ量、Redisの再起動速度、ワークロードが生み出すディスクI/Oに影響します。

定期的なスナップショットで十分な場合はRDBを使用します。より厳密な耐久性が必要な場合はAOFを使用します。実用的な耐久性と簡単なバックアップの両方が必要な場合は両方を使用しますが、実際のデータセットで復旧をテストしてください。

Redisの永続化を理解する

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

  • RDB（Redis Database）: データセットの特定時点のスナップショット。
  • AOF（Append-Only File）: サーバが実行したすべての書き込み操作のログ。

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

Redis Database（RDB）

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

RDBの仕組み

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

このプロセスにより、親プロセスは応答性を維持するため、スナップショット取得中もRedisはクライアントリクエストに応答し続けることができます。

RDBの利点

  • コンパクトなバックアップ: RDBファイルはバイナリ圧縮されており、Redisデータセットの非常にコンパクトな表現を提供します。そのため、バックアップやディザスタリカバリに最適です。
  • 高速な再起動: RDBファイルの再読み込みは、特に大規模データセットの場合、AOFファイルの再生よりも大幅に高速です。これは、単一の事前フォーマットされたバイナリファイルを読み込むためです。
  • 最小限のディスクI/O: RDB保存は設定された間隔でのみ発生するため、保存中でないときのディスクI/Oは最小限です。これにより、通常の運用時のパフォーマンスが向上する可能性があります。
  • 転送が容易: 単一のコンパクトなファイルであるため、RDBバックアップはディザスタリカバリやアーカイブ目的でリモートデータセンターに簡単に転送できます。

RDBの欠点

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

RDBの設定

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

# 900秒（15分）ごとに、少なくとも1つのキーが変更された場合にデータベースを保存
save 900 1

# 300秒（5分）ごとに、少なくとも10のキーが変更された場合にデータベースを保存
save 300 10

# 60秒ごとに、少なくとも10000のキーが変更された場合にデータベースを保存
save 60 10000

# RDB永続化を無効にする（すべてのsaveディレクティブをコメントアウトするか、以下を明示的に設定）
# save ""

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

Append-Only File（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スナップショットよりも強力な耐久性を提供します。everysecを使用すると、Redisは通常、確認済みの書き込みの約1秒分の損失に制限されますが、オペレーティングシステムやディスクの障害が耐久性に影響を与える可能性があります。
  • データ損失の低減: クラッシュが発生した場合、fsyncポリシーに応じて、失われるデータが大幅に少なくなります（またはまったく失われません）。
  • 検査可能な形式: AOFはRedisプロトコルコマンドを保存するため、RDBファイルよりもRedisツールで簡単に検査および修復できます。

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を設定する必要があります。

# AOF永続化を有効にする
appendonly yes

# アペンドオンリーファイルの名前（デフォルト："appendonly.aof"）
appendfilename "appendonly.aof"

# appendfsyncオプション：always、everysec、no
appendfsync everysec

# AOFファイルがベースの2倍のサイズで、かつ64MB以上のときに自動リライト
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs AOF：比較概要

機能 RDB（Redis Database Backup） AOF（Append-Only File）
メカニズム 特定時点のスナップショット（バイナリファイル） Redisプロトコル形式での書き込み操作のログ
データ損失 保存ポイント間での損失の可能性 everysecで通常約1秒、alwaysで最も強力
パフォーマンス 通常時の書き込みパフォーマンスが高く、fork()でブロックの可能性 強いfsyncで書き込みが遅くなり、I/Oがより一貫性を持つ
ファイルサイズ 非常にコンパクトなバイナリファイル 一般的に大きく、操作に応じて増加
復旧時間 大規模データセットで高速 大規模データセットで低速（コマンドの再生）
バックアップの容易さ 単一のコンパクトなファイル、バックアップ/DRに容易 ファイルが大きく、リライトなしでは管理が難しい可能性
可読性 人間には読めない RDBより検査しやすい
Redisのデフォルト はい（saveディレクティブあり） いいえ（デフォルトはappendonly no）

ハイブリッドアプローチ：RDBとAOFの併用

RedisはRDBスナップショットとAOFを一緒に使用できます。AOFが有効な場合、Redisは通常より最新であるため、起動復旧にAOFを使用します。最新のRedisでは、aof-use-rdb-preamble yesが有効な場合、リライトされたAOFファイル内でRDBプリアンブルを使用することもでき、リライトと再起動が高速化されます。

  • より高速なリライト: ハイブリッドAOFのRDB部分は、リライトプロセスに非常に高速な初期スナップショットを提供します。
  • （潜在的に）より高速な再起動: Redisが再起動すると、最初にAOFファイルのRDB部分を読み込み（これは高速です）、その後続くAOFコマンドを再生します。
  • より優れた耐久性: AOFの最小限のデータ損失の恩恵を引き続き受けられます。

ハイブリッドAOFが有効であると仮定する前に、Redisのバージョンと設定を確認してください。

適切な永続化戦略の選択

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

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

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

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

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

3. RDBとAOFの両方を使用する場合（ほとんどの重要なアプリケーションに推奨）

  • バランスの取れた耐久性と復旧: これは、データの耐久性が重要でありながら、効率的な再起動とバックアップも必要な本番システムに推奨されるアプローチです。
  • 堅牢性: 追加の保護層を提供します。一方の永続化方法が破損しても、もう一方で復旧できる可能性があります。
  • ハイブリッドAOF: サポートされ有効になっている場合は、RDBプリアンブルAOF形式を活用します。

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

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

まとめ

習慣ではなく復旧要件に基づいて永続化を選択してください。キャッシュ専用のRedisは、多くの場合RDBまたは永続化なしで使用できます。セッション、キュー、またはアプリケーション状態に使用されるRedisは、通常、AOF、テスト済みのバックアップ、およびデータが十分に高速に戻ってくることを証明する再起動ドリルが必要です。