1. 시작하기 전에: 캐시는 "게으름"이 아니라 "기억력"이다

친구야, 솔직히 말해보자.
PHP로 서비스 만들다가 트래픽이 조금 늘어나면 제일 먼저 터지는 게 뭘까?
정답은 거의 항상 데이터베이스야.

PHP는 기본적으로 Shared-Nothing 아키텍처야.
요청 하나가 들어오면 프로세스가 깨어나고, 코드 읽고, 연산하고, 응답 뱉고, 싹 다 잊어버려.
자바처럼 애플리케이션 메모리에 데이터를 계속 들고 있는 구조가 아니라는 거지.

그래서 PHP는 "다음 요청에서도 기억하게 만드는 장치"가 구조적으로 필요해.
그게 바로 캐시야. 캐시는 게으름이 아니라, PHP에게 선물하는 외장 기억력인 셈이지.

2. PHP 캐싱의 4개 층: 뭐부터 손대야 이득일까

2-1. OPcache — 안 켰으면 지금 켜라

PHP는 매 요청마다 .php 파일을 파싱해서 바이트코드로 컴파일해.
OPcache는 이 컴파일 결과를 공유 메모리에 저장해서 재사용하게 만들어줘.
PHP 5.5부터 코어에 포함됐고, 요즘 배포판은 기본 활성인 경우가 많지만 설정값은 기본값 그대로인 경우가 아주 흔해.

; php.ini
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256      ; MB, 코드량 많으면 올려라
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000 ; 파일 수보다 크게
opcache.validate_timestamps=0       ; 운영: 파일 변경 검사 끄기(배포 시 리셋 필수)
opcache.save_comments=1             ; 어노테이션 쓰는 프레임워크는 1 유지
opcache.jit_buffer_size=64M         ; PHP 8+, 웹 요청엔 효과 제한적

2-2. APCu — 프로세스 로컬 초고속 캐시

APCu는 같은 서버 안의 PHP-FPM 워커들이 공유하는 메모리 캐시야.
네트워크를 안 타니까 Redis보다도 빨라. 마이크로초 단위.
단점은 명확해. 서버 간 공유가 안 되고, FPM 재시작하면 날아가.

// 설정값, 라우팅 테이블처럼 "잘 안 변하고 모든 요청이 읽는" 데이터에 최적
$key = 'site:config:v3';
$cfg = apcu_fetch($key, $ok);
if (!$ok) {
    $cfg = loadConfigFromDb();
    apcu_store($key, $cfg, 300); // 300초
}

2-3. 분산 데이터 캐시 — Memcached / Redis

여기가 오늘의 주인공. 웹서버가 여러 대일 때 공통의 기억 장소가 되어주는 층이야.
세션, 쿼리 결과, 렌더링된 HTML 조각, API 응답 등 거의 모든 걸 여기에 담지.

2-4. HTTP / 리버스 프록시 캐시

가장 저렴한 캐시는 PHP를 아예 실행하지 않는 캐시야.
비로그인 사용자에게 보여주는 목록 페이지 같은 건 Nginx proxy_cache나 CDN에서 끊어버리면
PHP 프로세스 점유 자체가 0이 돼. 체감 효과는 이 층이 제일 크다.

3. Memcached vs Redis: 싸움 붙이지 말고 역할을 나누자

"둘 중 뭐가 좋아요?"는 사실 "망치랑 드라이버 중 뭐가 좋아요?" 같은 질문이야.
팩트 위주로 비교표부터 보자.

4. PHP에서 실제로 붙이기: 코드로 보는 기본기

Redis 연결 (phpredis 확장)

$redis = new Redis();
$redis->pconnect('127.0.0.1', 6379, 2.0); // 지속 연결 + 2초 타임아웃
$redis->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_IGBINARY);
$redis->setOption(Redis::OPT_PREFIX, 'app:');
$redis->auth('your-strong-password');

// Cache-Aside 기본형
function getProduct(Redis $r, PDO $db, int $id): ?array {
    $key = "product:$id";
    $hit = $r->get($key);
    if ($hit !== false) {
        return $hit === 'NULL' ? null : $hit; // 널 캐싱
    }
    $stmt = $db->prepare('SELECT * FROM products WHERE id = ?');
    $stmt->execute([$id]);
    $row = $stmt->fetch(PDO::FETCH_ASSOC) ?: null;

    // TTL에 지터를 섞어 동시 만료(캐시 스탬피드) 방지
    $ttl = $row ? 600 + random_int(0, 120) : 30;
    $r->setex($key, $ttl, $row ?? 'NULL');
    return $row;
}

