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

AOF vs. RDB 永続化パフォーマンスのトレードオフ比較

RedisのAOFとRDBの永続化におけるレイテンシ、耐久性、復旧時間、ファイルサイズ、本番設定のトレードオフを比較します。

AOF vs. RDB 永続化パフォーマンスのトレードオフ比較

Redisの永続化は、失っても構わないデータ量とサーバーが吸収できるディスク作業量のトレードオフです。しかし、永続化を有効にして再起動後にデータを復旧できるようにする場合、開発者はメカニズムを選択する必要があります。Redisの主要な永続化方法は、スナップショット（RDB） と追記専用ファイル（AOF） の2つです。それぞれのパフォーマンスへの影響、耐久性の特性、設定のトレードオフを理解することは、速度とデータ安全性の要件に合わせてRedisをチューニングする上で重要です。

RDBスナップショットはコンパクトで読み込みが高速です。AOFはより頻繁に書き込みを記録し、通常はより良い復旧ポイントを提供しますが、ディスクI/Oのコストが高くなります。

Redisの永続化を理解する

Redisは全データセットを揮発性メモリに保存します。永続化メカニズムは、このデータをディスクに保存し、Redisが再起動時にデータセットを再読み込みできるようにするために必要です。これにより、サービス中断や再起動時にもデータの可用性が確保されます。RDBとAOFは、根本的に異なるアプローチでこの目標を達成し、それぞれ異なるパフォーマンスプロファイルをもたらします。

1. Redisデータベース（RDB）スナップショット

RDBは、指定された間隔でデータセット全体のポイントインタイムスナップショットをコンパクトに作成します。このデータをバイナリファイル（dump.rdb）に保存します。

RDBの仕組みとパフォーマンスへの影響

RDB永続化は、BGSAVEコマンド（バックグラウンド保存）に大きく依存しています。保存がトリガーされると：

  1. フォーク： Redisはメインプロセスを子プロセスにフォークします。
  2. スナップショット： 子プロセスがデータセット全体をディスク上のRDBファイルに書き込みます。
  3. メインスレッドへの影響なし（ほぼ）： 子プロセスがディスクI/Oを処理するため、メインのRedisスレッドは書き込み操作中にブロックされることなく、クライアントリクエストへの応答を続けます。

パフォーマンスに関する考慮事項：

  • 書き込みレイテンシ： 一般的に、RDBは保存操作中に書き込みレイテンシにほとんど影響を与えません。これは作業がオフロードされるためです。主なパフォーマンスコストは、フォーク時と大規模ファイル書き込み時に発生するCPUスパイクと初期のI/Oバーストです。
  • 復旧時間： RDBは単一の最適化されたファイルであるため、再起動時に非常に高速に読み込まれ、復旧レイテンシを最小限に抑えます。
  • 耐久性のトレードオフ： スケジュールされた保存の間（例：5分ごと）にRedisがクラッシュした場合、最後の保存以降に行われたすべての書き込みが失われます。これにより、RDBはAOFよりも耐久性が低くなります。

RDB保存の設定

RDB保存は、redis.confファイルのsaveディレクティブを使用して、時間間隔と変更数を指定して設定します：

save 900 1     # 900秒（15分）以内に1つのキーが変更された場合に保存
save 300 10    # 300秒（5分）以内に10個のキーが変更された場合に保存
save 60 10000  # 60秒（1分）以内に10000個のキーが変更された場合に保存

2. 追記専用ファイル（AOF）永続化

AOFは、Redisサーバーが受信したすべての書き込み操作を追記専用のログファイルに記録します。Redisが再起動すると、これらのコマンドを順次再生してデータセットを再構築します。

AOFの仕組みとパフォーマンスへの影響

RDBとは異なり、AOFはトランザクションログに焦点を当てています。パフォーマンスプロファイルは、fsyncポリシーに大きく依存します。このポリシーは、Redisがバッファリングされたデータを物理ディスクに書き込む頻度を決定します。

AOF Fsyncポリシー：

ポリシー appendfsync設定 耐久性 パフォーマンスへの影響
毎秒 everysec 通常動作では良好。クラッシュ時には約1秒分の書き込みが失われる可能性あり バランスが良い。一般的な本番環境での選択肢。
同期なし no 低い（OSバッファに依存） 最速。OSクラッシュ時のデータ損失リスクが最大。
常に always 最も強いAOF耐久性ポリシー 最も遅い。すべての書き込みでディスク同期が発生するため、レイテンシが大幅に増加。

