こんにちは！ Redisの世界へようこそ。
日々、膨大なデータを高速にさばくインフラの裏側を覗いていると、データベースが機嫌を損ねないように「いかに上手に機嫌を取るか」がエンジニアの腕の見せ所だと痛感します。
今回は、Redisのデータが消えないように守るための仕組み（永続化）の中でも、少しマニアックだけど実務では超重要な「`no-appendfsync-on-rewrite`」という設定についてお話しします。
「名前が呪文みたいで難しそう……」と思ったそこのあなた、大丈夫です！
ここをクリアすれば、Redisの裏側の動きが手に取るようにわかるようになりますよ。優しく噛み砕いて解説していくので、ぜひ最後までついてきてくださいね。
—
1. そもそもRedisの「永続化（AOF）」ってなに？
Redisは、すべてのデータを「メモリ（RAM）」上で爆速で処理するデータベースです。
メモリは非常に高速ですが、弱点があります。それは「電源を落とすと、中身がぜんぶ消えてしまう」という点。
そこでRedisには、行った操作の履歴をノートにメモし続けるように記録する機能があります。これが AOF（Append Only File） という仕組みです。
日常の例えで考えてみよう
これを「お寿司屋さんでの注文」に例えてみましょう。
- メモリ（Redis本体）： 板前さんが頭の中で「今、何皿何が注文されたか」を覚えている状態。超速いけれど、お店の電源が落ちたら忘れちゃう。
- AOFファイル（ノート）： お客さんの注文が入るたびに、店員さんが「マグロ1丁！サーモン2丁！」とノートにガシガシ書き留めていく状態。万が一記憶が飛んでも、このノートを見返せば注文を復元できる。
このノートに書き込むとき、「お客さんが注文するたびに、すぐノートを本棚にしまいに行く（fsync）」のが基本の動作です。これをやるとデータは絶対に安全ですが、毎回本棚まで走るのでちょっと忙しくなりますよね。
—
2. AOFファイルの「大掃除（書き換え）」が始まると…？
Redisを長く使っていると、AOFの「ノート」はどんどん分厚くなっていきます。
「マグロ1皿」「やっぱりタコに変更」「あ、やっぱりマグロ」みたいな無駄な履歴も全部たまっていきます。これではノートが重くなりすぎて、読み込むのに時間がかかってしまいますよね。
そこで、Redisは定期的に「ノートの大掃除（AOF書き換え / Rewrite）」を行います。
- 大掃除のやり方：
今の最新の状態（結論）だけを綺麗にまとめた「新しいノート」を裏でこっそり作り直すんです。
ここで問題が発生します。
裏で大掃除（書き換え）をしている最中も、表ではお客さん（アプリ）がどんどん新しい注文をしてきます。つまり、「古いノートへの書き込み」と「綺麗にまとめた新しいノートを作るためのディスク作業」が、同時にハードディスク（ストレージ）を奪い合うことになるのです。
—
3. 本日の主役：`no-appendfsync-on-rewrite` とは？
ここで、今回のテーマである `no-appendfsync-on-rewrite` の出番です。
先ほど、「ノートに書くたびに、すぐに本棚にしまいに行く（fsync）」と言いましたよね。
ディスクのI/O（読み書きの交通渋滞）が起きている大掃除の最中にも、この「しまいに行く作業」を厳格に続けると、ハードディスクが悲鳴を上げてしまいます。結果として、Redis全体の処理がフリーズしたように遅くなってしまうのです。
この設定を `yes` にすると、大掃除（書き換え）の期間中だけ、「ちょっと今、大掃除で忙しいから、ノートを本棚にしまいに行く作業（fsync）は一時的にストップ！」と、一時休止させることができます。
設定のイメージ
- `no-appendfsync-on-rewrite no` （初期値）：
大掃除中も関係なく、厳格にノートをしまいに行く。安全第一だけど、ディスクが混雑してアプリの反応が遅くなるリスクがある。
- `no-appendfsync-on-rewrite yes` （推奨されるテクニック）：
大掃除中はしまいに行くのをちょっとサボる（※メモリ上には書いてある）。ディスクの渋滞を防ぎ、Redisの速度を維持する。ただし、この数秒間に万が一サーバーがブッ飛ぶと、その間のデータが数秒分消えるリスクがごくわずかに高まる。
—
4. 実務ではどう設定すべき？
「じゃあ、データを失いたくないから `no` にすべき？」と思いますよね。
しかし、実際の現場（プロダクション環境）では、大半のケースで `yes` に設定することが推奨されます。
なぜなら、大掃除の最中にディスクが完全に詰まってしまい、Redis全体が何秒も応答しなくなる方が、Webサービスとしては致命的な障害（タイムアウトなど）につながりやすいからです。「数秒間の書き込みの確実性」よりも「サービスの安定したレスポンス」を優先するという、エンジニアの知恵ですね。
設定の確認と変更方法
Redisの設定ファイル（`redis.conf`）を覗いてみましょう。
redis.conf の設定例
AOF書き換え中に fsync を一時停止するかどうか
yes にすると、書き換え中のディスク負荷（I/O渋滞）を軽減できます
no-appendfsync-on-rewrite yes
もし動いているRedisで設定を変えたい場合は、設定ファイル直しか、`CONFIG SET` コマンドでその場で変更することも可能です（※実務では設定ファイルを正として管理するのが基本です）。
コマンドで動的に変更する場合の例（redis-cli）
127.0.0.1:6379> CONFIG SET no-appendfsync-on-rewrite yes
OK
設定が正しく反映されたか確認
127.0.0.1:6379> CONFIG GET no-appendfsync-on-rewrite
1) “no-appendfsync-on-rewrite”
2) “yes”
—
まとめ
お疲れ様でした！ `no-appendfsync-on-rewrite` の正体、見えてきましたか？
- Redisはデータを守るためにノート（AOF）をつけている
- 定期的にノートの大掃除（書き換え）をする
- 大掃除中はハードディスクが忙しくなるので、一時的に「しまいに行く作業（fsync）」をサボらせて渋滞を防ぐのが `no-appendfsync-on-rewrite yes`
この設定一つをとっても、「データの安全性」と「システムのパフォーマンス」のどちらをどう取るかという、エンジニアリングのロマンが詰まっています。
ここをクリアできれば、もうRedisの永続化の仕組みで迷うことはありません。自信を持って、明日からの開発や運用に活かしてくださいね！
それでは、良きRedisライフを！
コメント