【実務・中級編】 MEMORY DOCTORコマンド – Redis

こんにちは。テクニカルリードの私だ。

君たちは本番環境のRedisが突然「OOM (Out of Memory)」でカーネルに殺され、夜中にページャーが鳴り響いた経験はないか？
あるいは、クラウドのマネージドRedis（AWS ElastiCacheやGoogle Cloud Memorystoreなど）で、データ量はそこまで増えていないのにメモリ使用率が急上昇し、理由もわからないままスケールアップのコストを承認させられたことは？

Redisは「メモリ上にすべてを置く」というシンプルゆえに強力な設計思想を持っているが故に、ひとたび設計を誤れば、メモリは瞬く間に枯渇する。
そして、そのメモリ肥大化の兆候を静かに、しかし正確に検知し、警鐘を鳴らしてくれる隠れた名医がいる。それこそが `MEMORY DOCTOR` コマンドだ。

今回は、この `MEMORY DOCTOR` の内部挙動と、実務の現場で私たちがどうこの診断結果を読み解き、アーキテクチャに落とし込むべきかについて、徹底的に解説しよう。

—

1. `MEMORY DOCTOR` とは何か？：生体情報の「総合診断」

まずは基本だ。`MEMORY DOCTOR` は、現在のRedisインスタンスのメモリ健康状態をスキャンし、人間が読める形式の診断レポート（Human-readable diagnostic message）を返す。

実際に本番同等の環境で叩いてみると、以下のような出力が得られる。

127.0.0.1:6379> MEMORY DOCTOR
“high memory usage is 99.45% of maxmemory. WARNING: maxmemory is too low. If you set maxmemory to persist data, consider scaling up. If you are using Redis for caching, ensure maxmemory-policy is properly eviction policy (e.g. volatile-lru, allkeys-lru) and keys have TTLs.”

おっと、これはレッドカード寸前の状態だ。
このコマンドは単なる `INFO memory` の数値の垂れ流しではない。Redisの内部状態（断片化率、メモリ使用量、maxmemoryの設定、スワップの有無など）を多角的に解析し、「何がクリティカルな問題であり、どう修正すべきか」のストーリーを生成してくれているのだ。

チーフアーキテクトとして、私は新人の頃「動けばいいや」と設定を適当に放置した結果、このDoctorからの警告を無視して痛い目を見たエンジニアを何人も見てきた。この出力の意味を、コードレビューの基準レベルで深く理解しよう。

—

2. 診断の裏側：Doctorは何を見ているのか？

`MEMORY DOCTOR` は、主に以下のメトリクスと構造上の矛盾を診断している。

1. `maxmemory` との実メモリの乖離・逼迫
設定された上限に対して、どれだけのメモリを食いつぶしているか。
2. メモリの断片化（Fragmentation）
OS側が割り当てたメモリ（RSS）と、Redisが実際にデータ保持に使っているメモリの比率（`mem_fragmentation_ratio`）。
3. VM（Virtual Memory）の兆候（古いバージョンや特殊な環境）
OSのページングによるレイテンシ悪化の予兆。

特に実務で最も頻繁に遭遇し、かつシステム障害に直結するのが 「メモリの断片化」 と 「maxmemory未設定／不適切設定」 だ。それぞれの診断メッセージが何を意味し、どう対処すべきか、私の実務知見を共有しよう。

—

3. 実務で遭遇する「3大警告」とアーキテクチャ的解決策

ケース A: 断片化の悪夢（Fragmentation Warning）

> 診断例: “High fragmentation ratio (1.85). The allocator is wasting memory.”

背景:

Redisはデータの頻繁な書き換え・削除に伴い、jemallocなどのメモリアロケータを通じてOSとメモリのやり取りを行う。この時、アロケータの挙動やデータのライフサイクルのせいで、メモリ上に「穴あきチーズ」のような状態（断片化）が発生する。論理的には50GBしか使っていなくても、OS側には100GB確保されている、という事態が起きるのだ。

