Wireframe

라이트세일 인스턴스 업그레이드 및 설정

월 5천원 정도 하던 국내 호스팅 서비스를 쓰다가, 저장 공간의 압박이 너무 커서 여기 저기로 옮겨 다니다 라이트세일에 정착한 것이 대략 2018년이다. (그 전에 해외 호스팅을 사용해봤는데, 얘들은 처음 1년 혹은 몇 달은 저렴하게 프로모션하지만, 그 이후로 요금은… 흠..) 처음 2년반 넘게 사용하는 동안에는 불편함이 없었는데, 워드프레스가 버전업이 되면서 무거워져서 그런지 점점 느려진다는 느낌이 들었다. 또, 번거롭게 설치하는 일 없이 사용하려고 bitnami 인스턴스를 사용했는데, 문제는 bitnami 스택에서 php만 업그레이드한다거나 하는 것이 어려웠다.

그러던 차에 라이트세일 서울 리전이 오픈했다. (처음에는 도쿄 리전에 만들었음) 이 때부터 PHP 7을 쓰기 시작했는데, PHP 7은 더 무거워져서 페이지가 너무 늦게 로딩되거나 아예 다운되어 응답하지 못하는 경우가 생겼다. 캐시 플러그인을 쓴다거나 이런 저런 방법들을 취해봐도 별로 효과가 없었다. 워드 프레스의 모든 플러그인을 비활성화해봐도 별다른 소용이 없었기에, 플랜을 업그레이드하기로 결정했다.

플랜의 비교

호스팅 비용이 살짝 상승하긴 하지만, 월 $5짜리 플랜은 디스크 용량이나 메모리 용량이 $3.5짜리의 두 배이기 때문에 업그레이드하는 것이 그리 나쁘지 않겠다고 판단했다. 상위 플랜으로 이주하는 방법은 생각보다 무척 간편했다. 현재 사용중인 인스턴스의 스냅샷을 만들고, 이 스냅샷으로부터 새 인스턴스를 만들어주면 된다. 이전에 쓰여진 글들을 보면 이 방법은 동일 리전에서만 사용가능하다고 했는데, 2022년 2월 기준으로 이제는 리전이 달라도 스냅샷을 통한 이전이 가능하다.

이전 방법

스냅샷을 사용한 플랜 이정 방법은 간단하다. 서버 인스턴스에 대한 스냅샷을 작성하고, 이 스냅샷으로부터 새로운 인스턴스를 생성하되, 이 때 새로운 플랜을 선택하면 된다. 이렇게 인스턴스를 교체하면 그 내부의 내용은 그대로 보존된다. 이렇게 스냅샷을 이용해서 새 인스턴스를 만드는 방법은 이전에는 동일 리전에 대해서만 허용됐지만, 지금은 리전에 상관없이 사용할 수 있다.

인스턴스를 새로 생성한 후에, 내 도메인으로 새 인스턴스에 접속되게 하려면 이전에 사용하던 고정 IP를 새로운 인스턴스에 연결해주면 끝이다. 기존에 사용하던 인스턴스는 유지하고 있으면 꺼 두더라도 요금은 부과되기 때문에, 새로운 인스턴스의 작동에 문제가 없는 것이 확인되면 삭제한다.

먼저 아래와 같은 절차로 인스턴스를 생성한다.

  1. 현재 사용중인 인스턴스의 관리 화면으로 간다.
  2. 스냅샷 탭에서 새 스냅샷을 생성한다. 이 과정은 약간 시간이 걸리기 때문에 잠시 기다린다.
  3. 스냅샷 생성이 완료되면, 해당 스냅샷 항목의 오른쪽에서 메뉴를 열어 새 인스턴스를 만든다.
  4. (이제 리전을 옮길 수도 있다.) 리전 및 서버 종류와 플랜을 선택하고 새 인스턴스를 생성한다.