pconnect는 PHP-FPM 워커가 커넥션을 재사용하게 해줘서 연결 오버헤드를 줄여줘.
다만 워커 수 × 서버 수 만큼 커넥션이 잡히니까 Redis의 maxclients는 꼭 확인하자.

Memcached 연결 (ext-memcached)

$mc = new Memcached('pool-main'); // 이름 주면 지속 연결 풀 재사용
if (!count($mc->getServerList())) {
    $mc->setOptions([
        Memcached::OPT_BINARY_PROTOCOL => true,
        Memcached::OPT_LIBKETAMA_COMPATIBLE => true, // 일관된 해싱
        Memcached::OPT_CONNECT_TIMEOUT => 500,
        Memcached::OPT_RETRY_TIMEOUT => 2,
        Memcached::OPT_REMOVE_FAILED_SERVERS => true,
        Memcached::OPT_COMPRESSION => true,
    ]);
    $mc->addServers([['10.0.0.11', 11211], ['10.0.0.12', 11211]]);
}

$data = $mc->get('ranking:daily');
if ($mc->getResultCode() === Memcached::RES_NOTFOUND) {
    $data = buildRanking();
    $mc->set('ranking:daily', $data, 300);
}

PSR-6 / PSR-16 로 추상화하기

드라이버를 코드 곳곳에 직접 박아두면 나중에 Memcached → Redis 갈아탈 때 지옥을 봐.
PHP 생태계는 PSR-6(CacheItemPool)과 PSR-16(SimpleCache) 표준을 갖고 있어.
Symfony Cache, Laravel Cache가 대표적이지.

use Symfony\Component\Cache\Adapter\RedisAdapter;
use Symfony\Component\Cache\Adapter\ApcuAdapter;
use Symfony\Component\Cache\Adapter\ChainAdapter;

// L1: APCu(로컬) + L2: Redis(공유) 2단 캐시
$cache = new ChainAdapter([
    new ApcuAdapter('app', 5),          // 5초짜리 초단기 로컬 캐시
    new RedisAdapter($redis, 'app', 600),
]);

$value = $cache->get('home:banner', function ($item) {
    $item->expiresAfter(600);
    return fetchBanners();
});

이 2단(Chain) 구조, 실무에서 진짜 강력해.
초당 수천 번 읽히는 설정값을 APCu가 흡수해주면 Redis 네트워크 왕복 자체가 사라지거든.

5. 캐싱 전략 5종 세트

① Cache-Aside (Lazy Loading)

가장 흔한 패턴. 읽을 때 캐시 먼저 보고, 없으면 DB에서 읽어 채운다.
장점은 단순함과 필요한 것만 캐싱된다는 점.
단점은 첫 요청이 항상 느리고, 데이터 갱신 시 무효화 로직을 직접 챙겨야 한다는 것.

② Write-Through

쓰기를 할 때 DB와 캐시를 동시에 갱신해.
읽기 일관성이 좋지만, 쓰기 지연이 늘고 안 읽힐 데이터까지 캐싱되는 낭비가 생겨.

③ Write-Behind (Write-Back)

캐시에 먼저 쓰고 DB는 비동기로 나중에 반영.
조회수, 좋아요 카운터처럼 정확도보다 처리량이 중요한 데이터에 딱이야.

// 조회수: Redis에서 INCR, 1분마다 배치로 DB flush
$redis->hIncrBy('pv:buffer', "post:$postId", 1);

// 크론 워커
$buf = $redis->hGetAll('pv:buffer');
$redis->del('pv:buffer');
foreach ($buf as $k => $cnt) {
    $id = (int)substr($k, 5);
    $db->prepare('UPDATE posts SET views = views + ? WHERE id = ?')
       ->execute([$cnt, $id]);
}

④ Refresh-Ahead / 조기 재계산

TTL이 만료되기 직전에 미리 갱신하는 방식.
Symfony Cache의 beta 파라미터(확률적 조기 만료, XFetch 알고리즘)가 이걸 구현해줘.

// beta가 클수록 만료 전에 미리 재계산할 확률이 높아진다
$value = $cache->get('heavy:report', function ($item) {
    $item->expiresAfter(3600);
    return buildHeavyReport();
}, 1.5);

⑤ Full Page Cache

비로그인 트래픽이 많은 서비스라면 최고 가성비.
렌더링된 HTML 전체를 Redis나 파일에 저장하고, 가능하면 Nginx 단에서 바로 응답해버려.
PHP 실행 자체를 건너뛰니까 초당 처리량이 자릿수로 뛴다.

6. 캐시 무효화: 컴퓨터 과학의 2대 난제

