AOF自動書き換えの境界線：`auto-aof-rewrite-percentage` が握る耐障害性とCPUのトレードオフ
Redisの運用において、永続化レイヤーのチューニングはシステムの生死を分ける境界線だ。特にAppend Only File（AOF）方式を採用する場合、データの整合性と引き換えに、ファイルサイズは容赦なく肥大化していく。
そのAOF肥大化を防ぎ、バックグラウンドでの再構築（AOF Rewrite）のトリガーを司る核心的パラメータが `auto-aof-rewrite-percentage` である。
今回は、この設定値がRedisの内部アーキテクチャ（fork、Copy-on-Write、OSページキャッシュ）にどのような影響を及ぼし、大規模環境においていかにして「システムの限界」を突破すべきか、その極限の知見を紐解く。
—
1. 内部メカニズムの解剖：なぜパーセンテージ制御が必要なのか
AOFはRedisに対するすべての書き込みコマンドを追記していくログ構造（Log-structured）を採用している。そのため、同じキーに対して何回も `SET` を繰り返した場合、AOFファイルには「過去の無駄な更新履歴」が延々と蓄積される。
ここで発生するのが、「メモリ上のデータセット（Dataset in memory）は小さく保たれているのに、AOFファイルは数倍のサイズに膨れ上がっている」という現象だ。
AOF Rewrite（BGREWRITEAOF）の本質
Redisはこの肥大化を解消するため、現在のメモリ上のデータを逆算し、「現在の状態を再現するのに必要な最小限のコマンド群」だけを抽出し、新しいAOFファイルをクリーンな状態から生成する。これが `BGREWRITEAOF` である。
このプロセスはメインスレッドをブロックしないよう、以下のステップで非同期実行される。
1. `fork(2)` の呼び出し: 親プロセス（Redisメイン）から子プロセスが生成される。
2. 子プロセスによる走査: 子プロセスはメモリ上の全キー空間をイテレートし、現在の状態を最小限のコマンドに変換して一時的なAOFファイルに書き出す。
3. 差分バッファ（AOF rewrite buffer）のフラッシュ: forkから書き込み完了までの間にメインスレッドが受けた新たな書き込みコマンドは、専用のバッファに蓄積され、最後に新しいAOFファイルへアペンドされる。
4. アトミックなファイル置き換え: `rename(2)` システムコールにより、古いAOFファイルが一瞬で新しいファイルに置き換えられる。
—
2. `auto-aof-rewrite-percentage` と `auto-aof-rewrite-min-size` の共犯関係
`auto-aof-rewrite-percentage` は単体では機能しない。常に以下の2つのパラメータの「論理積（AND）」によって発動条件が決定される。
- `auto-aof-rewrite-percentage 100` （デフォルト）
- `auto-aof-rewrite-min-size 64mb` （デフォルト）
判定アルゴリズムの数理
Redisのバックグラウンドタスク（`serverCron`）は、毎秒一定回数、以下の条件を評価している。
// Redisソースコード（aof.c 近傍の概念実装）
long long base_size = server.aof_rewrite_base_size;
long long current_size = aofCurrentSize;
// 初回書き換え、または前回の書き換え完了時のサイズと比較
if (base_size == 0) {
// まだ一度も書き換えが行われていない場合、起動時のサイズや前回の基準を適用
} else if (current_size > base_size &&
(current_size – base_size) 100 / base_size >= server.aof_rewrite_percentage &&
current_size >= server.aof_rewrite_min_size) {
// 閾値超え：BGREWRITEAOFをスケジュール
rewriteAppendOnlyFileBackground();
}
ここで重要なのは、「前回の書き換え完了時のサイズ（`aof_rewrite_base_size`）」が基準になる点だ。
例えば、デフォルトの `100`（100%増＝2倍）に設定されている場合、AOFファイルが前回の終了時から2倍のサイズに膨れ上がった瞬間にリライトが走る。
—
3. 現場で直面する「限界」とアーキテクチャ上の罠
デフォルト設定（`100` と `64mb`）は、小規模な検証環境や一般的なWebアプリケーションの初期段階においては機能する。しかし、メモリフットプリントが 50GB、100GB を超えるような大規模インメモリキャッシュ層では、このデフォルト値はシステムを崩壊させる時限爆弾になり得る。
罠1: `fork()` のレイテンシ爆発とCopy-on-Write（CoW）の悲劇
`BGREWRITEAOF` のトリガーは `fork()` を伴う。
メモリが数十GB搭載されたサーバーで `fork()` を実行すると、ページの参照テーブル（Page Table）の複製コスト自体はミリ秒単位であっても、その後のCopy-on-Write（CoW）によるメモリコピーの負荷がシステム全体のCPUとメモリバスを圧迫する。
もし `auto-aof-rewrite-percentage` が小さすぎると、この高コストな `fork()` が頻繁に発生し、メインスレッドのレイテンシ（LATENCY）が跳ね上がり、P99 / P99.9 レイテンシの悪化を招く。
罠2: 小さすぎる `min-size` と無駄なI/O
データセットが数GBあるにもかかわらず、`min-size` がデフォルトの64MBのままだと、運用初期のわずかな書き込み変動ですぐにリライト条件を満たしてしまう。結果として、ディスクI/O（特にSSDへの書き込み帯域）が常に飽和状態になり、SSDの寿命を削るだけでなく、OSのページキャッシュを汚染することになる。
—
4. チーフアーキテクトが推奨する実戦的チューニング指針
大規模Redisクラスターを設計・運用するにあたり、私は以下の戦略に基づき `auto-aof-rewrite-percentage` を再定義することを強く推奨する。
① 大規模データセット（RAM > 32GB）における設定の引き上げ
メモリが巨大な環境では、`fork()` の頻度を極限まで下げる必要がある。
デフォルトの `100`（2倍）から、`200`（3倍）〜 `300`（4倍）へと引き上げることで、リライトの頻度を抑制し、CPUサイクルとレイテンシの安定性を優先する。
例: メモリ64GB級のクラスタにおける推奨設定の方向性
auto-aof-rewrite-percentage 200
auto-aof-rewrite-min-size 1gb
これにより、前回のサイズから最低でも3倍に膨れ上がるか、あるいは1GBを超えない限り、無駄な `fork()` は発生しなくなる。
② ディスク容量とリストア速度のトレードオフ計算
パーセンテージを上げすぎることのデメリットは、「障害発生時のリストア（再起動時のAOFロード）にかかる時間」が増大することだ。
AOFファイルが不必要に肥大化した状態でRedisがクラフト（強制終了）した場合、次回の起動時に数千万〜数億のコマンドを再実行（Replay）するため、起動に数十分を要する事態に陥る。
したがって、以下の数式を頭に入れ、許容できるRTO（目標復旧時間）から逆算して上限値を決めるべきだ。
$$\text{許容可能な最大AOFサイズ} = \text{RAMの使用量} \times (1 + \text{rewrite-percentage} / 100)$$
—
5. 結び：監視なきチューニングは「ギャンブル」である
`auto-aof-rewrite-percentage` は、システムのワークロード（Write/Read比率、データのライフサイクル、オブジェクトの平均サイズ）によって最適解が完全に変わる。
必ず `INFO persistence` のメトリクスを監視し、以下の値の挙動をトレースせよ。
- `aof_current_size`: 現在のAOFファイルサイズ
- `aof_base_size`: 直近のリライト完了時のサイズ
- `aof_rewriting`: 現在リライトが実行中か（0 or 1）
監視の急所を突くためのCLIコマンド例
redis-cli INFO persistence | grep -E “aof_current_size|aof_base_size|aof_rewriting”
勘やデフォルト値に依存するな。自身のシステムの書き込みスループットとメモリの変化曲線を観測し、この境界線を意図してコントロールできた時、あなたは真にRedisを飼いならしたアーキテクトと言えるだろう。
コメント