트래픽이 많은 WordPress 사이트를 성능을 위해 어떻게 튜닝하나요?

Question

Accepted Answer

**계층별로 최적화하세요 — 각 계층은 부하가 다음 계층에 닿기 전에 흡수합니다.** 목표는 대부분의 요청을 cache에서 제공하고 PHP와 데이터베이스가 가능한 한 적게 일하게 하는 것입니다.

## 1. PHP-FPM과 OPcache

**PHP-FPM** 풀을 RAM에 맞게 사이징하고, **OPcache**를 켜서 PHP가 매 요청마다가 아니라 한 번만 컴파일되게 하세요:

```ini
; php-fpm pool: RAM이 고갈되지 않도록 worker 상한 설정
; pm.max_children = (PHP용 가용 RAM) / (평균 프로세스 크기, ~50MB)
pm = dynamic
pm.max_children = 40          ; 동시 PHP worker 하드 상한
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500         ; memory leak 방지를 위해 worker 재활용

; OPcache: 컴파일된 bytecode를 메모리에 cache
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0   ; prod에서 file-stat 검사 생략 (deploy 시 flush)
```

`max_children`가 너무 높으면 swap하고 crash하며; 너무 낮으면 요청이 큐에 쌓입니다(부하 시 502).

## 2. Object cache와 page cache + CDN

- **Object cache** (Redis/Memcached) — DB query 결과와 WordPress object cache를 캐싱하여 반복 query가 MySQL을 건너뜁니다.
- **Full-page cache** — 익명 방문자에게 캐시된 HTML을 제공하여 PHP가 전혀 실행되지 않게 합니다(Varnish, Nginx FastCGI cache, 또는 플러그인).
- **CDN** — 정적 asset(이미지, CSS, JS)을 오프로드하고 사용자에 가장 가까운 edge에서 페이지를 캐싱합니다.

이 계층화 덕분에 홈페이지 접속이 PHP나 DB를 전혀 건드리지 않고 edge나 page cache에서 반환될 수 있습니다.

## 3. 데이터베이스와 플러그인

**slow query log**를 켜서 원인을 찾고, 커스텀 query에 **index**를 추가하고, **autoloaded options**를 점검하세요(`autoload = yes`인 `wp_options`는 *모든* 요청에서 로드됩니다 — 비대해진 autoload 데이터는 전부를 느리게 합니다). 마지막으로 **플러그인 비대화를 줄이세요**: 각 플러그인은 query와 PHP 작업을 더하므로, 쓰지 않는 것은 제거하세요.

## 왜 중요한가

WordPress 요청은 기본적으로 PHP와 DB 부하가 큽니다. 따라서 튜닝 없이는 트래픽에 무너집니다. 계층형 캐싱(OPcache → object cache → page cache → CDN)에 적절히 사이징된 PHP-FPM과 가벼운 데이터베이스를 더하면 단일 서버가 수십 배의 트래픽을 처리하고 — 스파이크 중에도 계속 가동되게 합니다.