Redisメモリの深淵：なぜあなたのRedisは「太る」のか？——極限のメモリ最適化術
Redisを「単なるキャッシュ」としてしか見ていないエンジニアは、運用フェーズで必ず痛い目を見る。Redisの本質は「メモリという有限資源を、いかに極限まで効率的に使い倒すか」という戦いそのものだ。
今日は、表面的なコマンドの使い方ではなく、Redisのアーキテクチャがメモリとどう対峙しているのか、そして実務レベルでメモリをどう御すべきかについて、本質的な話をしよう。
—
1. 勘でメモリを見積もるな：MEMORY USAGEの真実
多くのエンジニアが `MEMORY USAGE` を叩いて満足するが、このコマンドには落とし穴がある。
特定のキーのメモリ使用量を確認
MEMORY USAGE my_huge_hash
返り値: 4208 (バイト数)
注意すべきは、この値は「値そのもののメモリ」と「Redisのオーバーヘッド」の合計である点だ。しかし、このコマンドをループで全キーに叩くのは自殺行為だ。Redisはシングルスレッドで動作するため、重い計算を強制すると全リクエストがブロックされる。
【教訓】
本番環境での診断は、必ず `SCAN` コマンドを組み合わせて、低負荷にサンプリングして調査すること。一気に全体をスキャンしてはいけない。
—
2. MEMORY DOCTORは「医師」ではなく「警告灯」
`MEMORY DOCTOR` を叩いたことはあるか？
MEMORY DOCTOR
“Memory usage is high, check for fragmentation…” のような警告が出る
これが出た時、システムは既に「危険信号」を点滅させている。特に注意すべきは 「断片化（Fragmentation）」 だ。
Redisは `jemalloc` をメモリアロケータとして採用している。これは非常に優秀だが、値の更新（特に大きな値の更新・削除）を繰り返すと、OSから確保したメモリ領域の中に「飛び地」ができる。
- 指標: `info memory` の `mem_fragmentation_ratio` を見ろ。
- 理想: 1.0 〜 1.5。
- 警告: 1.5を超えたら要注意。2.0を超えたら、それは「設計ミス」か「運用上の放置」だ。
【解消法】
物理的な再起動を待てない場合、Redis 4.0以降なら `CONFIG SET activedefrag yes` を検討しろ。ただし、これはCPUを食う。裏でデフラグが走ることでレイテンシにスパイクが生じる可能性がある。本番環境で有効化するなら、必ず検証環境で負荷試験を行え。
—
3. maxmemory-policyの選択が「運命」を決める
Redisのメモリが限界に達したとき、どう振る舞うべきか。これを決めるのが `maxmemory-policy` だ。
- allkeys-lru: 迷ったらこれ。最も使われていないキーを捨てる。現代のWebキャッシュ設計の「正解」に近い。
- volatile-lru: 有効期限付きのキーだけを捨てる。TTL設計を完璧に管理できているならアリだが、管理が甘いとメモリが溢れる。
- noeviction: デフォルトだが、メモリが一杯になると書き込みを一切拒否する。「メモリが溢れるくらいなら死ぬ」という高可用性が必要なシステム以外では使うな。
【設計の勘所】
「なぜキャッシュが消えるのか？」と嘆く前に、キャッシュのTTL設計と `maxmemory` のサイズが、システム全体のアクセスパターンと合致しているかを見直せ。LRU/LFUを当てにするのは、設計の敗北だ。
—
4. メモリを食い潰す「悪魔のデータ構造」
メモリ最適化の極意は、実はコマンドではなく「データ構造の選択」にある。
1. HASHの活用: キーをバラバラに作るな。関連するデータは一つのHASHにまとめろ。Redisは「ZipList（現在はQuickListの派生）」という省メモリな表現形式を持っており、フィールド数が少ないHASHは驚くほどメモリ効率が良い。
2. 型を疑え: 文字列で数値を保持するな。Redisの整数値は非常に効率よく保存される。
3. キー名の最適化: `user:10001:profile:name` のような長いキー名は、数百万件規模で積もると数GBの無駄になる。プロダクションでは `u:10001:p:n` のような短縮を検討する勇気も必要だ。
—
最後に：チーフアーキテクトからの助言
Redisのメモリ管理は、「どれだけ潔く捨てるか」と「どれだけ密に詰め込むか」のバランスゲームだ。
- 運用中に `info memory` を監視するダッシュボードを必ず用意すること。
- `used_memory_rss`（OS側から見た使用量）と `used_memory`（Redis側が認識している使用量）の乖離を常に監視せよ。この差分こそが「断片化の正体」だ。
Redisは魔法の箱ではない。メモリというリソースを、エンジニアであるあなたがどう制御するか。その設計思想が、システムのレスポンス速度と安定性に直結する。
コードを書く前に、データ構造を見直せ。それが、最高峰のエンジニアへの第一歩だ。
コメント