WHM(EasyApache 4) PHP 8.4 OPcache + Redis Object Cache 구성 장애 복구후기

관리자 화면이 느리거나, 첫 바이트가 늦게 도착(TTFB 상승)하는 사이트는 대개 PHP 실행 비용과 DB 질의 반복에서 시간이 빠집니다. WHM(EasyApache 4) 환경에서 OPcache와 Redis Object Cache를 붙일 때 필요한 설정과, 켠 뒤에 자주 터지는 장애 복구후기를 남겨봅니다.

목표: PHP 실행 최적화(OPcache) + DB/Object Cache(Redis)로 TTFB 및 관리자 지연을 줄입니다.

환경 WHM(EasyApache 4) / PHP 8.4 / SSH(root) / Redis Object Cache 플러그인

1) WHM에서 OPcache 활성화

WHM에서는 GUI로 켜는 편이 가장 빠릅니다.

우선 아래 경로로 이동해 php-opcache만 체크하고 Provision까지 완료하시면 됩니다.

경로: WHM → EasyApache 4 → Customize → PHP Extensions → php-opcache 체크 → Review → Provision

OPcache를 켜면 무엇이 달라지나

OPcache는 PHP 파일을 매 요청마다 다시 해석하지 않고, 컴파일 결과(바이트코드)를 메모리에 보관해 반복 실행 비용을 줄입니다.

연결이 되면 포트는 열려 있다고 보셔도 됩니다처럼 단정할 수는 없지만, OPcache는 “DB를 줄이는 도구”가 아니라 PHP 실행 자체를 가볍게 하는 장치라고 보시면 됩니다.

체감이 잘 나오는 구간은 방문자가 몰릴 때 CPU가 급격히 올라가는 상황, 그리고 관리자에서 글 저장/설정 저장처럼 PHP가 연속 호출되는 구간으로 반대로 외부 API 호출이나 DB 쿼리 구조가 병목이면 OPcache만으로는 개선이 제한적일 수 있습니다.

적용 요소	바로 변하는 증상	체감이 약한 경우
OPcache	반복 요청에서 CPU 사용량이 완만해짐 관리자 저장/로딩이 덜 출렁이는 편	쿼리 자체가 과도하거나 외부 호출이 병목인 구조
Redis Object Cache	같은 쿼리를 반복하는 구간에서 지연이 줄어듦 관리자 목록/편집 화면이 안정화되는 경우가 많음	TTL/메모리 정책이 없어 메모리 포화로 터지는 구성

2) SSH에서 Redis 서버 설치/자동시작

SSH 접속 시 비밀번호 입력이 화면에 표시되지 않아도 정상입니다.

그대로 입력 후 엔터를 누르시면 됩니다. Redis는 서버에 데몬이 떠 있어야 플러그인이 붙습니다.

# Redis 설치
dnf install redis -y

# 부팅 시 자동 시작 + 즉시 시작
systemctl enable --now redis

# 상태 확인
systemctl status redis --no-pager

연결 오류가 뜨면 먼저 볼 것

systemctl status redis에서 running이 아니면 플러그인 쪽은 아무리 만져도 계속 실패합니다.

여기서부터 원인 분리가 시작됩니다.

3) PHP 8.4 Redis 확장 설치 (ea-php 패키지)

Redis 서버가 떠 있어도, PHP가 Redis Object Cache 와 통신할 확장 모듈이 없으면 워드프레스는 붙지 않습니다.

• [IT 리뷰/블로그 SEO] - 블루호스트 VPS 워드프레스 TTFB 줄이기(OPcache + Redis Object Cache 설치)
• [IT 리뷰/블로그 SEO] - 워드프레스 성능 개선 3가지 - 하나 이상의 필수모듈 누락 예정된 이벤트, 지속적인 객체캐시 사용

WHM/EasyApache 4 환경은 보통 ea-php 버전별 패키지를 씁니다.

3-1. 패키지명 빠르게 찾기

# PHP 8.4 관련 Redis/OPcache 패키지 후보를 검색
dnf search ea-php84 | egrep -i 'redis|opcache|memcache' || true

# 설치 가능한 정확한 이름이 헷갈릴 때(예: redis vs phperedis) 아래도 유용
dnf search ea-php84 | egrep -i 'php-redis|phperedis|redis' || true

3-2. 설치 명령(대표 케이스)

구분	패키지명(예시)	설명
OPcache	ea-php84-php-opcache	WHM에서 체크로 켜는 방식이 일반적입니다. CLI 설치는 보조 수단으로 두시면 됩니다.
Redis(PHP 확장)	ea-php84-php-redis (환경에 따라 ea-php84-phperedis)	워드프레스 Redis Object Cache가 붙는 핵심입니다. Redis 서버와 PHP 확장이 둘 다 있어야 합니다.

# (예시) PHP 8.4 Redis 확장 설치
dnf install ea-php84-php-redis -y

