워드프레스 서버에서 갑자기 CPU 점유율이 급상승 할때 해결법 및 대처 과정
느닷없이 코드도사 사이트가 접속이 되지 않았다
일주일 전부터 그동안 잘 접속이 되던 “코드도사” 사이트가 접속이 불가한걸 알게 되었습니다.
그 이유는 바로 제가 사용하는 클라우드 서버인 “AWS 라이트세일” 이 1차 적인 문제였습니다. CPU가 주기적으로 점유율이 치솟는 바람에 CPU 버스트용량이 지속적으로 줄어든게 된 것이지요. AWS 라이트세일은 대용량의 사이트가 아닌 중소규모의 사이트에 적절한 리소스가 그리 크지 않고 제한적인 클라우드 서버입니다.
위 링크 글에서 언급한 것처럼 라이트세일의 한계를 깨닫고 나서 되도록 웹서버에 무리가 가지 않게 최소한의 자원으로 잘 운영을 하고 있었습니다. 코드도사 사이트는 라이트세일에 워드프레스를 사용하여 운영중이기 때문에 불필요한 플러그인을 줄이고 최대한 가볍게 사용중이었습니다.
3년전에 라이트세일 인스턴스 사양을 한단계 올린 뒤로 지금까지 큰 문제없이 운영중이었지만 갑자기 CPU 점유율이 높아진게 매우 이상했습니다. 글의 갯수가 갑자기 많이 늘어났다거나 트래픽이 폭증하거나 한 적이 없었기 때문이지요.
뚜렷한 원인을 찾지 못한 채 일단 줄어드는 CPU 버스트 용량을 보면서 지속적인 모니터링을 시작하게 되었습니다. 그런데 큰 이유 없이 CPU 점유율이 갑자기 100%로 치솟았다가 떨어지기를 반복했습니다. 이러다보니 “CPU 버스트 용량”이 지속적으로 줄어들었던 겁니다.
CPU 점유율이 갑자기 치솟은 원인을 알아내기 위해서 장장 일주일 이상을 라이트세일 서버를 모니터링 하면서 겨우 원인을 찾았습니다. 찾고 보니 이게 단순히 한가지가 아닌 여러 요소들이 복합적인거 같네요. 그 중에서 가장 큰원인은 “특정 IP 대역의 공격” 이었던거 같습니다.
이번 글에서는 저와 같이 워드프레스를 라이트세일로 운영하면서 겪은 “CPU 점유율이 갑자기 치솟는 문제” 에 대해 대처 방법과 과정을 기술해 볼까 합니다.
일단 플러그인을 의심하였다
가장 먼저 의심한 건 “플러그인” 이었습니다. 워드프레스는 다양한 플러그인을 통해 사용자가 원하는 기능을 다양하게 제공하는데 제가 사용하는 플러그인중에 혹시 “시스템 리소스”를 잡아먹는 플러그인이 있지 않을까? 라는 생각을 했습니다.
검색과 AI 비서 등을 통해 알아보니 워드프레스의 리소스는 간혹 “플러그인”이 잡아 먹는다고 하더군요. 그러나 사실 코드도사의 워드프레스는 특별한 플러그인을 사용하지 않아서 과연 플러그인일까? 했지만 일단 사용중인 플러그인을 살펴보기로 했습니다.
그 중에서 가장 의심스러웠던 게 바로 “WP Statistics” 라는 플러그인이었습니다. 그 이유는 의심가는 플러그인들을 전부 비활성 해놓은 상태에서 WP Statistics 만 켜놓으면 유독 CPU 점유를 많이 하는거 같이 보였기 때문이지요.
또한 WP Statistics 를 의심한 이유는 바로 “Slow 쿼리” 를 추적하였는데 거기에 찍힌 로그들이 WP Statistics 관련 테이블 조회 중에 발생한 겁니다. Slow 쿼리를 추적하는 방법은 다음과 같습니다.
# sudo vi /opt/bitnami/mariadb/conf/my.conf 파일을 연다. [mysqld] ... 중략 slow_query_log=0 # 이걸 1로 바꿔줌 slow_query_log_file=/var/log/mysql/mariadb-slow.log # 별도의 로그파일 생성 경로 기입 slow_query_time=1.0 # 기본값은 10초이지만 1초로 변경해줌. # 수정하고 저장하고 빠져나온뒤 서비스 재시작 # sudo /opt/bitnami/ctlscript.sh restart
위의 과정으로 하면 Slow 쿼리를 활성화 하는게 가능합니다. 여기서 찍힌 로그들이 “WP Statistics” 플러그인을 의심하게 하더군요.
그 중에서 쿼리시 가장 많이 찍힌 DB 테이블이 바로 “wp_statistics_search” 이었습니다. 특히 여기에 통계 데이터들이 꽤 저장되어 있더군요.
관련하여 WP Statistics 가 CPU 점유율에 미치는 영향을 알아보니 상당히 워드프레스 운영자들이 데이터가 너무 쌓이면 영향을 미치는거 같아 보입니다.
WP Statistics 가 내 워드프레스로 방문하는 방문객들의 통계 데이터를 저장하는 용도이기 때문에 시간이 지나면 데이터가 내 워드프레스 DB 에 끊임없이 쌓이게 됩니다. 그래서 워드프레스 공식 홈에서도 “Index WP MySQL For Speed” 와 같은 플러그인을 통해 WP Statistics 의 데이터를 최적화 시키는 작업을 권장하는거 같습니다.
일단 위의 링크에서처럼 “Index WP MySQL For Speed” 플러그인을 설치해서 고성능 키를 추가했습니다. 이렇게 하면 DB의 쿼리 처리가 더 빨라진다고 해서 말이지요.
이렇게 한 다음에 WP Statistics 플러그인을 최신 버전으로 업데이트 한 후 그동안 쌓인 데이터를 죄다 삭제하기로 했습니다. 아무래도 쌓인 통계 데이터가 영향을 미칠 걸 염려해서 말이지요.
그래서 제 라이트세일의 phpmyadmin 을 이용해 통계 데이터를 죄다 삭제 했습니다. 라이트세일에서 phpmyadmin 접속 방법은 위 링크 글의 블로거가 아주 잘 정리를 해줬군요.
이렇게 한 뒤에 CPU 점유율 추이를 다시 모니터링 해봤습니다.
다행이도 WP Statistics 플러그인 최적화 이후 뭔가 CPU 점유율이 떨어지는 걸로 보였습니다. 그러나…. 오래 못가더군요.
이후 한 최적화 조치들
WP Statistics 플러그인을 의심했으나 이거 다가 아니었던거 같습니다. 통계 데이터가 많이 쌓여있던건 사실이나 또다른 CPU 점유 원인이 있는거 같네요.
그래서 몇가지 최적화 작업을 한게 있습니다.
- 워드프레스 버전을 최신으로 업데이트 (5.X.X.X 에서 6.8.2 로 업데이트 함)
- 불필요한 플러그인 전부 비활성화(특히 구글 폰트도 비활성 처리)
- 라이트세일의 bitnami 서버에서 스왑(swap) 파일 생성
최적화 작업중에 가장 먼저 한게 “워드프레스를 최신 버전으로 업데이트”를 한겁니다. 기존에 사용하던 버전이 5.9.X 버전이었는데 기존에 저장되어 있던 “코드도사” 사이트의 데이터를 전부 백업한 다음에 혹여나 발생할지 모르는 “버전충돌”로 사이트가 먹통 되는걸 감안하게 과감하게 업데이트를 하기로 했습니다.
워드프레스를 최신으로 업데이트를 하는것도 도움이 되겠다 생각을 했지요.
워드프레스 데이터 백업은 위 링크와 같이 “UpdraftPlus” 라는 플러그인을 사용했습니다. 제가 사용해본 데이터 백업 플러그인 중에서는 제일 쓸만한거 같네요.
저처럼 운영중인 워드프레스의 최적화 작업을 하기 전에는 반드시 “백업”을 받아놓는게 좋습니다.
백업을 하고 “워드프레스”를 최신버전으로 업데이트 하였는데 다행이도 별다른 충돌 문제는 일어나지 않았습니다.
워드프레스를 6.8.2(최신버전) 으로 업데이트 하였지만…. 여전히 CPU 점유율을 둘쭉 날쭉 했습니다.
다음으로 코드도사 사이트에서 사용하던 “구글폰트” 로 전부 비활성화 처리를 하였습니다. 확실히 접속 속도가 빨라진걸 느낍니다. 요놈도 꽤나 리소스를 차지하고 있었던거 같습니다. 그 외에 불필요한 플러그인은 죄다 비활성화 처리를 했습니다.
그럼에도 CPU 점유율은 생각만큼 줄어들지 않았습니다. 평상시에 1~3% 사이였던 점유율이 최소 10%~100% 까지 순간적으로 치고 올라가는 패턴이 반복적이더군요. 이제는 현재 상태의 인스턴스(1 GB 메모리/40 GB 용량)는 더이상 견디기 어렵나? 라는 생각이 들어서 업그레이드를 해볼까? 라는 생각이 들었습니다.
하지만 다른 동일한 인스턴스의 워드프레스에서 아무 이상이 없는걸 보고 다시 한번 원인을 찾아보기로 했습니다. 혹여나 하는 마음에 1 GB 의 부족한 메모리를 보완하려고 하드디스크를 메모리 같이 사용하는 스왑(SWAP) 파일을 만들어 봤습니다.
# 1) SWAP 파일 생성 # 아래 명령어는 swapfile이라는 이름으로 2GB 크기의 파일을 생성. bs는 블록 크기, count는 블록 수를 의미, 따라서 2048 x 1M = 2G. sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 # 2) SWAP 파일 권한 설정 # SWAP 파일은 보안을 위해 소유자(root)만 읽고 쓸 수 있도록 권한을 설정. sudo chmod 600 /swapfile # 3) SWAP 활성 # 생성한 파일을 SWAP 영역으로 설정하고 활성. sudo mkswap /swapfile sudo swapon /swapfile
위 과정으로 스왑파일을 생성했지만… CPU 점유율은 여전히 줄어들지 않았습니다.
이 상태에서 “WP Statistics” 플러그인의 활성화하고 다시 모니터링을 해보기로 했습니다.
범인은 코드도사 사이트에 들어오는 공격 패킷과 봇
거의 일주일 동안 모니터링을 해도 뚜렷한 원인을 찾지 못했지만 이런 저런 검색을 하고 알아본 결과 혹시나 하는 마음에 “WP Statistics” 에 찍히는 IP 들을 관찰해 보기로 했습니다.
자주 접속하는 사용자들을 보니 놀랍게도 “34.174.x.x” IP 들이 제일 많았습니다. 그런데 이 IP 들 중에 특정 IP 들이 들어올때마다 CPU 점유율이 갑자기 치솟는 걸 발견하게 되었네요.
이 IP 들 몇몇을 알아보니 놀랍게도 “구글 클라우드” 의 IP 들 입니다. 설마 이 IP 들이 공격하는게 아닐까? 의심을 하게 되었지요. AI 들에게 물어보니 구글 계열 IP 지만 크롤링이나 봇 등의 공격 IP 일 가능성도 있다고 했습니다.
결국 특정 IP 들의 크롤링이나 봇 공격등이 CPU 점유율을 치솟게 하는 원인이었네요. 해당 IP 들이 주요 검색 엔진들의 크롤링 봇이 아닐까 했지만 검색 엔진들의 봇이 이렇게 과도하게 접속하는건 아닐거라는 판단입니다.
이 IP 들을 막아야 겠군요. 라이트세일의 워드프레스 서버는 bitnami 로 되어 있는데 리눅스 기반입니다. IP 들을 차단할 수 있는 확실한 수단인 “iptables” 로 처리하면 됩니다.
sudo iptables -A INPUT -s 34.174.0.0/16 -j DROP
처음에는 몇몇 IP 들만을 차단했으나 지속적인 공격이 들어오는거 같아서 아예 34.174.x.x 를 전부 차단하였습니다. 그랬더니… 드디어 CPU 점유율이 급격이 줄어들고 CPU 버스트 용량도 100%로 회복이 되었습니다. 무려 일주일 넘게 모니터링 한 결과네요.
이후에 접속 통계 정보를 확인하려고 다시 “WP Statistics” 를 활성화 하였는데 요걸 켜고 나서 다시 CPU 점유율이 조금씩 올라가는 걸 보고 이참에 아예 비활성화 하기로 했습니다. 이 플러그인의 영향이 아예 없던 것도 아니었네요.
결론적으로 취한 조치는 이렇습니다.
iptables 로 IP 대역 차단 + WP Statistics 플러그인 비활성화
이후에는 CPU 점유율이 5% 이하로 안정적이고 CPU 버스트 용량도 100%로 회복이 되었습니다. 덕분에 코드도사 사이트 접속도 빨라졌네요.
혹시 저와 같은 사례를 겪으면 분들은 참고가 되셨으면 합니다.