이 과정이 끝나면 만들어 놓은 스냅샷과 동일한 내용으로 인스턴스가 만들어진다. 하지만 기존 인스턴스로 서비스가 계속 운영되고 있기 때문에 새 인스턴스를 통해서 서비스가 제공되도록 네트워크 설정을 조정해야 한다. 기존에 생성해놓은 고정 IP 주소를 제거해서 새로 만들 필요 없이, 기존 고정 IP 주소가 새 인스턴스를 가리키도록 변경만 해주면 된다.

  1. 라이트 세일 홈으로 돌아가서 네트워킹 탭을 선택한다.
  2. 기존 인스턴스를 사용하던 리전 (내 경우는 서울) 아래에 고정 IP 주소 항목이 보인다. 메뉴를 열고 “관리”를 클릭하여 해당 IP에 대한 관리로 진입한다.
  3. 퍼블릭 고정 IP에 연결된 구 인스턴스가 표시된다. “분리”를 클릭하여 해당 고정 IP에서 구 인스턴스를 분리한다.
  4. 분리가 완료되면 다시 새 인스턴스를 선택해서 IP를 연결한다.

여기까지 해주고나면 모든 작업이 끝난다. 기존에 사용하던 인스턴스는 계속 유지하고 있으면 비용이 발생하므로 삭제해주면 된다. 그리고 기존 인스턴스에서 만들었던 스냅샷은 인스턴스를 삭제하더라도 계속 남아있게 되고, 스냅샷을 유지하는데에도 비용이 발생할 수 있으므로 홈의 스냅샷 탭에서 확인하고 사용하지 않을 스냅샷은 삭제해주면 된다.

서비스 상태 확인

인스턴스 사양을 업그레이드한 직후, 일단 심한 로딩 딜레이는 확실히 사라진 것 같았다. 이틀 정도 지나고 나서 자원 소모량을 살펴보았는데, 여전히 CPU 사용량이 높게 나와서 남은 CPU 버스트 용량이 별로 남아있질 않았다. 무슨 문제가 있는 것일가?

인스턴스에 접속하여 bitnami가 제공하는 로그 분석 도구를 사용해서 몇 가지 문제점을 확인해볼 수 있다. 브라우저의 원격 터미널 기능을 사용해서 서버에 접속해본다. 터미널에서 다음 명령을 실행하면 보조 도구를 실행할 수 있고, 여기서 서비스 상태 확인, 서비스 시작/중지 및 SSL 인증서 설치/갱신을 처리할 수 있다.

$ sudo /opt/bitnami/bnhelper-tool

이 도구는 서버 로그를 분석해서 문제의 소지가 있는 부분에 대해서 조언해준다. 나의 경우 아래와 같은 문제점을 보고했다.

  1. 가용 램이 부족하다.
  2. pagespeed 모듈 관련한 에러 로그가 많이 보인다.
  3. 특정 단일 IP에서 다량의 접근이 발생한다.
  4. php-fpm의 최대 동시 실행 수에 도달했다.

우선 가용램이 부족한 부분은 더 비싸고 좋은 플랜으로 가기보다는 지금 수준에서 최대한 뽑아 먹어야(?)할 것이기 때문에 넘어가도록 한다. 최소한 3.5불짜리 가장 저렴한 버전에서 겪던 응답을 못하는 수준은 벗어났기 때문에 딱히 변경은 하지 않을 것이다.

먼저 가용램이 부족한 것은 플랜의 문제이고, 당장은 메모리 부족으로 서버가 응답이 없거나 하는 상태에는 빠지지 않기 때문에 패스한다. 이 보다 더 상위 플랜의 비용을 감당하기에는 어렵다고 판단된다. php-fpm의 최대 동시 실행 수에 도달한 부분도 어쩔 수 없다고 생각한다. 서버의 설정을 변경하여 동시 실행 수를 늘릴 수는 있지만 그만큼 cpu 사용량이 증가하게 된다.

php-fpm의 최대 동시 실행 수에 도달했다는 것도 서버에 더 큰 부담을 주면서 동시 접속을 늘리는 것인데… 그만큼 CPU 사용량을 더 늘리게 될거라서 무시하기로 한다.

