【入門編】障害復旧プロセス – Redis

こんにちは！システム開発の現場で、日々インフラやデータベースと格闘している先輩エンジニアです。

今回は、インメモリデータベースの代名詞である「Redis（レディス）」の心臓部、「障害復旧プロセス」についてお話しします。

「Redisが突然クラッシュした！データはどうなるの？」
「RDBとかAOFとかよく聞くけど、いざという時どっちが優先されるの？」

そんな疑問を持ったことはありませんか？
ここをクリアすれば、Redisのデータ永続化とリカバリの仕組みはバッチリマスターできますよ。専門用語をできるだけ使わず、身近な例えを交えながら、本質を優しく紐解いていきましょう。

—

1. そもそもRedisのデータはどこにある？（日常の例え）

Redisは、すべてのデータを「メインメモリ（RAM）」上に置いて処理する超高速なデータベースです。メモリ上で動いているので、データの読み書きが電光石火の速さなんですね。

しかし、ここに大きな弱点があります。
メモリというのは、いわば「ホワイトボード」のようなものです。電源を切ったり、サーバーがクラッシュして再起動したりすると、ホワイトボードに書かれていた文字（データ）はすべて綺麗さっぱり消えてしまいます。

「じゃあ、サーバーが落ちたらデータはゼロ？」
それを防ぐために、Redisには「ノートに書き留めて残しておく仕組み」が用意されています。それがRDBとAOFという2つの永続化機能です。

—

2. 2つのセーフティネット：RDBとAOFの正体

Redisがデータを残す方法には、大きく分けて2つのアプローチがあります。

① RDB（Redis Database）：「定期スナップショット方式」

例え： 1時間に1回、ホワイトボードの写真をスマホでパシャリと全体撮影してアルバムに保存するイメージ。
特徴： ファイルサイズが小さく、復旧（読み込み）が爆速です。ただし、最後の写真撮影からクラッシュするまでの間に起きた変更（最後の1時間の出来事）は記録されていません。つまり、「少しだけデータが巻き戻るリスク」があります。

② AOF（Append Only File）：「全行程ギロッピー（全録画）方式」

例え： ボードに書く・消すという作業のすべてを、「1番目に『A』と書いた、2番目に『B』を消した…」と、ボイスレコーダーで最初から最後まで実況録音し続けるイメージ。
特徴： データを100%完璧に復元できます（データ損失がほぼゼロ）。ただし、操作のログがどんどん溜まるため、ファイルサイズが巨大になりやすく、復旧に時間がかかります。

—

3. クラッシュ！再起動時、Redisは何をどう読み込むのか？（優先順位の謎）

もしあなたの運用するRedisサーバーが突然クラッシュしてしまったら、Redisは再起動のタイミングで大急ぎでデータをメモリ（ホワイトボード）に戻します。

ここで、「RDBとAOFの両方のファイルがある場合、Redisはどちらを優先して読み込むのか？」という疑問が湧きますよね。

答えはシンプルです。「AOFファイルが最優先される」のです。

Redisの復旧お仕事フロー

Redisが再起動したとき、頭の中で次のような判断をしてメモリを再構築しています。

1. 「AOFファイルはあるか？」を確認する。

ある場合： データが一番正確（最新）なので、AOFの記録を最初から順に再生してメモリを完全に再現します（※RDBは無視されます）。
ない場合： 次のステップへ進みます。

2. 「RDBファイルはあるか？」を確認する。

ある場合： 最後に写真を撮った時点の状態をメモリに復元します。
ない場合： 保存されたデータがないため、空っぽのホワイトボードからスタートします。

つまり、Redisの基本方針は「より正確で新しい情報を優先する（AOF > RDB）」ということです。

—

4. 実務で役立つ！復旧時のログを見てみよう

実際にRedisが再起動してデータを読み込む際、ログ（`redis-server`の出力やログファイル）には以下のようなメッセージが出力されます。ここを読むと、Redisがどのようにデータを復旧したかが一目瞭然です。

AOFファイルが存在する場合のログ例
1:M 01 Jan 2023 10:00:00.123 DB loaded from append only file: 0.45 seconds

> 【エンジニアの解説】
> 「`loaded from append only file`」と出力されていますね。これは「AOFファイルを使ってデータをメモリに読み込みましたよ」というサインです。AOFが優先され、無事に最新の状態で復旧が完了しています。

もしAOFを有効にしておらず、RDBだけを使っている場合はこうなります。

RDBファイルのみが存在する場合のログ例
1:M 01 Jan 2023 10:05:00.456 DB loaded from disk: 0.12 seconds

> 【エンジニアの解説】
> こちらは「`loaded from disk`（ディスク＝RDBファイルからロード）」となっています。スナップショットからの復旧なので、読み込み速度は非常に高速ですが、スナップショット作成以降のデータは失われている可能性があります。

—

5. 先輩からのアドバイス：堅牢なシステムを作るために

ここまで、Redisの障害復旧プロセスについて解説してきました。
「じゃあ、AOFだけを有効にしておけば完璧だね！」と思いがちですが、実務の現場では少し違います。

AOFは安全だが、復旧に時間がかかる。
RDBはスピーディーだが、わずかにデータが消える可能性がある。

そのため、大規模なプロダクション環境（商用環境）では、「基本はRDBで定期的にスナップショットを撮りつつ、極限までデータを守りたい重要システムではAOFを併用する」というハイブリッドな設定にすることが多いです。

Redisは「インメモリだから速い、けれど消えやすい」という特性を正しく理解し、万が一のクラッシュ時にどうやってデータが戻ってくるのか（優先順位と手順）を知っておくだけで、障害時のパニックを劇的に減らすことができます。

インフラの仕組みを味方につけて、自信を持ってコードを書き、システムを支えていきましょう。
あなたのエンジニアライフを、心から応援しています！