【実務・中級編】 AOFタイムスタンプ記録 – Redis

Redis AOF タイムスタンプ記録: ポイントインタイムリカバリを極めるための実践論

諸君、本日はRedisにおけるAOF（Append Only File）のタイムスタンプ記録機能、そしてそれがもたらすポイントインタイムリカバリ（Point-in-Time Recovery: PITR）について、我々が実務で直面する課題と、それをどう乗り越えるか、その核心に迫りたい。

巷には「AOFを使えばバックアップできる」という浅い理解が蔓延している。しかし、我々が目指すべきは、単なるバックアップではない。障害発生時、あるいは誤操作発生時に、「あの時点」まで正確にデータを復旧できる、「ポイントインタイム」という概念を、我々のシステムでいかに実現するか、これが重要だ。

AOFの基本と、タイムスタンプ記録の意義

まず、AOFの基本から再確認しよう。AOFは、Redisサーバーが受け取ったすべての書き込みコマンドを時系列で記録していく。これにより、Redisは再起動時にこれらのコマンドを再実行することで、データを復旧できる。

しかし、標準的なAOF設定では、ファイルは単にコマンドを連ねていくだけだ。これでは、ある時点までの状態を「正確に」再現することは難しい。なぜなら、AOFファイルが生成されてから、あるコマンドが実行されるまでの間に、サーバーがクラッシュする可能性は常に存在するからだ。

ここで登場するのが、AOFファイルへのタイムスタンプ記録だ。Redis 4.0以降、AOFファイルには、特定のコマンド群の前に、そのコマンドが実行されたUnixタイムスタンプが記録されるようになった。具体的には、`BGREWRITEAOF`コマンドが実行される際、RedisはAOFファイルの内容を整理し、その際に各コマンドの実行タイムスタンプを付与する。

このタイムスタンプ記録がなぜ重要か？それは、PITRの土台となるからだ。タイムスタンプが付与されたAOFファイルがあれば、我々は以下のシナリオで強力な復旧能力を発揮できる。

特定時点への復旧: 例えば、昨日の午前10時30分に発生したデータ破損を検知した場合、その時点までのAOFデータを正確に再現できる。
差分バックアップとの連携: RDBスナップショットとAOFファイルを組み合わせることで、より効率的かつ安全なバックアップ戦略を構築できる。

実践！AOFタイムスタンプ記録の設定と利用

では、具体的にどう設定し、どう利用するのか。

1. AOFの有効化と設定

まず、Redisの設定ファイル（`redis.conf`）でAOFを有効にする必要がある。

.conf
AOFを有効にする
appendonly yes

AOFファイルの保存先（デフォルトはRedisのデータディレクトリ）
appendfilename “appendonly.aof”

AOF書き込みポリシー
always: 各コマンド実行後にディスクへ書き込む (最も安全だがパフォーマンス影響大)
everysec: 1秒に1回ディスクへ書き込む (推奨設定、パフォーマンスと安全性のバランスが良い)
no: OSのキャッシュに任せる (最も高速だが、クラッシュ時のデータ損失リスクが高い)
appendfsync everysec

`appendfsync`の設定は、パフォーマンスとデータロスのリスクのトレードオフとなる。実運用では、多くの場合 `everysec` が採用される。

2. `BGREWRITEAOF` によるタイムスタンプの付与

AOFファイルは、時間とともに肥大化していく。そこで、定期的にAOFのリライト（`BGREWRITEAOF`）を実行し、ファイルサイズを最適化する必要がある。このリライトの際に、Redisはタイムスタンプを付与する。

手動でリライトを実行するには、`redis-cli` から以下のコマンドを実行する。

redis-cli BGREWRITEAOF

あるいは、Redisが自動でリライトを実行する条件を設定することも可能だ。

.conf
AOFファイルが指定されたサイズを超えたら自動でリライトする
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

この設定により、AOFファイルが現在のサイズから100%増加し、かつ64MBを超えた場合に、自動的にリライトが実行される。

