【テクニカル・上級編】メモリ最適化と診断 – Redis

Redisのメモリ極限制御：アーキテクチャの深淵と「断片化」との戦い

Redisは単なるKVSではない。それは、メモリという有限の資源を極限まで使い切り、レイテンシという名の物理法則に抗うための「精密機械」だ。

大規模システムでRedisを運用するということは、単に`maxmemory`を設定することではない。Redisのメモリ管理の「心臓部」を理解し、jemallocが裏で何をしているのか、データ構造のオーバーヘッドがなぜ膨らむのかを、そのコードの行間から読み解くことである。

今日は、表面的なドキュメントには載っていない、現場で「死線」を越えてきた者だけが知るメモリ最適化の真髄を語ろう。

—

1. `MEMORY USAGE`：その数字は真実を語っているか

多くのエンジニアは`MEMORY USAGE key`を気軽に使用するが、注意が必要だ。このコマンドは、指定されたキーが占有するメモリを、Redis内部のデータ構造（`robj`）に基づき再帰的に算出する。

注意点：

計算コストの罠: 大規模なHashやSorted Setに対してこのコマンドを叩くと、O(N)の計算が発生し、メインスレッドがブロックされる。本番環境での安易な実行はレイテンシスパイクの元だ。
物理メモリとの乖離: `MEMORY USAGE`が返す値は「論理的なサイズ」であって「OSが確保している物理的なRSS」ではない。Redisが管理するデータ構造のサイズであり、アロケータ（jemalloc）が確保した実際のメモリ量とは、断片化分だけ必ずズレが生じる。

2. 物理メモリの深淵：断片化（Fragmentation）の正体

Redisが`used_memory`と`used_memory_rss`を分けてレポートする理由を理解しているか？

used_memory: Redisが論理的に認識しているメモリ使用量。
used_memory_rss: OSがRedisプロセスに割り当てている実際の物理メモリ量。

この差分、つまり `mem_fragmentation_ratio = used_memory_rss / used_memory` が1.5を超えるようなら、それは警鐘だ。jemallocがメモリを断片化し、OSに返却できていない状態を意味する。

断片化を解消する「外科手術」

設定ファイルで `activedefrag yes` を有効にすれば、Redisはバックグラウンドで断片化を解消（Defragmentation）する。しかし、これはCPUリソースを消費する。

実行中に動的に有効化する場合
CONFIG SET activedefrag yes

デフォルト設定からさらにアグレッシブに攻める場合
負荷が高い時は自動調整されるが、強制的に閾値を下げる
CONFIG SET activedefrag “100 10 500 50 10 0”
解説: [開始閾値% 終了閾値% 開始CPU負荷% 終了CPU負荷% 最小移動量最大移動量]

このチューニングは、システムのI/O負荷とメモリ効率のトレードオフだ。安易に弄るな。メトリクスを数日間観測し、jemallocの動作を理解してから触れ。

3. `MEMORY DOCTOR`：アーキテクトの診断書

`MEMORY DOCTOR`コマンドは、Redisが自身の健康状態を自己診断するためのものだ。

MEMORY DOCTOR
出力例: “Memory fragmentation is high…”

このコマンドが警告を吐いたとき、それは既に「手遅れに近い」状態が多い。ここで重要なのは、警告の内容を鵜呑みにせず、なぜその状態になったのかを推測することだ。例えば、「Hashの要素数が少ないのにメモリを食っている」なら、それは`ziplist`から`hashtable`へエンコーディングが切り替わった境界値の設計ミスだ。

4. `maxmemory-policy`：どのデータを見捨てるか

`maxmemory`に達したとき、Redisはどのデータを切り捨てるか。ここでアーキテクトの腕が試される。

`allkeys-lru`: 最も汎用的。だが、アクセスパターンが「冪乗則」に従わない場合、キャッシュ効率が劇的に低下する。
`volatile-lru`: TTLが設定されたキーのみを対象とする。これは「捨てるべきでない永続的なデータ」と「捨てるべきキャッシュ」が混在する複雑なシステムで必須の選択だ。
`allkeys-lfu`: LRUよりも強力な場合がある。頻度をベースにするため、一度きりのアクセスでキャッシュが流れる現象を防ぐ。

極限の知見：
メモリを限界まで詰め込みたいなら、`maxmemory`を物理メモリの80%以下に抑えるのが鉄則だ。Redisのオーバーヘッドに加え、OSのページテーブルやネットワークバッファは`maxmemory`の制限外でメモリを食う。これを忘れると、OOM Killerにプロセスを殺され、再起動時のRDB読み込みでメモリ不足に陥るという悲劇が待っている。

結びに代えて

Redisのメモリ管理は、OS、アロケータ、そしてRedisのデータ構造が織りなす高度な協奏曲だ。

コマンドを叩いて数字を眺めるだけでは、真のチューニングはできない。jemallocのチャンクサイズ、`robj`構造体のポインタの無駄、そしてアプリケーションが生成するキーの命名規則に至るまで、全てがメモリ効率に直結している。

メモリ最適化とは、単なる節約ではない。システムが限界に達したとき、いかにして「優雅に」振る舞わせるか。そのための設計判断こそが、エンジニアの美学である。

さあ、次は君のRedisの`info memory`を見てみろ。そこにどんな物語が隠れているか、私には見えるはずだ。