やあ、こんにちは！
Redisの世界へようこそ。伝説のチーフアーキテクトと呼ばれることもある私だけど、今日は肩の力を抜いて、君のRedisの旅をサポートする「頼れる先輩」として話をさせてほしい。
今日取り上げるテーマは、Redisの心臓部の一つ「AOF書き換え（Rewrite）」だ。
「なんだか難しそうな名前だな…」って思ったかい？大丈夫。ここをクリアすれば、Redisの裏側の仕組みが手に取るようにわかるようになるし、実務でトラブルが起きたときも慌てず対処できるようになる。
基礎から本質まで、たっぷり噛み砕いて伝えるから、コーヒーでも飲みながらリラックスして読んでいってくれ。
—
1. Redisの「メモ帳」：AOFとは何か？
まず、Redisがデータをどうやって覚えているかのお話から始めよう。
Redisは、超高速な「インメモリデータベース」だ。つまり、すべてのデータをパソコンのメモリ（RAM）の上に広げて保持している。だから電光石火の速さなんだけど、弱点もある。そう、電源を切ると（サーバーが落ちると）記憶がすべて消えてしまうことだ。
そこで登場するのが「AOF（Append Only File）」という仕組みだ。
これは例えるなら、「Redis君の作業ノート」だ。
- ユーザーAさんが「名前を田中にして」と言った → ノートに「`SET name 田中`」と書く
- ユーザーBさんが「年齢を25にして」と言った → ノートに「`SET age 25`」と書く
- ちょっと待って、さっきの「名前を田中にして」を「やっぱり鈴木にして」に変えた → ノートに「`SET name 鈴木`」と追記する
このように、Redisは自分が実行した命令を、上書きせずにひたすら一番後ろに書き足していく（Append Only）。もし万が一サーバーがプツンと切れてしまっても、このノートを最初から順番に読み直せば、消えたデータを完璧に復活させることができるというわけだ。安全第一の素晴らしい仕組みだね。
—
2. ノートがパンクする！？ AOFの宿命
さて、この「作業ノート（AOFファイル）」、順調に働き続けてくれるのはいいんだけど、一つ大きな問題がある。
使えば使うほど、ノートがどんどん分厚くなっていくんだ。
例えば、こんなやり取りを想像してほしい。
1. 「カウンターを1にする」（`SET counter 1`）
2. 「カウンターを2にする」（`SET counter 2`）
3. 「カウンターを3にする」（`SET counter 3`）
…
100万回繰り返す。
AOFノートには、この100万行の歴史がすべて残る。でも、今の状態を知るために本当に必要な情報ってなんだい？
そう、「最後にカウンターはいくつだったか（最終的な結論：`SET counter 1000000`）」だけだよね。
過去の「1だった」「2だった」という経緯は、今のデータ復元にはもう不要なゴミなんだ。なのに、ノートが何ギガバイトにも肥大化してしまうと、こんなデメリットが出てくる。
- ハードディスクの容量を無駄に圧迫する
- 万が一のサーバー再起動のとき、Redisがこの膨大なノートを読み込むのに時間がかかりすぎて、サービスがなかなか始まらない（ダウンタイムが長くなる）
「これじゃいかん！」ということで登場するのが、今回の主役「AOF書き換え（Rewrite）」なんだ。
—
3. 本日の主役：AOF書き換え（Rewrite）の魔法
じゃあ、この分厚くなったノートをどうやってスリム化するのか？
日常の例えで言えば、「ノートの総集編（ダイジェスト版）を作る作業」だ。
Redisは、肥大化したAOFノートを整理したくなると、裏側でこっそりこんな作業をする。
1. 今のメモリの状態をパッと見る
「ええと、今のカウンターの最終的な値は『100万』っと。名前は『鈴木』ね」
2. 最小限のコマンドだけを書いた「新しい綺麗なノート」を作る
過去の100万行の履歴はすべて無視して、「今を再現するために必要な必要最低限の命令（スナップショット）」だけを、まっさらな新しいノートに書き出す。
`SET counter 1000000`
`SET name 鈴木`
3. ノートをバトンタッチする
新しい綺麗なノートの準備ができたら、今まで使っていた分厚い古いノートをゴミ箱に捨てて、新しいノートをこれからの「公式ノート」に任命する。
これがAOF書き換え（AOF Rewrite）の正体だ。
どうだい？やっていることは意外とシンプルだろう？
過去の無駄な歴史をきれいさっぱり忘れ去り、「今の最新の結果」だけをコンパクトに凝縮するスマートな作業なんだ。
—
4. 現場で役立つ！AOF書き換えのコントロール
この書き換え、実はRedisが裏で自動的にやってくれる。基本的には「ノートが前のサイズの2倍になったら」とか「ファイルが一定以上大きくなったら」自動発動するように設定されているんだ（`auto-aof-rewrite-percentage`などの設定値でコントロールする）。
でも、エンジニアとして覚えておいてほしいのは、手動でもこの書き換えを命令できるということだ。
もし運用していて「ちょっとAOFファイルが大きくなりすぎたな、今夜のうちにキレイにしておきたいな」と思ったら、Redisにこう命じればいい。
RedisのCLI（操作画面）から実行するコマンド
BGREWRITEAOF
【プロからのワンポイントアドバイス】
このコマンドの頭文字にある「BG」は Background（バックグラウンド） の略だ。
Redisはシングルスレッド（基本は同時にひとつの仕事しかできない）で有名だけど、この書き換え作業だけは、裏側の別動隊（子プロセス）にこっそりやらせる。だから、重い書き換えの最中でも、ユーザーからの「データをくれ！」というリクエストを止めることなく、サクサク動き続ける。この非同期設計こそが、Redisがプロの現場で愛され続ける理由の一つなんだ。
—
まとめ：ここをクリアすれば、Redisは怖くない！
お疲れ様！ここまで理解できれば、AOF書き換えの本質はもう完璧だ。
- AOFとは、Redisの「作業ノート（操作の履歴）」である。
- 肥大化すると、ディスクを圧迫し、復旧に時間がかかるようになる。
- AOF書き換えとは、過去の無駄な履歴を捨て、今のデータを再現する「最小限のコマンド集（ダイジェスト版）」に作り直す魔法である。
- `BGREWRITEAOF`を使えば、サービスを止めずに裏側で安全にキレイにできる。
インフラやデータベースの世界は、一見難しそうに見える仕組みも、紐解いてみれば「いかに効率よく片付けるか」という日常の工夫の延長線上にある。
ここをクリアした君なら、もうRedisの永続化の基本はバッチリマスターできているよ！自信を持って次のステップに進んでほしい。
さあ、次のアーキテクチャの話に進もうか？
コメント