こんにちは！Redisの奥深い世界へようこそ。
あなたが今、Redisの「永続化（データを消えないように保存すること）」、特にその心臓部であるAOF（Append Only File）の仕組みにたどり着いたのは素晴らしいことです。ここをクリアすれば、あなたもRedisの挙動を手に取るように理解できるようになりますよ。
今回は、AOFの中でも少し玄人好みなテーマ、「AOFリライト中のfsync設定」について、専門用語をできるだけ使わずに、僕と一緒に紐解いていきましょう。
—
1. まずはおさらい：Redisの「AOF」ってなに？
Redisは、すべてのデータをメモリ上に置いて超高速に動くデータベースです。「メモリ上のデータは、サーバーの電源を切ったら消えちゃうじゃん！」という不安を解消するためにあるのが、AOFという仕組みです。
AOFは、「Redisに行った命令（Aを書いた、Bを消した、など）を、まるで料理のレシピノートのように、上から順番にすべて日記として書き留めていく方式」です。
もしRedisが突然クラッシュしても、このレシピノートを最初から順番にフムフムと実行していけば、見事にデータを元の状態まで復元できるというわけですね。
—
2. ノートが分厚くなりすぎて大ピンチ！「AOFリライト」の登場
さて、このレシピノート（AOFファイル）、ずっと書き続けているとどうなるでしょうか？
「Aをセット」「やっぱりAを消す」「Bをセット」「Bの値を書き換える」……。
何日も運営していると、ノートは無駄なメモ書きだらけで驚くほど分厚くなってしまいます。これでは復元するのに何時間もかかるし、ディスクの容量も圧迫してしまいますよね。
そこでRedis君は、定期的に大掃除をします。これが「AOFリライト（書き換え）」です。
過去の無駄なやり取りは一切無視して、「いま現在の結果、これだけ覚えておけばOK！」という最新のデータだけを綺麗にまとめた、新しいピカピカのノートを作り直す作業です。
—
3. 本日の本丸：「AOFリライト中のfsync」ってなに？
さて、ここからが今日のメインテーマです。
新しくて薄いノートを作っている最中（リライト中）、Redisはバックグラウンドで必死にディスク（ハードディスクやSSD）にデータを書き込んでいます。
ここで問題になるのが、「どれくらいの頻度で、ディスクにしっかり書き込ませるか（= fsync）」という設定です。
日常の例え話で考えてみよう
イメージしてください。あなたは今、分厚い教科書をきれいにノートにまとめ直す作業（AOFリライト）をしています。
- パターンA：几帳面すぎるあなた
「1文字書くごとに、ペンを置いて、下敷きを机の引き出しにしっかりしまい、鍵をかける（fsync）」
→ 安全性抜群ですが、手が疲れてノートが全然進みません（ディスクが渋滞を起こし、Redisの動きがカクカクになる）。
- パターンB：マイペースすぎるあなた
「全部書き終わるまで、机の上の整理整頓は一切しない！」
→ ノート作りは爆速で終わりますが、もし途中で地震（サーバーの障害）が起きたら、机の上の散らかったメモがどこに行ったか分からなくなって大惨事になります（データが消えるリスク）。
Redisの「AOFリライト中のfsync設定」は、この「安全性」と「スピード（ディスクの優しさ）」のバランスをどう取るかを決めるツマミなんです。
—
4. 具体的にどう設定するの？
Redisの設定ファイル（`redis.conf`）には、以下のような項目があります。
AOFリライト（またはディスクへの書き込み）の最中に、
Linuxのカーネルに対して「そろそろディスクに書き込んで！」と指示を出すタイミングの調整
no-appendfsync-on-rewrite yes
この `no-appendfsync-on-rewrite` という設定、直訳すると「リライト中はappendfsync（ディスクへの強制書き込み）をしなくてもいいよね？」という意味になります。
- `no-appendfsync-on-rewrite yes` にした場合（おすすめ！）
リライト（大掃除）の最中は、ディスクへの強制書き込み（fsync）を少しお休みします。
なぜなら、リライト中は裏でディスクがすでに大忙しでデータを書き込んでいるからです。そこにさらに「今すぐ書き込め！」と命令すると、ディスクがキャパオーバーを起こし、Redis全体の動きが一時的にフリーズしたようにピタッと止まってしまう（I/Oスパイク）のを防ぐためです。
- `no-appendfsync-on-rewrite no` にした場合
安全第一！リライト中であっても、容赦なく「今すぐディスクに書き込め！」と命令し続けます。
安全ですが、ディスクが悲鳴を上げ、ユーザーからのリクエストに対するRedisの返事が遅くなる（レイテンシが悪化する）リスクが高まります。
—
5. 先輩エンジニアからのアドバイス
実務の現場では、システムに求められる要件によってこの設定のチューニングを行います。
基本的には、`no-appendfsync-on-rewrite yes` に設定しておくことが多いです。なぜなら、リライト中の一瞬のタイミングで万が一障害が起きても、元の古いノート（古いAOFファイル）がまだ残っているため、最悪の事態（データの完全損失）は免れるからです。
「ディスクが悲鳴を上げて、Webサイト全体の動きが重くなるのを防ぎつつ、安全性を保つ」
この絶妙なバランスを取るのが、優れたエンジニアの腕の見せ所というわけですね。
ここをクリアできれば、あなたはもうRedisの「裏側の呼吸」まで理解できたも同然です。自信を持って、日々の開発や運用に向き合っていきましょう！何か分からないことがあれば、いつでも気軽に聞いてくださいね。
コメント