3. ポイントインタイムリカバリの実行

PITRを実現するには、以下の手順を踏む。

1. 最新のRDBスナップショットを取得する。
2. RDBスナップショット以降のAOFファイル（タイムスタンプ付き）を取得する。
3. Redisサーバーを停止する。
4. RDBスナップショットをRedisのデータディレクトリに配置する。
5. 取得したAOFファイルをRedisのデータディレクトリに配置する。
6. Redisサーバーを起動する。

Redisは起動時に、まずRDBファイルをロードし、その後AOFファイルを適用する。AOFファイルにタイムスタンプが付与されている場合、Redisは「どの時点」までのコマンドを適用すべきかを判断し、不要なコマンド（リライト後のAOFファイルには、古いコマンドの重複が含まれることがある）をスキップしながら、指定された時点までデータを復旧しようとする。

注意点:
Redis 4.0以降では、AOFリライト時にタイムスタンプが記録されますが、復旧時に特定のタイムスタンプを指定して開始する直接的なコマンドは存在しません。 PITRは、RDBスナップショットと、その時点以降のAOFファイル群を組み合わせ、人間が手動でどのAOFファイルまで適用するかを判断して実行するプロセスです。

より洗練されたPITR戦略としては、RDBスナップショットを定期的に取得し、その間のAOFファイルをアーカイブし、必要に応じて特定のRDBと、それに続くAOFファイル群を組み合わせて復旧するという運用が考えられます。

堅牢な設計パターンとパフォーマンスへの配慮

1. RDBとAOFの併用戦略

AOFのタイムスタンプ記録は強力だが、万能ではない。RDBスナップショットとAOFを併用することで、より堅牢で効率的なバックアップ・リカバリ戦略を構築できる。

RDB: 定期的なフルバックアップとして、データ損失リスクを低減する。`save` コマンドや `BGSAVE` コマンドで取得する。
AOF: RDB取得時点からの増分リカバリとして機能する。`appendfsync everysec` を設定し、データ損失を最小限に抑える。

この組み合わせにより、短時間でのリカバリ（RDB + 最新AOF）と、より長期間の履歴保持（定期的なRDBと、その間のAOFアーカイブ）を両立できる。

2. AOFリライトの自動化と監視

`BGREWRITEAOF` は、Redisのパフォーマンスに影響を与える可能性がある。特に、リライト中はCPUとディスクI/Oが消費される。

タイミングの最適化: リライトは、トラフィックが少ない時間帯に自動実行されるように設定する。
監視: AOFファイルサイズ、リライトの頻度、リライトにかかる時間などを監視し、異常を早期に検知する。
ディスク容量: AOFファイルは時間とともに肥大化するため、十分なディスク容量を確保すること。

3. ポイントインタイムリカバリのテスト

何よりも重要なのは、定期的なリカバリテストである。机上の空論で終わらせず、実際に本番環境と同等のデータ量で、様々な障害シナリオを想定したリカバリテストを繰り返し実施すること。これにより、手順の不備、設定の誤り、タイムスタンプ記録の落とし穴などを事前に発見できる。

結論: AOFタイムスタンプ記録は「点」ではなく「線」で捉える

AOFのタイムスタンプ記録機能は、我々に「特定の時点」への復旧という強力な武器を与えてくれる。しかし、それは単に設定一つで実現する魔法ではない。RDBとの併用、自動リライトの最適化、そして何よりも、定期的なリカバリテストという実践を通じて、初めてその真価を発揮する。

我々エンジニアは、常に「もしもの時」を想定し、データという資産を守り抜く責任がある。AOFのタイムスタンプ記録を深く理解し、それを活用した堅牢なアーキテクチャを設計・実装していくこと。それが、我々が信頼されるテクニカルリードとして、チームに、そしてプロダクトに貢献できる道だと信じている。

さらに深く掘り下げたい諸君は、Redisの公式ドキュメントを参照し、自身の環境で実験を重ねることを強く推奨する。現場で会おう。