アーキテクチャ的解決:

Redis 4.0以降であれば、Active Memory Defragmentation（アクティブデフラグ）を有効化するのが定石だ。
`redis.conf` または動的に以下を設定せよ。

activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 30

※ただし、アクティブデフラグはCPUを激しく消費する。ピークタイムを避け、負荷の低い時間帯に回るようにチューニングすること。

ケース B: 爆発するクライアントバッファ（Client Output Buffers）

> 診断例: “Clients are consuming a large amount of memory…”

背景:

Pub/Subの慢性的遅延や、巨大なレスポンスを返すスロークエリ（`KEYS ` や巨大な `HGETALL`）を叩くクライアントがいると、出力バッファが肥大化し、メモリを圧迫する。

アーキテクチャ的解決:

アプリケーション側の設計ミスだ。`KEYS` コマンドの本番利用は即座に禁止し、`SCAN` カーソルへ置き換えろ。また、Pub/Subのコンシューマが遅い場合は、ブローカーとしてのRedisの限界を見極め、KafkaやSQSなどのメッセージング基盤へアーキテクチャを移行すべきだ。

ケース C: 緩慢な死、maxmemoryの欠如

> 診断例: “maxmemory is not set and memory usage is high.”

背景:

これを放置するのは、ブレーキの壊れたスポーツカーで山道を攻めるようなものだ。データが無制限に増え続け、最終的にLinuxのOOM KillerにRedisプロセスが突然屠られる。フェイルオーバーも何もあったものではない。

アーキテクチャ的解決:

キャッシュ用途であれば、必ず `maxmemory` を物理メモリの70〜80%程度に設定し、適切なエビクションポリシー（削除ポリシー）を適用しろ。

maxmemory 12gb
maxmemory-policy allkeys-lru
# もしくは厳密なTTL管理がされているなら volatile-lru

—

4. 運用自動化：CI/CDパイプラインとモニタリングへの組み込み

優秀なエンジニアは、障害が起きてから `MEMORY DOCTOR` を叩かない。障害の芽を事前に摘むために、このコマンドを自動化システムに組み込む。

例えば、PrometheusのExporterや、定期実行するCronスクリプト（PythonやGoなど）からRedisに接続し、`MEMORY DOCTOR` の出力文字列をパース、あるいは `INFO memory` の指標と組み合わせて監視基盤（DatadogやGrafana）に流し込むのだ。

以下は、私がかつて大規模ECシステムの監視用に入れた、ヘルスチェックロジックの概念的なスニペットだ。

import redis

def check_redis_health(host=’localhost’, port=6379):
client = redis.Redis(host=host, port=port)

# MEMORY DOCTORの結果を取得
doctor_report = client.execute_command(‘MEMORY DOCTOR’)
print(f”Redis Health Report: {doctor_report.decode(‘utf-8’)}”)

# 簡易的な断片化チェック
info = client.info(‘memory’)
frag_ratio = info.get(‘mem_fragmentation_ratio’, 1.0)

if frag_ratio > 1.5:
# SlackやPagerDutyへアラート発報
send_alert(f”CRITICAL: Redis memory fragmentation is high: {frag_ratio}”)

if __name__ == “__main__”:
check_redis_health()

—

5. チーフアーキテクトからの提言

Redisは「速い」からといって、メモリ管理を怠っていい免罪符にはならない。
メモリは有限の資源であり、そのコストはクラウド時代において直接インフラ費用に跳ね返る。

今すぐ君たちのプロジェクトにあるRedisインスタンスに対して、手動であれスクリプトであれ、`MEMORY DOCTOR` を実行してみたまえ。
もしかすると、すでにシステムは静かに悲鳴を上げているかもしれない。

設計とは、構造の美しさだけでなく、こうした低レイヤーの挙動に対する深い洞察の積み重ねの上に成り立つものだ。
コードを書くだけがエンジニアではない。インフラストラクチャの「声」を聞き、先回りして守り抜くことこそが、真のプロフェッショナルの仕事である。