キャッシュサーバーの役割と特性

Redis / Memcached はインメモリデータストアであり、DB アクセスを削減してレスポンスタイムを短縮するために使われる。全データをメモリ上に保持する設計であるため、スケールアップの主目的はメモリ増強だ。Redis は単一スレッド（コマンド処理）のため、CPU コア数を増やしても直接的なスループット向上にはつながりにくい。

ボトルネックになるリソース

リソース症状確認コマンド
メモリeviction 発生・maxmemory-policy によるキー削除redis-cli INFO memory
CPU（単一スレッド）高コストコマンド（KEYS・SMEMBERS 大）で 100% 張り付きredis-cli SLOWLOG GET
ネットワーク帯域大きい value のバルク転送で帯域飽和INFO stats → instantaneous_output_kbps

スケールアップの内容と効果

① メモリ増強（最優先）

■ 必要メモリの試算
必要メモリ = キー数 × (key + value + Redis オーバーヘッド 50〜100B) × 1.2
例：1,000万キー、key 20B + value 200B + overhead 75B = 295B/key
→ 1000万 × 295B × 1.2 ≈ 3.54GB → 4GB 以上を maxmemory に設定
Shell — Redis メモリ設定と確認
# redis.conf
maxmemory 8gb
maxmemory-policy allkeys-lru

# メモリ状況確認
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"
# eviction 確認（増えていれば maxmemory が不足）
redis-cli INFO stats | grep evicted_keys

⚠️ mem_fragmentation_ratio に注意

1.5 以上の場合はフラグメンテーションが発生中。MEMORY PURGE（Redis 4.0+）や再起動でフラグメントを解消してからスケールダウンを判断してください。

② CPU スパイクへの対処（コマンド最適化優先）

Redis — スロークエリ確認
redis-cli SLOWLOG GET 10
# KEYS * → SCAN に置き換える
# SMEMBERS(大) → SSCAN に置き換える
# LRANGE 0 -1 → ページネーションに変更
redis-cli --latency-history -i 1

スケールダウンの考え方

条件スケールダウン可否
evicted_keys が 30 日間ゼロmaxmemory 削減を検討可
used_memory が maxmemory の 50% 以下インスタンスサイズ縮小を検討可

スケールアップ vs スケールアウト

✅ Redis のスケール判断

単一ノードで 64GB 以下ならスケールアップが管理シンプル。64GB 超、または書き込みが 100,000 ops/s 超えで Redis Cluster（スケールアウト）を検討。読み取り多ければ Replica 追加。

判断指標（監視メトリクス）

メトリクス確認コマンドスケールアップの目安
メモリ使用率INFO memory → used_memory/maxmemory≥ 75% が継続
eviction 数INFO stats → evicted_keys1時間で 1,000 件超え
キャッシュヒット率INFO stats → keyspace_hits/misses≤ 85% に低下

まとめ

項目要点
スケールアップの主目的メモリ増強。eviction を防いでキャッシュヒット率を維持する。
CPU 対処KEYS/SMEMBERS 等の O(N) コマンドを SCAN 系に置き換える。CPU コア増加は効果薄。
maxmemory 設定物理メモリの 80% を上限。OS・バッファに 20% を残す。
スケールアウト移行データ量 64GB 超え、または書き込み 100K ops/s 超えで Redis Cluster を検討。