こんにちは！Redisの運用で頭を悩ませていませんか？
「なんだか最近、サーバーのメモリがパンパンになってきたぞ……？ でも、どのデータがメモリを食いつぶしているんだ？」
実務の現場では、こういう緊急事態に直面することがよくあります。本番稼働中のRedisに直接「おい、誰がメモリを食ってるんだ！」と問い詰める（`KEYS`コマンドなどを乱発する）のは、サーバーをダウンさせる危険な行為なので絶対にNGです。
そこで登場するのが、RDBファイル（Redisのバックアップデータ）をオフラインでこっそり解析するというプロの技。
今回は、Redisのメモリ管理の仕組みから、巨大なキーを特定してスッキリ解決する手順まで、優しく丁寧にお伝えしていきますね。ここをクリアすれば、あなたもRedisのメモリ管理で迷うことはなくなりますよ！
—
1. 例え話でスッキリ理解：RedisのメモリとRDB
まず、Redisがどうやってデータを管理しているか、イメージしてみましょう。
Redisは、いわば「超高速なホワイトボード」です。
すべてのデータをメモリ（RAM）という名のホワイトボード上に書き込んでいるからこそ、一瞬で読み書きができます。しかし、このホワイトボードには物理的な限界があります。
ある日、誰かがホワイトボードいっぱいに巨大なイラストや不要なメモを書き殴り、スペースがなくなってしまいました。
「消さなきゃいけないけれど、どれが重要なデータで、どれが不要な落書き（ゴミ）なのか、パッと見ではわからない……」
そんなとき、あなたならどうしますか？
ホワイトボードの写真をスマホでパシャリと一度撮影して（これがRDBスナップショットの作成です）、その写真を自分のデスク（別サーバー）に持ち帰って、じっくりルーペで拡大して「おや、この巨大なメモを書いたのは誰だ？」と犯人捜しをしますよね。
これが、オフライン解析の基本思想です。本番のホワイトボード（Redisサーバー）を一切邪魔せず、安全に原因を特定できる最高のアプローチなのです。
—
2. なぜ「オフライン解析」が必要なのか？
初心者のうちは、メモリが増えると、いの一番にRedisへ「今どんなデータがあるの？」とコマンドを送りたくなります。
しかし、Redisはシングルスレッド（1つの作業員が休まず一人で処理をこなす仕組み）で動いています。
もし本番環境で「すべてのキーを教えてくれ！」（`KEYS ` など）と頼んでしまうと、その作業員はその仕事にかかりっきりになり、他のユーザーからの大事なリクエストを何秒も、下手すると何分も待たせてしまいます。結果、サービス全体がフリーズする「大惨事」になりかねません。
だからこそ、「スナップショット（RDB）を安全な場所に取り出して、別室でこっそり検品する」というアプローチが、プロの現場では常識とされているんです。
—
3. 実践！RDBファイルからメモリ泥棒を特定する手順
それでは、実際にRDBファイルを解析して、メモリを圧迫している犯人（巨大なキー）を特定する手順を一緒に見ていきましょう。
今回は、Python製の世界中で大人気な解析ツール「rdbtools」を使います。これがあると本当に人生が変わるくらい便利ですよ。
ステップ1：RDBファイルを確保する
まずは、Redisのデータが詰まったRDBファイル（通常は `dump.rdb` という名前です）を手に入れます。安全のために、このファイルを別の分析用サーバーや自分の手元のPCにコピーしておきましょう。
ステップ2：解析ツール（rdbtools）の準備
Pythonの環境があれば、コマンド一発でインストールできます。
rdbtools と、高速に処理するための python-lzf をインストールするよ
pip install rdbtools python-lzf
ステップ3：メモリ食い虫ランキングを作成する（CSV出力）
ツールを使って、RDBファイルの中身をスキャンし、「どのキーが、何バイトのメモリを使っているか」を一覧（CSV形式）に書き出します。
dump.rdbを解析して、メモリ使用量順に並べ替えたCSVファイルを作るコマンド
rdb -c memory dump.rdb > memory_report.csv
【解説】
- `-c memory` は、「メモリ使用量を詳しく解析してね」という指定です。
- 生成された `memory_report.csv` を、Excelやスプレッドシートで開いてみてください。どのキーがどれだけのメモリを占有しているかが一目瞭然になります！
ステップ4：特定のデータ型に絞って調査する
「いや、うちはハッシュ型（Hash）やリスト型（List）に変なデータが溜まっている気がするんだよな……」という場合は、次のようにコマンドを叩いて、特定のデータ型だけに絞って巨大なキーを見つけることも可能です。
例：大きすぎる「文字列（String）」のキートップ10をコマンドライン上でサクッと確認する
rdb -c memory –bytes 1024 –type string dump.rdb | sort -t, -k4 -nr | head -n 10
—
4. よくある「メモリ泥棒」のパターンと対策
解析結果を見て、「うわっ、なんだこのキーは！」となる代表的なパターンがいくつかあります。
1. 有効期限（TTL）が設定されていないゴミデータ
- 一時的なキャッシュのつもりだったのに、期限を付け忘れて永遠にメモリに居座っているパターン。
- 対策： `EXPIRE` コマンドでちゃんと寿命を持たせてあげましょう。
2. 一つのハッシュやリストに要素が詰め込まれすぎている（巨大コンテナ）
- 1つのキーの中に、数百万件のデータを突っ込んでいるようなケース。
- 対策： データを適度なサイズに分割（シャーディング）するか、不要になった古い要素を定期的に削除する仕組みを作りましょう。
—
まとめ
いかがでしたでしょうか？
RDBファイルを活用したメモリ解析は、一見難しそうに見えて、実は本番環境を守るための「最も安全で優しいアプローチ」です。
- 本番サーバーに負荷をかけないために、RDBを別環境に持ち出してオフラインで解析する。
- `rdbtools` などの便利なツールを使って、メモリを食っている犯人（キー）をランキング形式で暴き出す。
この基本 さえ押さえておけば、今後どれだけデータが増えても、冷静に原因を突き止めてスマートに対処できるようになります。
Redisのメモリ管理、怖くありませんよね？
ぜひ次のメンテナンスや設計の際に、この手法を試してみてください。あなたのエンジニアライフが、より快適で知的になりますように！
コメント