AWS Lightsail의 1GB RAM 서버에서 워드프레스를 운영하며 겪었던 스왑 사용량 문제와 해결 과정을 정리한 글입니다. 과도한 스왑 사용으로 인한 블로그 속도 저하를 개선하기 위한 실전 최적화 방법을 공유합니다.
서버 상태 진단: 스왑 사용량이 너무 많다
우분투 22.04 서버에서 free -m 명령어로 메모리 상태를 확인했을 때 스왑 사용량이 541MB(총 1024MB)에 달했습니다. RAM은 914MB 중 588MB(64.3%)가 사용 중이었고, 그중 MySQL(mysqld)이 781MB를 차지하고 있었습니다. 이는 1GB RAM 서버에서는 지나치게 많은 메모리를 사용하는 상황이었습니다.
블로그 로딩 속도 저하, 사용자 경험 악화는 물론 서버의 전반적인 응답성 저하로 직결되는 문제였습니다. 목표는 스왑 사용량을 100MB 이하로 줄이는 것이었습니다.
MySQL 메모리 사용량 최적화
MySQL 설정 파일 수정
가장 먼저 메모리를 가장 많이 소비하고 있던 MySQL 설정을 살펴보았습니다. /etc/mysql/mysql.conf.d/mysqld.cnf 파일을 열어보니 다음과 같은 문제점을 발견했습니다:
- innodb_buffer_pool_size가 128MB로 설정
- max_connections가 151로 과도하게 설정
- 기타 메모리 관련 설정이 1GB RAM 서버에는 과한 값으로 설정
설정 파일을 다음과 같이 수정했습니다:
[mysqld]
user=mysql
bind-address=127.0.0.1
mysqlx-bind-address=127.0.0.1
key_buffer_size=16M
myisam-recover-options=BACKUP
log_error=/var/log/mysql/error.log
max_binlog_size=100M
socket=/var/run/mysqld/mysqld.sock
pid-file=/var/run/mysqld/mysqld.pid
innodb_buffer_pool_size=64M # 128MB → 64MB
max_connections=30 # 151 → 30
tmp_table_size=8M # 16MB → 8MB
max_heap_table_size=8M
MySQL 재시작 및 오류 해결
설정을 저장하고 MySQL을 재시작(sudo systemctl restart mysql)했으나 처음에는 오류가 발생했습니다. 에러 로그(/var/log/mysql/error.log)를 확인해보니 query_cache_size=0 설정이 문제였습니다. MySQL 8.0에서는 query_cache 기능이 완전히 제거되어 더 이상 지원되지 않는 설정이었습니다. 해당 설정을 제거하고 다시 재시작하니 정상적으로 MySQL이 구동되었습니다.
결과 확인
MySQL 설정 변경 후 데이터베이스에 접속하여 설정 값을 확인했습니다:
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # 67108864 (64MB)
SHOW VARIABLES LIKE 'max_connections'; # 30
SHOW VARIABLES LIKE 'tmp_table_size'; # 8388608 (8MB)
htop 명령어로 시스템 리소스 사용량을 모니터링해보니 MySQL 메모리 사용량이 781MB에서 369.4MB로 대폭 감소했습니다. 스왑 사용량도 541MB에서 314MB로 줄었지만, 목표인 100MB 이하에는 아직 도달하지 못했습니다.
PHP-FPM 설치 및 최적화
PHP-FPM 설치
PHP 설정도 메모리 사용량에 영향을 미친다는 점에 착안하여 PHP-FPM을 설치했습니다. php -v 명령어로 확인한 결과 PHP 버전은 8.1.2였으며, 다음 명령어로 PHP-FPM을 설치했습니다:
sudo apt install php8.1-fpm
PHP-FPM 설정 최적화
PHP-FPM 설정 파일(/etc/php/8.1/fpm/php.ini)에서 memory_limit을 128M에서 64M으로 줄이고, 풀 설정(/etc/php/8.1/fpm/pool.d/www.conf)도 다음과 같이 최적화했습니다:
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
이후 PHP-FPM을 재시작(sudo systemctl restart php8.1-fpm)하니 PHP 프로세스의 메모리 사용량이 최적화되기 시작했습니다.
웹 서버 연동
Apache 웹 서버를 사용 중이었기 때문에 mod_php를 비활성화하고 PHP-FPM을 연동했습니다:
sudo a2dismod php8.1
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.1-fpm
sudo systemctl restart apache2
이 변경 후 PHP 요청이 PHP-FPM을 통해 처리되면서 메모리 사용량이 추가로 감소했습니다.
워드프레스 최적화
플러그인 정리
워드프레스 대시보드에서 불필요한 플러그인을 비활성화했습니다. 특히 다음과 같은 플러그인이 메모리를 많이 사용하는 것으로 파악되었습니다:
- 사용하지 않는 백업 플러그인
- 테마 편집기
- 실시간 통계 플러그인
- 기타 활성화되어 있지만 사용하지 않는 플러그인
캐싱 플러그인 설정
LiteSpeed Cache 플러그인을 설치하고 다음 기능을 활성화했습니다:
- 페이지 캐싱
- CSS/JS 최소화
- 이미지 지연 로드
- 브라우저 캐싱
- GZIP 압축
이 설정으로 블로그 로딩 속도가 크게 향상되었습니다.
이미지 최적화
이미지 압축 플러그인(Smush)을 설치하여 다음과 같은 최적화를 적용했습니다:
- 기존 이미지 일괄 압축
- 새 이미지 업로드 시 자동 최적화
- WebP 변환 활성화
- 이미지 크기 조정
이미지 최적화 후 페이지 로딩 속도가 추가로 개선되었습니다.
성능 향상 결과
메모리 사용량 개선
모든 최적화 작업 후 htop으로 확인한 메모리 사용량은 다음과 같이 변경되었습니다:
- MySQL 메모리 사용량: 781MB → 310MB
- PHP-FPM 메모리 사용량: 약 60-90MB (5개 프로세스)
- RAM 사용량: 609MB → 550MB (약 10% 감소)
- 스왑 사용량: 541MB → 200MB
목표인 스왑 사용량 100MB 이하에는 미치지 못했지만, 초기 상태보다 크게 개선되었습니다.
성능 테스트 결과
Google PageSpeed Insights로 블로그 속도를 측정한 결과:
- 데스크톱: 85점 → 92점
- 모바일: 65점 → 75점
실제 사용자 경험 측면에서도 페이지 로딩 시간이 평균 3초 이내로 줄어들어 체감 속도가 크게 향상되었습니다.
추가 최적화 방안
데이터베이스 최적화
워드프레스 데이터베이스 테이블을 최적화하면 추가 성능 향상을 기대할 수 있습니다. phpMyAdmin이나 WP-CLI를 사용하여 다음과 같은 작업을 수행할 수 있습니다:
wp db optimize
또는 SQL 명령어를 직접 실행:
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;
자동화된 데이터베이스 정리
WP-Cron을 활용하여 주기적으로 데이터베이스를 정리하도록 설정할 수 있습니다. 특히 다음과 같은 데이터를 정리하면 도움이 됩니다:
- 오래된 리비전
- 스팸 댓글
- 휴지통 항목
- 트랜잭션 로그
CDN 활용
컨텐츠 전송 네트워크(CDN)를 활용하면 서버 부하를 줄이고 전 세계 사용자에게 더 빠른 접속 속도를 제공할 수 있습니다. Cloudflare와 같은 무료 CDN 서비스를 활용하는 것도 좋은 방법입니다.
결론
1GB RAM의 제한된 환경에서 워드프레스를 최적화하는 작업은 어려운 도전이었지만, 단계적인 접근으로 상당한 성능 향상을 이룰 수 있었습니다. MySQL과 PHP-FPM 설정 최적화만으로도 스왑 사용량을 크게 줄이고 블로그 속도를 향상시킬 수 있었습니다.
다만 1GB RAM의 물리적 한계는 분명히 존재하며, 블로그 트래픽이 증가하거나 더 많은 기능을 추가할 경우 AWS Lightsail 2GB RAM 플랜(월 $10)으로의 업그레이드를 고려해볼 만합니다.
이 최적화 과정이 비슷한 환경에서 워드프레스를 운영하는 다른 개발자들에게 도움이 되길 바랍니다. 소규모 블로그라도 최적화를 통해 전문적인 수준의 속도와 안정성을 확보할 수 있다는 점을 기억하시기 바랍니다.