Redisメモリ最適化の急所：`MEMORY USAGE`を制する者がスケーラビリティを制す
テックリードの私だ。コードレビューやアーキテクチャ設計を見渡していて、最も頻繁に遭遇するアンチパターンの一つが「なんとなくRedisにデータを放り込み、メモリが圧迫されてから慌てて調査する」という泥縄式のアプローチだ。
Redisは「インメモリの高速なデータストア」であるからこそ、メモリの消費量をバイト単位で正確に把握し、設計段階でフットプリントを予測・コントロールできなければプロフェッショナルとは言えない。
今回は、Redisのメモリ管理における隠れた主役、`MEMORY USAGE`コマンドを取り上げる。単なるコマンドのリファレンスではない。実務の現場でこのコマンドをどう武器にし、いかに堅牢なメモリ設計に昇華させるか、その極限の知見を伝授しよう。
—
1. なぜ `MEMORY USAGE` なのか？（INFOコマンドの限界）
メモリ使用量を調べる際、多くの初心者は `INFO memory` を叩きたがる。しかし、`INFO memory` が返す `used_memory` は、Redisプロセス全体が消費しているグローバルな数値に過ぎない。
「どの特定のキーがメモリを食い潰しているのか？」
「数千万件あるユーザーセッションのうち、どれが肥大化しているのか？」
こうしたドリルダウンが必要な現場において、`INFO` は無力だ。そこで登場するのが `MEMORY USAGE` である。
基本構文とサンプル
MEMORY USAGE key [SAMPLES count]
最もシンプルな使い方は以下の通りだ。
適当な文字列キーをセット
127.0.0.1:6379> SET user:1001:profile “{\”name\”: \”Alice\”, \”age\”: 30, \”role\”: \”admin\”}”
OK
このキー単体が消費しているメモリバイト数を測定
127.0.0.1:6379> MEMORY USAGE user:1001:profile
(integer) 105
返された `105` という数値。これが、このキー（キー名と値、およびRedis内部のメタデータを含む）が消費している正確なバイト数だ。この解像度を手に入れたことで、私たちの設計アプローチは劇的に変わる。
—
2. 実務で知るべき「内部アルゴリズム」とSAMPLESオプション
ここで、Redisの内部構造に踏い込んだ深い知見を共有しよう。
`MEMORY USAGE` は、キーが指すオブジェクトの構造を再帰的に走査し、メモリ消費量を計算する。しかし、Hash、Set、Sorted Set、Listといったコンテナ型データ構造や、内部でEncodingが複雑化しているオブジェクトにおいて、すべての要素を完全に走査するとO(N)の計算量となり、シングルスレッドで動くRedisのメインループをブロック（レイテンポラリな停止）させるリスクが生じる。
そこで用意されているのが `SAMPLES` オプションだ。
MEMORY USAGE large:hash:key SAMPLES 5
サンプリングのメカニズム
コンテナ型データ構造（HashやZSetなど）のメモリ計測において、すべての要素を舐めるのではなく、指定されたサンプル数（デフォルトは5）だけランダムに抽出し、その平均サイズから全体を推測する。
- SAMPLESの指定値と挙動:
- `SAMPLES 0`: すべての要素を完全にスキャンする（正確だが、巨大なキーではCPUを焼き、レイテンシが跳ね上がる）。
- `SAMPLES N` (N > 0): 指定したサンプル数に基づく近似値を返す（O(1)に近い極めて安全なコストで計算可能）。
【テクニカルリードからの教訓】
本番環境（Production）において、要素数が数万件を超えるような巨大なキーに対して `SAMPLES` なしで `MEMORY USAGE` を実行してはならない。それは「自爆行為」に等しい。本番でのモニタリングには必ず `SAMPLES 5`（あるいはそれ以下）を付与し、精度とパフォーマンスのトレードオフをコントロールしろ。
—
3. 実践：メモリ爆発を防ぐ設計パターン
では、この `MEMORY USAGE` を実際のシステム設計や運用にどう組み込むべきか。私が推奨する2つのパターンを伝授する。
パターンA: 開発・ステージング環境での「データ構造プロファイリング」
新しい機能を実装し、Redisにデータを格納する設計をした際、必ずCI/CDパイプラインやステージング環境で以下の検証を行うべきだ。
Python (redis-py) を用いたデータ構造のメモリ効率検証スクリプトのイメージ
import redis
r = redis.Redis(host=’localhost’, port=6379)
10万件のユーザーデータを String (JSON) で入れた場合
r.set(“user:json:1”, ‘{“id”: 1, “name”: “Bob”, “tags”: [“rust”, “redis”, “architecture”]}’.encode(‘utf-8’))
mem_string = r.execute_command(“MEMORY USAGE”, “user:json:1”)
同じデータを Hash で入れた場合
r.hset(“user:hash:1”, mapping={“id”: 1, “name”: “Bob”, “tags”: “rust,redis,architecture”})
mem_hash = r.execute_command(“MEMORY USAGE”, “user:hash:1″)
print(f”String (JSON) usage: {mem_string} bytes”)
print(f”Hash usage: {mem_hash} bytes”)
Redisは、データ構造（Encoding）によってメモリフットプリトが劇的に変わる。小規模なフィールドを持つオブジェクトをJSON文字列として格納するより、Hash構造（かつフィールド数が少なく `ziplist` や `listpack` に最適化される範囲）で持たせた方が、オーバーヘッドを含めてメモリ効率が良いケースが多々ある。
`MEMORY USAGE` を使って「どのデータ構造が最もメモリを効率的に使えるか」を実測値で証明してからコードを書くこと。これが一流のエンジニアの仕事だ。
パターンB: 本番環境での非同期監査バッチ（Memory Auditor）
本番環境で「誰がメモリを無駄遣いしているか」を特定するため、低負荷な監査バッチを回す設計手法だ。
1. `SCAN` コマンドでキーを少しずつスキャンする（`KEYS` コマンドは絶対に使うな。O(N)でRedisが死亡する）。
2. 取得したキーに対して `MEMORY USAGE key SAMPLES 3` を実行する。
3. 閾値（例: 10KB以上）を超えている「肥大化キー」を検出し、Slackやログにアラートを飛ばす。
この仕組みをバックグラウンドワーカーとして実装しておくだけで、メモリリークや意図しないデータ肥大化の兆候を、障害が発生する数日前に検知できる。
—
4. パフォーマンス上の注意点（暗黙のコスト）
最後に、アーキテクトとして知っておくべきハードな事実を伝えておく。
- メモリは「正確」ではない（Allocatorのオーバーヘッド）
`MEMORY USAGE` が返す値は、Redisのオブジェクトが論理的に消費しているサイズ＋アロケータの管理サイズの大まかな見積もりだ。OSレベルやjemallocが実際に確保している物理メモリ（RSS）とは厳密には一致しない。全体感の把握には `INFO memory` を使い、個別の特定には `MEMORY USAGE` を使うという使い分けを忘れるな。
- メモリ計測もCPUを消費する
前述の通り、巨大なコンテナ型キーに対する過剰な `MEMORY USAGE` の乱用は、シングルスレッドのRedisを詰まらせ、全体のレイテンシを悪化させる。本番環境での実行頻度は最小限に抑えよ。
—
結びにかえて
メモリ管理は、Redis運用における「最後の砦」だ。
「動けばいい」という甘い設計は、データ量がスケールした瞬間にシステムを崩壊させる。
`MEMORY USAGE` は、単なるデバッグ用コマンドではない。あなたのコードのメモリ効率を暴き出し、より高効率なアーキテクチャへと導くためのメスである。
今日のコードレビューから、感覚的なメモリ見積もりを捨て、実測値に基づいたロジカルな設計を徹底してほしい。君たちの健闘を祈る。
コメント