# 적용: 블루호스트/WHM 환경에서 php-fpm 재시작이 안 먹히면 httpd 재시작이 안전
systemctl restart httpd

4) 워드프레스 설정: Redis Object Cache

플러그인 설치 후 “Enable Object Cache”를 누르면 wp-content/object-cache.php 드롭인이 생성됩니다. 이 파일이 생기면 워드프레스가 Redis를 캐시 계층으로 쓰기 시작합니다.

4-1. wp-config.php 권장 상수

가장 중요한 건 키 충돌 방지입니다. 운영/스테이징/복제본이 섞이면 같은 Redis DB를 공유하면서 꼬일 수 있어 WP_CACHE_KEY_SALT는 사실상 필수에 가깝습니다.

/** Redis Object Cache (PHP 8.4 / local redis) */
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);

/** 클라이언트 지정(환경에 따라 'phpredis' or 'predis') */
define('WP_REDIS_CLIENT', 'phpredis');

/** 키 프리픽스(멀티사이트/스테이징/복수 설치 시 충돌 방지) */
define('WP_CACHE_KEY_SALT', 'my-site:');

/** TTL(선택): 무제한 캐시로 Redis 메모리가 차는 걸 방지하고 싶을 때 */
define('WP_REDIS_MAXTTL', 900);

자주 막히는 지점입니다. TTL이 없고 메모리 정책도 없으면 Redis가 가득 찼을 때부터 에러가 나오기 시작합니다. “연결 오류”처럼 보이지만 실제로는 메모리 포화가 원인인 경우도 꽤 많습니다.

5) Redis 메모리/정책 권장값 (redis.conf)

오브젝트 캐시는 “많이 저장”보다 “안전하게 버리기”가 더 중요합니다. Redis를 캐시로 쓰면서 maxmemory와 maxmemory-policy를 같이 잡지 않으면, 어느 순간 서버 전체가 흔들릴 수 있습니다.

5-1. 메모리 상한 예시

대략적 성격	Redis maxmemory	비고
소형~중형	256MB	RAM 여유가 적을 때 무난한 시작점
중형~대형	512MB ~ 1GB	관리자/크롤링/배치가 잦으면 이 구간이 편합니다
대형 이상	1GB ~ 2GB+	동접/봇/배치가 크면 RAM 여유에 맞춰 상향

5-2. redis.conf 예시(안전한 기본)

# 파일 위치는 배포판/설치 방식에 따라 다를 수 있음(예: /etc/redis/redis.conf)
# (1) 외부 노출 방지(로컬만)
bind 127.0.0.1 ::1
protected-mode yes

# (2) 메모리 상한 + 축출 정책(핫 키 유지)
maxmemory 512mb
maxmemory-policy allkeys-lru

# (3) (선택) 영속성 - 운영 성격에 따라 선택
appendonly yes
appendfsync everysec

allkeys-lru는 “오래 안 쓴 키부터 버리기”입니다. 캐시 Redis에서는 이 성격이 잘 맞습니다. 반대로 기본값에 가까운 noeviction은 “가득 차면 더는 못 넣기”라서 장애 상황을 더 크게 만드는 편입니다.

6) 장애 복구: DB 연결 오류 / 하얀 화면 / 관리자 로그인 문제

Redis를 켠 직후 "Error Establishing a Database Connection"가 뜨거나, 관리자 로그인에서 “Redis 연결 설정 중 오류”가 나오면 복구를 우선하셔야 합니다. 이 부분만 확인하시면 됩니다. 드롭인(object-cache.php)을 잠깐 빼면 사이트는 DB 기반으로 바로 돌아옵니다.

1. 즉시 복구: wp-content/object-cache.php 파일 삭제(또는 이름 변경) → 화면 복구
2. 서버 확인: systemctl status redis --no-pager가 active (running)인지 확인
3. 확장 확인: PHP 8.4 Redis 확장이 설치되어 있는지 재확인
4. 재적용: systemctl restart httpd 후 플러그인에서 다시 Enable Object Cache

캐시를 켜자마자 과부하가 생기면 “캐시가 빨라졌나”보다 캐시 미스 + 웜업을 먼저 의심하셔야 합니다. 초기에는 캐시가 비어 있어 DB 질의가 몰릴 수 있고, Redis까지 추가로 떠서 CPU/메모리를 동시에 씁니다. VPS 사양이 타이트하면 이 구간에서 되려 느려질 수 있습니다.

7) 최종 점검 체크리스트

• WHM에서 php-opcache 활성화 + Provision 완료
• Redis 서버: systemctl status redis가 active (running)
• PHP 8.4 Redis 확장 설치(예: ea-php84-php-redis)
• 적용 재시작: systemctl restart httpd
• 워드프레스에서 Enable Object Cache로 드롭인 생성
• Redis에 maxmemory + allkeys-lru 적용

