【入門編】メモリ使用量メトリクス – Redis

こんにちは！Redisの奥深い世界へようこそ。
今日は、Redisを運用する上で避けて通れない、しかし誰もが一度は頭を悩ませる「メモリ管理」についてお話ししますね。

「Redisってインメモリデータベースだからメモリが命って言うけど、実際どうやって管理されているの？」
「`INFO memory` コマンドを叩いたはいいけれど、似たような数字が並んでいて、どれを見ればいいか分からない……」

そんなモヤモヤを抱えていませんか？大丈夫、安心してください。
今回は、チーフアーキテクトの私が、専門用語のジャングルを切り分けて、日常の「あるある」に例えながらスッキリと解説します。ここをクリアすれば、あなたのRedisのメモリ理解はもうバッチリマスターできますよ！

—

1. 例え話：Redisと「本棚」の物語

まず、Redisがメモリとどう付き合っているのかをイメージしやすくするために、「オフィスにある巨大な本棚（資料室）」を想像してみてください。

Redis（データ）： 資料室に置いてある書類たち。
物理メモリ（OSが管理する実体）： 会社が用意してくれた実際の床面積（スペース）。

あなたは仕事をするために書類を本棚に詰め込んでいきます。「本当に必要な書類の束」が大きくなればなるほど、本棚（物理メモリ）のスペースも占有されていきますよね。

Redisもこれと全く同じです。データを保存すればするほど、メモリを消費します。では、その消費量を測るための「3つの重要メトリクス」を見ていきましょう。

—

2. `INFO memory` が教えてくれる3つの数字

Redisのコンソール（`redis-cli`）を開いて `INFO memory` という魔法の呪文を唱えると、たくさんのデータが表示されます。その中でも特に重要な、以下の3つの主役たちを仲良くさせてあげましょう。

1. `used_memory` （純粋な書類の重さ）
2. `used_memory_rss` （本棚ごと占有しているスペース）
3. `used_memory_peak` （過去最大に散らかしたときの記録）

一つずつ、優しく解きほぐしていきますね。

—

① `used_memory`：Redis自身が計算した「純粋なデータサイズ」

まずはこれです。

定義： Redisが保持しているデータ（文字列、ハッシュ、リストなど）そのものが消費している純粋なメモリの量。
例え： 書類に書かれている文字自体の重さや、ファイル自体のサイズです。バインダーや棚の枠組みを除いた、「純粋な中身の重さ」だと思ってください。

この値が右肩上がりに増えているときは、「あ、今ユーザーがたくさんログインしてデータを保存しているんだな」と直感的に分かります。

—

② `used_memory_rss`：OSから見た「実際に奪っているリアルな空間」

次に、現場で一番トラブルになりやすいのがこの RSS（Resident Set Size：常駐セットサイズ） です。

定義： OS（オペレーティングシステム）の視点から見て、Redisというプロセスが「物理的にOSから奪い取っているメモリの総量」。
例え： 書類の束（`used_memory`）はそんなに重くないのに、「とりあえず大きめのダンボール箱にガサッと入れて、さらに専用の棚ごと占有している状態」です。

なぜ、中身（`used_memory`）と外見（`used_memory_rss`）にズレが出るの？

ここが初心者泣かせのポイントです。
Redisは、データを削除したり上書きしたりすると、メモリを「空き地」にします。しかし、その空き地をすぐにOSに「返却する」とは限らないのです。

OSの仕組み上、メモリの貸し借りは「まとまった単位（ページ単位）」で行われます。そのため、Redis内部では「もうこのデータは捨てたよ！」と片付けていても、OSから見ると「いやいや、まだあなた（Redis）に貸し出したスペースだから、他のアプリには渡さないよ」と、キープされたままになっている状態（メモリの断片化）がよく起きます。

> 先輩からのアドバイス：
> `used_memory_rss` が `used_memory` よりも極端に大きい場合、それはメモリの散らかり（断片化）が起きているサインです。「お部屋の掃除（メモリのデフラグ）」が必要な時期に来ている証拠ですよ。

—

③ `used_memory_peak`：過去最高にメモリを使った「歴史の爪痕」

最後は、過去のピークを知るためのメトリクスです。

定義： Redisが起動してから、「これまでに記録した最大のメモリ消費量（基本的には `used_memory` のピーク）」。
例え： 大規模なセールやイベントの日に、一時的に資料がオフィスにあふれかえり、「一番部屋が散らかったときの伝説」です。

この値がなぜ重要かというと、「このRedisサーバーには、過去にこれだけのメモリが必要だった」という最大負荷の履歴書になるからです。サーバーのスペック（メモリ容量）を設計・見直しするときに、この値をベースにすると失敗がありません。

—

3. 実践：実際に見てみよう

それでは、実際に `redis-cli` から覗いてみましょう。

$ redis-cli
127.0.0.1:6379> INFO memory
Memory
used_memory:1048576 # 純粋なデータは約1MB
used_memory_rss:3145728 # でもOSからは約3MB 占有されている（おやおや？）
used_memory_peak:5242880 # 過去の最大は約5MB だったみたい

この出力例を見てください。
「データは1MBしかないのに、OSからは3MBも取られているな。ということは、過去にたくさんデータを出し入れした名残で、ちょっとお部屋が散らかっている（断片化している）んだな」と、一瞬で状況が読めるようになります。
これが、Redisのエンジニアとしての「目」を持つということです。

—

まとめ

お疲れ様でした！最後に、今回学んだ3つのポイントをスッキリ整理しておきましょう。

`used_memory` ＝ Redisが把握している純粋なデータの中身の重さ。まずはここを見よう。
`used_memory_rss` ＝ OSが実際にRedisに割り当てているリアルな占有スペース。ここが大きすぎると断片化の疑いあり。
`used_memory_peak` ＝過去に一番メモリを消費したときの最高記録。サイジングの羅針盤。

メモリの仕組みが頭の中でクリアになると、Redisの挙動が手に取るように分かるようになり、運用時の不安がスーッと消えていきます。

「ここをクリアすれば、Redisの基本はバッチリマスターできますよ！」
自信を持って、明日からの開発や運用にこの知見を活かしてくださいね。それでは、次のステップでお会いしましょう！