パフォーマンスに関する考慮事項：

  • 書き込みレイテンシ： appendfsync alwaysを使用する場合、すべての書き込みコマンドでディスク同期のレイテンシが発生し、RDBやインメモリ操作と比較して操作が大幅に遅くなります。everysecを使用すると、fsyncをバッチ処理することでこれを大幅に軽減します。
  • 復旧時間： AOFファイルは大きくなる可能性があり、数百万のコマンドを再生するには、コンパクトなRDBファイルを読み込むよりも時間がかかるため、復旧レイテンシが高くなります。
  • ファイルサイズ： AOFファイルは通常、RDBファイルよりもはるかに大きくなります。これは、データ構造の最終状態ではなく、コマンド（例：SET key value）を保存するためです。

AOFの有効化と設定

AOFはデフォルトで無効になっており、redis.confでappendonly yesを設定することで有効になります。重要な設定はappendfsyncです：

appendonly yes
appendfilename "appendonly.aof"
# 耐久性と速度のトレードオフに推奨される設定
appendfsync everysec

パフォーマンストレードオフ分析：AOF vs. RDB

RDBとAOFのどちらを選択するかは、生の動作速度（レイテンシ）と保証されたデータ復旧のどちらを優先するかによって決まります。

レイテンシとスループット

  • RDB（生の速度に最適）： 書き込みはバックグラウンドプロセスで処理されるため、メインのRedisスレッドは保存中に直接的なI/Oの影響をほとんど受けません。これにより、BGSAVEフォーク時にシステムに負荷がかかっていない限り、一般的に書き込みレイテンシが低くなります。
  • AOF（alwaysモード）： この設定は最も低速です。ディスクレイテンシがすべてのクライアント書き込みコマンドに直接導入されるため、p99レイテンシが高くなります。
  • AOF（everysecモード）： fsync操作がバッファリングされ、頻度が低いため、ほとんどの操作でRDBに近いパフォーマンスを提供します。

耐久性とデータ損失リスク

  • AOF（耐久性に最適）： 特にappendfsync alwaysの場合、最も高い耐久性を提供します。everysecでも、データ損失は1秒間に制限されます。
  • RDB（耐久性に劣る）： 保存スケジュールによっては、データ損失が数分から数時間に及ぶ可能性があります。

復旧時間

  • RDB（高速復旧）： 最適化されたコンパクトなバイナリ形式により、再起動時間が短くなります。
  • AOF（低速復旧）： 大規模なコマンドログの再生はスナップショットの読み込みよりも時間がかかり、再起動時のダウンタイムが増加します。

ベストプラクティス：両方の永続化方法の使用

高いパフォーマンスと強力な耐久性保証の両方が求められる環境では、RDBとAOFの両方の永続化を同時に有効にすることをお勧めします。

両方が有効な場合、Redisは起動時の再生にAOFファイルを使用して、最大のデータ整合性を実現します。また、定期的にRDBスナップショットを生成し続けます。

なぜ両方を使用するのか？

  1. より良い復旧オプション： 両方が有効な場合、Redisは通常、AOFの方がより完全であるため、最初にAOFを読み込みます。RDBを保持することで、バックアップとディザスタリカバリ用の追加のフォールバック成果物が得られます。
  2. 運用の柔軟性： RDBはコンパクトでアーカイブが容易ですが、AOFはデータ損失のウィンドウを狭めます。これらを組み合わせることで、さまざまな障害モードをカバーできます。

両方を使用するための設定スニペット：

# 1. RDBを有効にする
save 900 1

# 2. 'everysec'同期でAOFを有効にする
appendonly yes
appendfsync everysec

AOFファイルサイズの管理（リライト）

AOFに関する重要な運用上の懸念事項は、ファイルサイズの増大です。時間の経過とともに、AOFファイルは、以前の値を上書きするものであっても、すべての変更をログに記録するため、巨大になる可能性があります。これに対処するために、RedisはAOFリライトを提供しています。

AOFリライトは、データセットの現在の状態を再構築するために必要な最小限のコマンドセットのみを含む、新しい最適化されたAOFファイルを生成します。このプロセスは、現在のAOFファイルのサイズがベースサイズの一定の倍数を超えて大きくなったときに自動的にトリガーされます。

auto-aof-rewrite-percentage 100  # AOFファイルがベースサイズより100%大きくなったらリライト
auto-aof-rewrite-min-size 64mb    # ファイルが少なくとも64MB以上でなければリライトしない

リライトに関する注意： RDB保存と同様に、AOFリライトにはプロセスのフォークが含まれます。システムのメモリが制限されている場合、この一時的なメモリ使用量の倍増（実行中のインスタンスとリライト中のコピー）は、不安定性やスワップを引き起こす可能性があります。

まとめ

最近の書き込みを失うことよりも、高速な再起動、コンパクトなバックアップ、低い書き込みオーバーヘッドが重要な場合はRDBを使用してください。すべての書き込みを同期せずに、より狭い復旧ウィンドウが必要な場合は、appendfsync everysecを指定したAOFを使用してください。多くの本番システムでは、両方を有効にすることで、耐久性、バックアップの利便性、復旧オプションの実用的な組み合わせが得られます。