오라클 클라우드 찾아온 502 Bad Gateway
오라클 클라우드 프리티어의 장점 바로 무료로 사용 가능하다는 점은 제 입장에서는 축복과도 같습니다. 하지만 사양이 낮은 인스턴스(특히 RAM 1GB~2GB 모델)에서 워드프레스를 운영하다 보면 PHP-FPM 최적화 설정을 해야하는데요. 이는 바로 불시에 찾아오는 ‘502 Bad Gateway’ 에러 때문입니다.
분명히 어제까지 잘 접속되던 사이트가 갑자기 먹통이 되고, 서버를 재시작해야만 겨우 살아나는 현상. 저 역시 바로 어제 이 문제를 겪었고, 원인을 파악해 보니 범인은 바로 PHP-FPM의 과도한 메모리 점유였습니다.
오늘은 저사양 서버에서도 워드프레스를 쾌적하게 돌릴 수 있는 PHP-FPM 최적화 설정값을 공유하고자 합니다.
502 Bad Gateway, 도대체 무엇인가?
02 에러는 한 마디로 게이트웨이 간의 통신 불량을 의미합니다. 워드프레스 환경에서는 보통 웹서버(NGINX)와 애플리케이션 서버(PHP-FPM) 사이의 연결이 끊어졌을 때 발생합니다.
사용자가 접속하면 NGINX가 요청을 받습니다.
NGINX는 이 요청을 처하기 위해 PHP-FPM에게 전달합니다.
이때 PHP-FPM이 메모리 부족으로 죽어있거나, 응답을 제때 주지 못하면 NGINX는 “저쪽(PHP-FPM)에서 이상한 답을 주네?”라며 사용자에게 502 Bad Gateway라는 대답을 해주는 거죠.
저사양 서버에서 502가 유독 자주 뜨는 이유
오라클 클라우드 프리티어와 같은 1GB RAM 서버에서는 메모리 관리가 생명입니다.
RAM이 꽉 차면 서버는 하드디스크(SSD)의 일부를 메모리처럼 쓰기 시작합니다. 이때 속도가 급격히 느려지며 NGINX가 기다리다 연결을 끊어버립니다.
리눅스 시스템은 메모리가 한계치에 다다르면 시스템 붕괴를 막기 위해 가장 메모리를 많이 먹는 프로세스를 강제로 죽입니다. 보통 그 희생양이 PHP-FPM이나 MySQL이 되고, 그 결과 사이트는 즉시 502 에러를 뱉게 됩니다.
# NGINX 에러 로그 확인
tail -f /var/log/nginx/error.log
# 로그에 "upstream prematurely closed connection" 혹은
# "connect() failed (111: Connection refused)" 가 찍혀있다면
# 100% PHP-FPM 문제입니다.PHP-FPM 최적화 – 왜 메모리가 부족할까?
워드프레스는 PHP 기반으로 동작하며, 이를 효율적으로 관리하기 위해 PHP-FPM을 사용합니다. 문제는 PHP-FPM의 기본 설정이 어느 정도 사양이 뒷받침되는 서버에 맞춰져 있다는 점입니다.
기본 설정인 pm = dynamic 방식은 미리 일정 수의 프로세스를 띄워놓고 대기합니다. 하지만 접속자가 없어도 메모리를 계속 점유하고 있기 때문에, RAM 1GB 내외의 서버에서는 데이터베이스(MySQL/MariaDB)와 메모리 쟁탈전을 벌이다 결국 서버가 뻗어버리게 됩니다. 이를 해결하기 위해서는 프로세스 관리 방식을 서버 사양에 맞게 ‘다이어트’ 시켜야 합니다.
PHP-FPM 최적화 ondemand 방식 변경
저사양 서버 최적화의 핵심은 pm = ondemand 설정입니다. 이름 그대로 ‘요청이 있을 때만’ 프로세스를 생성하는 방식입니다.
핵심 설정값 설명 (RAM 1GB~2GB 기준)
WordOps 환경을 기준으로 /etc/php/8.3/fpm/pool.d/www.conf (버전에 따라 경로 상이) 파일을 수정해야 합니다.
pm = ondemand: 접속자가 있을 때만 PHP 프로세스를 깨웁니다. 평상시 메모리 점유율을 획기적으로 낮춰줍니다.
pm.max_children = 10: 동시에 띄울 수 있는 최대 프로세스 수입니다. 프로세스당 약 30~50MB를 소모하므로, 1GB RAM 서버에서는 10~15 사이가 가장 안전합니다.
pm.process_idle_timeout = 10s: 요청 처리가 끝난 프로세스가 몇 초 뒤에 사라질지 결정합니다. 10초 정도로 짧게 잡으면 메모리 회수가 빠릅니다.
pm.max_requests = 500: 한 프로세스가 500번의 요청을 처리하면 스스로 종료하고 새로 시작합니다. 이는 장기적인 메모리 누수(Memory Leak)를 방지하는 안전장치입니다.
실전 적용: WordOps 환경에서 수정하기
이제 터미널을 열고 직접 설정을 변경해 보겠습니다. (PHP 8.3 버전을 예로 듭니다.)
1) 설정 파일 열기
Bash
sudo nano /etc/php/8.3/fpm/pool.d/www.conf
2) 설정 내용 수정
기존의 pm = dynamic 관련 설정을 주석 처리하거나 아래 내용으로 덮어씁니다.
Ini, TOML
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s
pm.max_requests = 500
3) PHP-FPM 재시작
설정을 마쳤다면 문법 검사 후 서비스를 재시작합니다.
Bash
sudo php-fpm8.1 -t
sudo systemctl restart php8.1-fpm
htop과 로그 확인
설정 적용 후 서버에 다시 접속해 보세요. 터미널에서 htop 명령어를 입력해 보면, 이전보다 메모리 사용량이 눈에 띄게 줄어든 것을 확인할 수 있습니다. 특히 접속자가 없을 때 php-fpm 프로세스들이 사라지고 메모리가 확보되는 모습이 보인다면 성공입니다.
또한 WordOps를 사용 중이라면 x-cache: hit 상태를 체크하여 서버 부하가 실제로 줄어들었는지 모니터링하는 것이 좋습니다.
오라클 클라우드 성능 최적화 x-cache-hit 변경 방법
많은 분이 워드프레스 사이트를 만들 때 보통은 글자 수나 포스팅 개수에만 집착하긴 하지만, 내 집이 가장 편안해야 합니다. 최적화를 통해 사이트 속도를 높이고 접속 오류를 줄이는 것에는 큰 관심이 없는 분이 많지만 이 또한 멋진 컨텐츠를 만드는 기초 공사 과정입니다.
저사양 서버라고 해서 워드프레스를 포기할 필요는 없습니다. 이번 PHP-FPM 최적화를 통해 안정적인 블로그 운영의 기반을 다져보시건 어떨까요.
답글 남기기