【入門編】 RDBスナップショット – Redis

こんにちは！ Redisの世界へようこそ。
私はこれまで数多くのシステムを設計・運用してきたけれど、その中でもRedisというインメモリデータベース（メモリ上で高速に動くデータベース）は、本当に魅力的で頼れる相棒なんだ。

今回は、Redisの心臓部の一つである「RDBスナップショット（永続化）」について、徹底的に、そして分かりやすく解説していくよ。

「メモリ上で動くってことは、サーバーの電源が落ちたらデータが全部消えちゃうんじゃないの？」
そんな不安を持ったそこのあなた。大正解！とても鋭い着眼点だ。
メモリは非常に高速な反面、電気を失うと中身が消えてしまう儚い性質を持っている。

だからこそ、Redisには消えては困るデータを安全に保存しておく仕組みが必要になる。それが今回学ぶRDBスナップショットなんだ。
ここをクリアすれば、Redisのデータ管理の基本はバッチリマスターできるから、安心してついてきてね！

—

1. 例え話で理解する「RDBスナップショット」

難しい専門用語はいったん脇に置いて、日常のシーンで考えてみよう。

君が今、ものすごく凝った「超大作の絵画」をホワイトボードに描いているとするよ。
ホワイトボードは、いわばRedisの「メモリ（RAM）」だ。描き心地は最高にスムーズだけど、誰かがうっかり消しゴムで消したり、夜間に清掃の人がボードを全部拭いちゃったら一巻の終わりだよね。

そこで、どうする？
作業の区切りが良いところで、「スマホでホワイトボードの写真をパシャリと撮影して、クラウドに保存しておく」よね。

この「ある瞬間の状態をまるごと切り取って、カセットテープやファイルに保存する行為」こそが、RDBスナップショットの正体なんだ。

メモリ（RAM） ＝描き途中のホワイトボード（高速だけど消えやすい）
RDBファイル ＝スマホで撮影した写真（ディスクに保存され、電源を切っても消えない）

もしサーバーがクラッシュしても、次に起動したときにこの「写真（RDBファイル）」を読み込めば、パシャリと撮影した瞬間の状態まで一瞬で巻き戻すことができるというわけ。

—

2. RDBスナップショットの仕組みと「3つの条件」

Redisは、設定ファイル（`redis.conf`）にあらかじめ「こういう条件になったら写真を撮ってね」というルール（トリガー）を書き込んでおくことができる。

デフォルトでは、こんなルールになっているんだ：

「900秒（15分）以内に、データが1回以上変わったら写真を撮る」
「300秒（5分）以内に、データが10回以上変わったら写真を撮る」
「60秒（1分）以内に、データが10000回以上変わったら写真を撮る」

どれか一つでも条件を満たすと、Redisは裏側で自動的にスナップショットを作成する。
「頻繁に書き換えがあるときは短い間隔で、あまり動かないときはのんびり撮る」という、非常に理にかなった賢い仕組みになっているんだよ。

—

3. 手動でスナップショットを撮ってみよう（実践）

百聞は一見に如かず。実際にRedisを操作して、手動でスナップショットを撮ってみよう。
Redisには、手動で写真を撮るためのコマンドが2つ用意されている。

① `SAVE` コマンド（同期処理）

今すぐ絶対に写真を撮ってくれ！とお願いするコマンド。

Redisのコマンドライン（redis-cli）を開いていると仮定して
127.0.0.1:6379> SAVE
OK

【先輩のワンポイントアドバイス】
この `SAVE` コマンド、実は本番環境では禁じ手とされることが多いんだ。なぜなら、写真を撮り終えるまでの間、Redisが他の仕事（ユーザーからのリクエスト処理）を一切受け付けなくなってしまうから。
ホワイトボードの写真を撮る間、「みんな、一歩も動かないで！息もしないで！」と教室全体をフリーズさせるようなものだね。データ量が多いと、アプリ全体が一時的に固まってしまう。

② `BGSAVE` コマンド（非同期処理・バックグラウンド）

そこで登場するのが、実務の主役である `BGSAVE`（Background Save）だ。

127.0.0.1:6379> BGSAVE
Background saving started

これを使うと、Redisは自分自身の「分身（コピー）」を裏側の世界でこっそり作り出し、その分身に「今のメモリの状態を写真に収めておいてよ」とお願いするんだ。
本体（親）はそのまま休むことなく、ユーザーからのリクエストをサクサク処理し続ける。非常にスマートで安全なやり方だよね。

—

4. RDBのメリット・デメリットを知る

どんな技術にも、光と影（トレードオフ）がある。RDBスナップショットの本質を理解するために、メリットとデメリットを整理しておこう。

メリット

1. ファイルがコンパクトで高速
データがギュッと圧縮されたバイナリ形式で保存されるため、ファイルサイズが小さく、Redisを再起動したときの読み込み（復旧）がもの凄く早い。
2. バックアップや災害復旧に最適
「この瞬間のデータ」が1つのファイル（通常は `dump.rdb` という名前）にまとまるので、このファイルを別のサーバーにコピーするだけで、簡単にバックアップや移行ができる。

デフォルトのデメリット（ここが重要！）

「データの空白地帯」が生まれる

例えば「5分に1回」スナップショットを撮る設定にしていた場合、最後の撮影から4分59秒後にサーバーがブッ飛んだら……？
そう、最後の5分間に書き込んだデータは、写真に残っていないため消えてしまう。

「1秒たりともデータムダにしたくない！」というミッションクリティカルなシステムの場合、RDBだけでは少し心もとない。だからこそ、Redisには「AOF（Append Only File）」という別の永続化方式も用意されていて、これらを組み合わせて使うのがプロの現場の定石なんだ。

—

最後に

お疲れ様！
「RDBスナップショット」の正体が、ただの「メモリの定期的な写真撮影」だと分かれば、もう怖いものはないはずだ。

メモリは消えやすいから、定期的にディスクに写真（RDB）を撮る。
本番環境では、お店を止植えさせないために `BGSAVE` を使う。
ただし、写真と写真の間の隙間に起きたデータ変更は消えるリスクがあることを知っておく。

この本質さえ押さえておけば、インフラエンジニアやバックエンドエンジニアと話すときも、自信を持ってアーキテクチャの設計ができるはずだよ。

Redisの基本は、こうした「直感的な仕組みの積み重ね」でできている。
一歩ずつ、確実に自分のものにしていこう。次のステップも私と一緒に楽しく学んでいこうね！