こんにちは！Redisの奥深い世界へようこそ。
世界最高峰のエンジニアなんて紹介をされちゃうと緊張しちゃいますが、今日はお酒でも飲みながら話すようなリラックスした気持ちで、Redisの「永続化」と、その裏側にあるちょっとしたドラマについてお話しさせてくださいね。
Redisって、メモリ上で超高速にデータを処理するから「データの隠れ家」みたいで最高なんですが、いかんせんメモリなので、サーバーの電源がプツッと切れたりすると、データが消えちゃうという弱点があります。
そこで登場するのが、データをディスクに書き留めておく「永続化」という仕組みです。
今日はその永続化の主役の一つである「AOF（Append Only File）」と、そこに関わるちょっとマニアックだけど超重要な設定`aof-load-truncated`について、一緒に紐解いていきましょう。
ここをクリアすれば、Redisのトラブルシューティング能力はワンランクアップしますよ。バッチリマスターしていきましょう！
—
1. Redisの「日記帳」：AOFとは何か？
まずは基本から。Redisは、メモリの中にあるデータをそのままディスクにスナップショットとして保存する「RDB」という方法のほかに、「AOF（Append Only File）」という方法を持っています。
例えるなら、AOFはRedisがその日に行った操作をすべて書き留める「分厚い日記帳」です。
「キーAに『りんご』を代入した」「キーBを削除した」という命令（コマンド）を、起きた順番にひたすら下へ下へと書き足していくんです。
サーバーが再起動したときは、この日記帳を最初からパラパラとめくりながら「ふむふむ、最初はこうして、次はこうして…」と追体験することで、メモリ上のデータを完全に復元します。すごく確実で安心できる仕組みですよね。
—
2. トラブル発生！「日記帳の途中でペンが折れた」日
さて、ここからが本題です。
この「日記帳（AOF）」ですが、常にディスクに書き込みを行っています。もし、日記を書いているまさにその瞬間、突然の停電が起きたり、サーバーが強制終了（OOM Killerによるクラッシュなど）してしまったらどうなるでしょうか？
想像してみてください。
「キーCに『みかん』を…」と書いている途中で、ガクッ！と部屋の電気が消えてしまいました。
次にサーバーの電源を入れ直したとき、Redisはこう思います。
「よし、日記帳を読んで復元するか……おや？ 最後のページ、途中で文字が途切れて『キーCに『みかん』を…』の途中で終わってるぞ…？」
これが、「AOFファイルの破損（末尾の切れ端）」と呼ばれる現象です。未完成の文字がぽつんと残されている状態ですね。
—
3. 主役の登場：`aof-load-truncated` ってなに？
ここでRedisの頭を悩ませる重大な決断があります。
「途中で途切れた不完全な日記の続きを、どう扱うべきか？」
この挙動をコントロールするのが、今回のお題である設定 `aof-load-truncated` です。
`truncated`（トゥランケーテッド）とは、「切り詰められた、途中で切れた」という意味。つまりこの設定の名前は、「途中で切れたAOFファイルを、どうやって読み込むか？」という意味になります。
選べる選択肢は、大きく分けて2つです。
パターンA：`yes` の場合（デフォルト・優しさ重視）
> 「途中まででもいいから、読めるところだけ読んで起動してくれ！」
- 挙動: 末尾の壊れた部分だけを無視（切り捨て）し、無事に読めた直前までのデータを使ってRedisを起動します。
- メリット: サービスが止まらずにすぐ復旧できます。
- デメリット: 最後の数秒間（あるいは最後に書き込み中の瞬間）のデータが、ほんの少し失われる可能性があります。
パターンB：`no` の場合（厳格・データ完全性重視）
> 「不完全なデータなんて気持ち悪い！ 起動を拒否してくれ！」
- 挙動: 破損を見つけた瞬間、エラーを吐いて起動をストップします。
- メリット: 中途半端な状態でデータが崩れるのを防げます。
- デメリット: 人間が手動でファイルを修復するか、別の手段をとるまで、Webサービスが止まりっぱなしになります。
—
4. 実務ではどう設定すべき？ 先輩からのアドバイス
初心者の方からよく「どっちにすればいいんですか？」と聞かれます。
私の現場での経験から言うと、基本的にはデフォルトの `yes` のままで運用することが多いです。
なぜなら、Webシステムの現場では「少しのデータロス（数件のログやセッション情報など）があっても、一刻も早くサービスが復旧すること（高可用性）」が優先されることが多いためです。もし `no` にしていて、真夜中にサーバーが落ち、朝起きたら「データが壊れているので手動で直してください」とRedisがストライキを起こしていたら……冷や汗が止まりませんよね。
ただし、金融系のシステムなど「1円のデータ狂いも許されない」ような極限の環境では、`no` に設定し、万が一のときは専用の修復ツール（`redis-check-aof`）を使って安全にファイルを直す、というアプローチをとることもあります。
設定ファイル（`redis.conf`）での記述は以下のようになっています。
aof-load-truncatedの設定例
末尾が破損したAOFファイルを検知した際に、読み込みを続けるか（yes）、エラーで終了するか（no）
aof-load-truncated yes
非常にシンプルですが、システムの命運を握る大切なスイッチです。
—
まとめ
いかがでしたでしょうか？
- AOF はRedisの「操作の全記録ノート」。
- 突然のサーバー停止で、そのノートの末尾が途切れることがある。
- `aof-load-truncated` は、その途切れたノートを「読めるところまで読んで動く（`yes`）」か「エラーで止まる（`no`）」かを決める防衛ライン。
Redisのこうした設定の裏側には、「もしも障害が起きたらどう振る舞うべきか」という設計者の哲学がしっかりと詰まっています。
ここを理解できれば、もうRedisの永続化で怖いものはありません。「お、ちゃんとリスクヘッジできてるじゃん」と周りからも一目置かれるはずです。
明日からの設計や運用に、ぜひこの知見を活かしてみてくださいね。それではまた！
コメント