【入門編】 AOF書き換え (BGREWRITEAOF) – Redis

やあ。Redisの世界へようこそ。
Redisを触り始めると、必ず一度は「AOF」という言葉に出会うはずだ。そして、運用を続けていくと必ず直面するのが「AOFファイルが肥大化してディスクを圧迫する」という問題。

今日は、このAOFという「Redisの歴史書」を、いかにスマートに整理整頓するか、その極意を伝授しよう。難しい概念は抜きにして、まずは日常の風景から紐解いていくよ。

—

Redisは、メモリの中にあるデータを扱う超高速なデータベースだ。でも、メモリは電源を落とすとデータが消えてしまうよね。そこでRedisは、「これまで実行した命令」をすべてノートに書き留めているんだ。これが「AOF（Append Only File）」だ。

想像してみてほしい。君がスーパーで買い物をするときのメモを。

…これ、ただの「買い物リスト」なら、「今、冷蔵庫には何があるか？」を知るために、わざわざ全部読み直すのは面倒だよね？
実際には「何も入っていない」のに、メモだけがどんどん長くなっていく。これがAOFの「肥大化」という現象だ。

メモが100万行に増えたとき、Redisを再起動すると、その100万行を最初から最後まで律儀に読み直す必要がある。これでは時間がかかって仕方がない。

そこで登場するのが `BGREWRITEAOF` だ。
これは、「今の状態」を再現するために必要な、最小限のコマンドだけを書き直す魔法の機能だ。

先ほどの例で言えば、この魔法をかけるとこうなる。

これだけ。100万行あったメモが、たった1行の「結果」に凝縮される。これがAOF書き換え（Rewrite）の本質だ。

ここがエンジニアとして知っておくべきポイントだ。「BG」はBackgroundの略。
Redisはシングルスレッドで動く、極めて潔癖で速いシステムだ。もし書き換え作業をメインの仕事の合間にやらせたら、その間、Redisは止まってしまう。

そこでRedisは、「今の自分」をそっくりそのままコピー（フォーク）して、別の分身に書き換え作業を丸投げするんだ。
これなら、メインのRedisはユーザーからの注文を受け続けられるし、裏側で分身がせっせと「断捨離」を終えてくれる。

Redis CLIから、このコマンドを叩くのはとても簡単だ。

Redisに接続して、書き換えをリクエストする
127.0.0.1:6379> BGREWRITEAOF
返ってくるメッセージ
“Background append only file rewriting started”

このコマンドを打つと、Redisは裏側で以下のプロセスを実行する。

1. フォーク: 自分自身のコピーを作成。
2. 書き出し: 分身がメモリ上の現在の状態をスナップショットとして書き出す。
3. 同期: 書き換え中に発生した新しい命令もちゃんと追記する。
4. 切り替え: 古い巨大なファイルと、新しく作ったスリムなファイルを入れ替える。

この「書き換え」は便利だけど、魔法ではない。いくつか気をつけておくべきことがある。

頻度はほどほどに: `auto-aof-rewrite-percentage` という設定がある。デフォルトでは「ファイルサイズが2倍になったら書き換える」ようになっているが、頻繁すぎるとディスクへの書き込み負荷（I/O負荷）が高まる。
メモリの空き容量: フォークした瞬間に、Redisは一時的にメモリを消費する。メモリがギリギリの状態で運用していると、最悪の場合、OSにプロセスを殺される（OOM Killer）リスクがある。

—

AOFの書き換えを理解することは、Redisというシステムが「いかに効率よく、かつ止まらずに仕事をするか」という哲学を理解することに他ならない。

ここを理解できれば、君はもうRedisの初級者を卒業したと言ってもいい。
Redisは、こういった「いかに無駄を省くか」という工夫の塊なんだ。ぜひ、運用する際は「今、僕のAOFファイルはどのくらいスリムかな？」と時々覗いてみてほしい。

どうだい？ Redisの基本、もうバッチリだろう？
また壁にぶつかったら、いつでも聞きに来てくれ。君のエンジニアとしての成長を応援しているよ。