"컴퓨터 과학에는 두 가지 어려운 문제가 있다. 캐시 무효화와 네이밍."
필 칼튼의 이 농담, 캐시 좀 다뤄본 사람은 웃지 못해. 너무 사실이라서.

패턴 A. 키에 버전 심기

// updated_at 기반 키 — 데이터가 바뀌면 키 자체가 달라진다
$key = sprintf('post:%d:v%d', $post['id'], strtotime($post['updated_at']));

삭제(DEL)를 할 필요가 없어서 가장 안전한 무효화야.
옛 키는 TTL로 자연 소멸하게 두면 돼.

패턴 B. 네임스페이스 버전

$ver = $redis->get('ns:product:ver') ?: 1;
$key = "product:list:$ver:page:$page";

// 상품이 하나라도 바뀌면
$redis->incr('ns:product:ver'); // 관련 캐시 전체가 한 방에 무효화

패턴 C. 태그 기반 무효화

Symfony의 TagAwareAdapter, Laravel의 Cache::tags()가 제공해.
단, Laravel의 태그 기능은 Redis/Memcached 드라이버에서만 동작한다는 점 기억하자.

Cache::tags(['products', "brand:$brandId"])
     ->remember("product:$id", 600, fn() => Product::find($id));

Cache::tags(["brand:$brandId"])->flush();

7. 캐시 스탬피드: 새벽 3시에 서버를 죽이는 범인

상황을 그려보자. 인기 게시글 캐시 TTL이 600초야.
정확히 만료되는 그 순간, 동시에 들어온 500개의 요청이 전부 캐시 미스를 만나.
그리고 500개가 동시에 똑같은 무거운 쿼리를 DB에 날려.
DB 커넥션 풀 고갈 → 응답 지연 → 요청 적체 → 서버 다운. 이게 Cache Stampede야.

해법 1: TTL 지터

$ttl = 600 + random_int(-60, 60); // 만료 시점을 흩뿌린다

해법 2: 뮤텍스 락 (SET NX)

function remember(Redis $r, string $key, int $ttl, callable $fn) {
    $val = $r->get($key);
    if ($val !== false) return $val;

    $lock = "lock:$key";
    // NX + EX 원자적 락 획득
    if ($r->set($lock, 1, ['nx', 'ex' => 10])) {
        try {
            $val = $fn();
            $r->setex($key, $ttl, $val);
        } finally {
            $r->del($lock);
        }
        return $val;
    }

    // 락을 못 얻은 요청은 잠깐 기다렸다 재시도
    for ($i = 0; $i < 20; $i++) {
        usleep(50000); // 50ms
        $val = $r->get($key);
        if ($val !== false) return $val;
    }
    return $fn(); // 최후의 폴백
}

해법 3: 논리적 만료 (Stale-While-Revalidate)

캐시 값 안에 expires_at을 같이 저장하고, 물리 TTL은 훨씬 길게 잡아.
논리적으로 만료됐으면 일단 오래된 값을 바로 반환하고, 갱신은 백그라운드로 던져.
사용자는 절대 기다리지 않게 되지. 실무에서 가장 안정적인 패턴이야.

$payload = json_decode($redis->get($key) ?: 'null', true);
if ($payload) {
    if ($payload['exp'] < time() && $redis->set("refresh:$key", 1, ['nx','ex'=>30])) {
        dispatch(new RefreshCacheJob($key)); // 큐로 위임
    }
    return $payload['data']; // 낡았어도 즉시 응답
}

8. 세션 저장소를 Redis로 옮기기

PHP 기본 세션은 파일 기반이야. 서버 한 대일 땐 문제없지만
로드밸런서 뒤에 서버 2대만 놔도 로그인이 풀리는 괴현상이 시작돼.
sticky session으로 버티는 방법도 있지만, 정석은 세션 저장소 분리야.

; php.ini
session.save_handler = redis
session.save_path = "tcp://10.0.0.20:6379?auth=pw&database=1&timeout=2"
session.gc_maxlifetime = 7200
session.lazy_write = 1

그리고 세션 DB는 캐시 DB와 분리하는 게 좋아.
캐시용 Redis에 maxmemory-policy allkeys-lru를 걸어놨는데 세션까지 같이 있으면?
메모리 압박이 오는 순간 사용자 세션이 통째로 증발해. 로그인 전원 해제 사고 나는 거지.

# 캐시 전용 인스턴스
maxmemory 4gb
maxmemory-policy allkeys-lru

# 세션 전용 인스턴스
maxmemory 2gb
maxmemory-policy volatile-lru   # TTL 있는 키만 축출
appendonly yes                  # 재시작해도 세션 유지

9. Redis 자료구조로 즐기는 고급 기술