8) 운영 환경에서 자주 터지는 증상별 빠른 분리

“Redis 켠 뒤부터만 느리다”는 말이 나오면 캐시 자체보다 연결 실패 재시도나 리소스 압박이 섞였을 가능성이 큽니다. 특히 관리자 화면은 요청이 무거워 실패가 더 잘 드러납니다.

자주 보이는 증상	로그/메시지 단서	먼저 할 일
특정 저장/업데이트만 500	memory exhausted, allowed memory size	PHP/워드프레스 메모리 상향 + 무거운 플러그인 점검
간헐적 500 / DB 오류	too many connections, server shutdown	동시성/리소스 확인 + 크롤러/배치 시간대 점검
캐시 켠 뒤부터 500	redis 127.0.0.1:6379, object-cache.php	드롭인 제거로 복구 → Redis 서버/확장 재확인 후 재적용
.htaccess 수정 직후 500	웹서버 레벨 오류, 403/500 반복	최근 변경 줄 롤백 후 최소 변경 단위로 다시 적용

9) 로그 관리와 보안 주의

로그는 켜두면 편하지만, 그대로 두면 용량이 금방 불어납니다. 운영 환경에서는 확인할 때만 켜고 끝나면 정리하는 편이 속이 편합니다.

• 확인 끝나면 display_errors는 꺼두는 편이 안전합니다.
• debug.log / php_error.log는 확인 후 파일 비우기 또는 이름 변경 보관
• 로그 파일을 웹에서 접근 가능한 위치(문서 루트)에 두지 않기

10) 대규모 사이트에서 Redis 지연(Latency)이 튀는 경우

데이터가 큰 사이트는 “연결 성공”만으로 끝나지 않습니다. 어느 순간 지연이 튀면서 관리자 화면이 느려지면, 연결 값보다 클라이언트와 메모리 정책이 좌우하는 경우가 많습니다.

10-1. Predis보다 PhpRedis를 우선

Predis는 PHP 라이브러리 방식이라 편하지만 무겁습니다. PhpRedis는 C 확장이라 비용이 낮습니다. 지연이 반복되면 WP_REDIS_CLIENT를 phpredis로 고정해두는 쪽이 흔합니다.

define('WP_REDIS_CLIENT', 'phpredis');

10-2. “가득 차면 알아서 비우기”를 명령으로 적용

# 1. 메모리 꽉 차면 오래된 것부터 삭제하도록 변경
redis-cli config set maxmemory-policy allkeys-lru

# 2. 데이터 지울 때 서버 멈춤(렉) 방지 설정
redis-cli config set lazyfree-lazy-eviction yes
redis-cli config set lazyfree-lazy-expire yes

10-3. 과부하인지 확인하는 최소 명령

redis-cli info stats | grep ops_per_sec
redis-cli config get maxmemory-policy

ops_per_sec는 초당 처리 명령 수입니다. 값이 평소 대비 과도하게 치솟으면 캐시 미스/봇/배치가 같이 흔들고 있을 가능성이 큽니다.

Q. Redis Object Cache를 켰는데 오히려 더 느려졌습니다. 정상인가요?

A.초기에는 캐시가 비어 있어 DB 질의가 몰릴 수 있습니다. Redis까지 추가로 떠서 CPU/메모리를 같이 쓰기 때문에 VPS 사양이 타이트하면 되려 느려질 수 있습니다. 불안정하면 wp-content/object-cache.php를 잠깐 빼서 안정화한 뒤 다시 붙이시는 편이 안전합니다.

Q. “Redis 연결 설정 중 오류”가 관리자 로그인에서만 뜹니다.

A.관리자는 요청이 무거워 실패가 더 잘 드러납니다. Redis가 running인지, WP_REDIS_HOST/PORT가 로컬과 맞는지, PHP Redis 확장이 설치되어 있는지부터 확인하시면 됩니다.

Q. 드롭인(object-cache.php) 삭제하면 캐시 설정이 모두 날아가나요?

A.드롭인은 캐시 사용 스위치에 가깝습니다. 삭제하면 캐시가 비활성화되고 사이트는 DB 기반으로 돌아옵니다. 플러그인 설정은 남아 있는 경우가 많아 다시 Enable 하면 재생성됩니다.

Q. Redis를 외부에서 접속 가능하게 열어도 되나요?

A.권장하지 않습니다. 오브젝트 캐시는 보통 로컬(127.0.0.1)에서만 붙입니다. 부득이하게 분리 구성이라면 방화벽 제한, 인증, 전용 네트워크(관리망)까지 같이 잡으셔야 합니다.

Q. OPcache만 켜도 체감이 있나요?

A.PHP 실행 시간이 병목이면 체감이 납니다. 반대로 쿼리/외부 호출이 병목이면 OPcache만으로는 한계가 있어 Redis(오브젝트 캐시)나 플러그인/쿼리 구조 정리가 더 크게 먹힙니다.