다음은 pagespeed 모듈이다. pagespeed 모듈은 아파치 서버의 설정을 자동으로 최적화하여 응답 속도를 크게 높여준다. 다만 경우에 따라서 CPU 사용량이 많아진다. 이 기능을 끄기로 결정한다.

Pagespeed 모듈 비활성화하기

Pagespeed 모듈을 끄기 위해서는 아파치 설정에서 해당 모듈을 활성화 하는 부분을 주석처리해준다. 먼저 아래 명령으로 아파치 설정 파일을 연다.

$ vim /opt/bitnami/apache2/conf/httpd.conf

pagespeed 를 검색해보면 아래 두 라인이 나오는데, 각 라인 앞에 “#”를 삽입해서 주석처리한 후 파일을 저장한다.

# Include conf/pagespeed.conf
# Include conf/pagespeed_libraries.conf
$ sudo /opt/bitnami/ctlscript.sh restart apache

아래 명령으로 아파치 서버를 재시작한다. PageSpeed 모듈이 비활성화 되었는지는 PC에서 curl 같은 명령으로 페이지를 가져와서 출력해본다. 헤더 내용에서 ‘X-Mod-Pagespeed: (모듈버전…)’ 이라는 항목이 없어졌다면 PageSpeed가 꺼진채로 작동하는 것이다.

봇 차단

뭔지 모르지만 봇으로 보이는 접속이 상당히 많고, 이들이 쓸데없이 서버에 부하를 주는 것 같으니 이 부분도 처리해자. bnsupport-tool 을 사용하여 진단했을 때, 각각의 문제에 대해 도움을 받을 수 있는 링크를 출력해서 보여주고 있으니 참고하면 된다.

https://docs.bitnami.com/bch/apps/moodle/troubleshooting/deny-connections-bots-apache/

우선 최근에 가장 많이 접근하는 ip는 무엇인지 확인해본다. 다음 명령은 웹서버 로그로부터 ip만 추출하여 개수가 많은 순으로 정렬하여 표시해준다.

$ cd /opt/bitnami/apache2/logs/$ tail -n 10000 access_log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 10

이렇게 나오는 ip 중에서 일반 사용자 및 구글 크롤러 등을 제외하고 의심스러운 접속을 차단하자. 추출한 상위 로그를 실제 액세스 로그에서 찾아보았을 때 일정한 시간 간격으로 접근하고 있다던지 하면 봇으로 의심할 수 있다.

구글 크롤러의 경우, host 명령으로 ip에 해당하는 호스트를 찾으면 도메인 이름에 googlebot 이라는 단어가 포함된다. 다시 해당 도메인을 host 명령에 넘겨서 원래의 ip가 나오면 구글 크롤러로 판단할 수 있다. 특정 IP의 워드프레스 접근을 막기 위해서는 /opt/bitnami/apps/wordpress/conf/httpd-app.conf 파일에서 차단할 IP를 등록해준다.

<Directory "/opt/bitnami/apps/wordpress/htdocs">
    Options +MultiViews +FollowSymLinks
   
    # 특정 IP 차단
    deny from 138.201.192.8
    deny from 207.180.201.192
    deny from 216.244.66.230
    deny from 65.21.232.254
    deny from 85.10.199.185

편집을 마쳤으면 아파치 설정 파일에 오류가 없는지 확인하고 아파치를 재시작하면 된다.

$ apachectl -t
Syntax OK    
$ sudo /opt/bitnami/ctlscript.sh restart apache

이정도 작업을 해주고나니 CPU 사용량이 제법 안정되고 블로그 로딩도 제법 안정적으로 이뤄지는 것처럼 보인다. 조금 더 빠른 로딩 및 서버 부하를 더 줄이고 싶은 경우에는 WPSuperCache 플러그인에 대한 설정을 손봐야 할 것인데, 이 내용은 다음 기회에 다뤄보도록 하겠다.

Exit mobile version