실시간 랭킹 — Sorted Set

$redis->zIncrBy('rank:20240601', 1, "user:$uid");
$top = $redis->zRevRange('rank:20240601', 0, 9, true); // 상위 10명
$myRank = $redis->zRevRank('rank:20240601', "user:$uid");

MySQL로 ORDER BY score DESC LIMIT 10 때리는 것보다 압도적으로 빨라.
ZSet 연산은 O(log N)이고, 내부적으로 skiplist로 구현돼 있거든.

API 레이트 리밋 — 슬라이딩 윈도우

$key = "rl:$userId:" . floor(time() / 60);
$cnt = $redis->incr($key);
if ($cnt === 1) $redis->expire($key, 120);
if ($cnt > 100) {
    http_response_code(429);
    exit('Too Many Requests');
}

Lua 스크립트로 원자성 확보

// 재고 차감을 원자적으로
$lua = <<<'LUA'
local s = tonumber(redis.call('GET', KEYS[1]) or '0')
if s < tonumber(ARGV[1]) then return -1 end
return redis.call('DECRBY', KEYS[1], ARGV[1])
LUA;
$left = $redis->eval($lua, ["stock:$pid", 3], 1);

Redis는 Lua 스크립트를 하나의 원자적 단위로 실행해.
경쟁 조건 걱정 없이 "확인 후 변경" 로직을 안전하게 만들 수 있지.
다만 스크립트가 길면 싱글스레드를 점유하니 짧게 유지하는 게 철칙이야.

파이프라이닝 — 왕복 횟수를 줄여라

// 100번 GET = RTT 100회 → 느림
$pipe = $redis->multi(Redis::PIPELINE);
foreach ($ids as $id) $pipe->get("product:$id");
$results = $pipe->exec(); // RTT 1회

캐시가 느리다고 느껴질 때, 원인의 절반은 Redis가 아니라 N+1 왕복이야.
MGET이나 파이프라인으로 묶는 것만으로 체감이 확 바뀐다.

10. 측정 없는 최적화는 미신이다

재능넷 '지식인의 숲'에서 성능 관련 질문을 보다 보면,
"캐시 붙였는데 왜 안 빨라져요?"라는 하소연이 꽤 많아.
대부분의 원인은 병목이 거기가 아니었다는 거야.

먼저 봐야 할 지표들

# Redis 상태 확인
redis-cli INFO stats | grep keyspace
# keyspace_hits / keyspace_misses → 히트율 계산
redis-cli INFO memory | grep -E 'used_memory_human|evicted'
redis-cli --latency -h 127.0.0.1
redis-cli SLOWLOG GET 10

# Memcached
echo "stats" | nc 127.0.0.1 11211 | grep -E 'get_hits|get_misses|evictions'

프로파일링 도구

Xdebug의 프로파일러는 개발 환경용, 운영에서는 Blackfire나 Tideways, 무료로는 Excimer/SPX 같은 샘플링 프로파일러를 써.
"어디서 느린지"를 숫자로 본 다음에 캐시를 붙여야, 붙인 만큼 효과가 나와.

11. 실전 체크리스트와 흔한 실수

// 캐시 장애에도 죽지 않는 래퍼
function safeCache(callable $get, callable $fallback) {
    try {
        return $get();
    } catch (RedisException|Throwable $e) {
        error_log('cache down: ' . $e->getMessage());
        return $fallback(); // DB 직행
    }
}

12. 정리: 캐시는 아키텍처의 문제다

여기까지 왔으면 감이 올 거야.
캐싱은 "Redis 깔고 set/get 몇 줄 쓰는 일"이 아니라,
데이터의 변경 빈도와 일관성 요구 수준을 설계하는 일이야.

상품 가격은 1초만 틀려도 안 되지만, 인기 게시글 목록은 5분 늦어도 아무도 안 죽어.
이 차이를 구분하는 순간, TTL과 무효화 전략이 자연스럽게 정해져.

마지막으로 하나만 기억해줘.
캐시는 성능 문제를 해결하는 게 아니라 뒤로 미루는 도구라는 사실.
근본적으로 느린 쿼리는 인덱스와 스키마로 고쳐야 하고,
캐시는 그 위에 얹는 가속 레이어여야 해.
순서를 거꾸로 하면, 언젠가 캐시가 걷히는 순간 서비스가 통째로 무너져.

더 깊은 실전 사례나 코드 리뷰가 필요하다면 재능넷의 개발 전문가들에게 물어보는 것도 좋은 방법이야.
성능 최적화는 결국 경험치 싸움이거든. 오늘도 즐거운 튜닝 되길!