VPS 사양을 트래픽에 맞춰 고르는 방법

얼마 전 사이트가 느려졌다며 VPS를 두 배 큰 요금제로 올린 운영자를 만났다. 접속자는 많지 않았다. 원인은 메모리 부족이 아니라 매 요청마다 실행되는 느린 데이터베이스 조회였다. 서버를 키우기 전에 트래픽과 병목을 따로 봐야 하는 이유다.

월 방문자보다 바쁜 시간의 요청을 본다

월간 페이지뷰만으로 CPU를 고르면 대개 사양이 커진다. 예를 들어 월 30만 페이지뷰는 한 달 평균으로 환산하면 초당 약 0.12페이지다. 바쁜 시간에 평균의 30배가 몰려도 초당 약 3.5페이지다. 물론 한 페이지가 이미지와 스크립트 여러 개를 불러오고, 로그인이나 검색처럼 서버가 직접 처리하는 요청도 있다. 그래서 페이지뷰와 서버가 처리한 요청 수는 구분해야 한다.

먼저 최근 1~2주의 접속 기록에서 가장 바쁜 5분의 초당 요청 수를 확인한다. 그 시간대의 응답 시간, CPU 사용률, 메모리 여유, 데이터베이스 조회 시간도 함께 본다. 동시 처리량은 대략 ‘초당 요청 수 × 요청 처리 시간’이다. 초당 20건을 처리하고 한 건이 평균 0.5초 걸리면 동시에 처리 중인 요청은 약 10건이다. 같은 20건이라도 처리 시간이 2초로 늘면 40건이 쌓인다.

트래픽보다 페이지 무게가 먼저 비용을 만드는 경우도 많다. 한 페이지를 보는 데 서버에서 평균 1MB를 내려보내고 월 30만 페이지뷰가 발생하면 전송량은 단순 계산으로 약 300GB다. 캐시와 이미지 외부 저장 여부에 따라 실제 VPS 전송량은 달라진다. 요금제를 비교할 때는 CPU와 메모리뿐 아니라 월 전송량 한도와 초과 과금 방식도 확인해야 한다.

처음 VPS를 고를 때는 메모리부터 계산한다

캐시가 잘 적용된 소규모 블로그라면 1~2개 가상 CPU와 2GB 메모리를 출발점으로 잡을 수 있다. 웹서버, 애플리케이션, 데이터베이스를 한 VPS에 함께 두고 동적 요청이 많다면 4GB부터 검토하는 편이 운영하기 수월하다. 이 숫자는 보장 사양이 아니다. 애플리케이션 종류와 플러그인, 데이터베이스 크기에 따라 차이가 크다.

메모리 계산에는 운영체제와 웹서버만 넣으면 안 된다. 애플리케이션 작업 프로세스, 데이터베이스 버퍼, 배포 중 잠깐 늘어나는 사용량까지 합쳐야 한다. 평소 메모리가 거의 꽉 차고 스왑 입출력이 계속 발생한다면 증설 근거가 된다. 반대로 메모리 여유가 충분한데 특정 페이지에서만 CPU가 치솟는다면 쿼리와 캐시부터 확인한다. 사용률 한 번이 높았다는 이유만으로 상위 요금제로 옮길 필요는 없다.

디스크도 용량과 성능을 나눠 본다. 이미지 20GB와 데이터베이스 20GB는 같은 공간을 쓰지만 디스크에 주는 부담은 다르다. 데이터베이스 응답이 느릴 때는 저장 공간이 남았는지만 보지 말고 디스크 대기 시간과 입출력 지연을 확인한다. 로그가 계속 쌓여 디스크가 가득 차는 사고는 비싼 VPS에서도 똑같이 난다.

이전할 때는 백업 복원과 되돌리는 순서를 먼저 적는다

서버 이전은 파일을 복사하는 작업으로 끝나지 않는다. 데이터베이스를 어느 시점에 멈추거나 동기화할지, 업로드 파일은 언제 복사할지, 새 서버에서 인증서와 예약 작업이 정상 동작하는지 정해야 한다. 쓰기가 계속 발생하는 사이트라면 파일과 데이터베이스 백업 시점이 어긋나지 않도록 특히 주의한다.

작업 전에는 기존 서버의 파일, 데이터베이스, 설정을 각각 백업하고 새 환경에서 실제로 복원해 본다. 백업 파일이 있다는 사실과 복원이 된다는 사실은 다르다. 백업은 VPS 내부 저장소와 별도 위치에도 보관한다. 같은 서버가 지워지면 그 안의 백업도 함께 사라진다. 자동 스냅샷이 있더라도 보관 기간과 복원 범위를 확인해야 한다.

전환 직전에는 도메인 설정의 갱신 주기를 확인하고, 새 서버에서 주요 페이지와 로그인·결제·문의 같은 쓰기 기능을 점검한다. 전환 뒤에는 접속 기록과 오류 기록을 보며 구 서버로 들어오는 요청이 남아 있는지 살핀다. 문제가 생겼을 때 어느 시점까지 이전 서버로 되돌릴 수 있는지도 미리 정해 둔다. 데이터가 새 서버에만 쌓인 뒤에는 단순히 연결 대상을 되돌리는 것만으로 해결되지 않는다.

장애가 나면 접속 경로를 따라 좁혀 간다

사이트가 열리지 않을 때 곧바로 재부팅하면 원인을 찾을 기록을 놓치기 쉽다. 먼저 내 접속 환경만의 문제인지, 여러 위치에서 같은 증상인지 확인한다. 다음으로 도메인 연결, 서버 접속, 웹서버 상태, 애플리케이션 오류, 데이터베이스 연결 순서로 범위를 좁힌다. 화면에 표시되는 오류와 서버 기록의 발생 시각을 맞춰 보면 단서가 빨리 나온다.

연결 자체가 안 되면 도메인 설정, 방화벽, 서버 상태와 네트워크를 확인한다.
연결은 되는데 오류 화면이 나오면 웹서버와 애플리케이션 오류 기록을 본다.
일부 페이지만 느리면 해당 요청의 처리 시간과 데이터베이스 조회를 확인한다.
갑자기 전체가 느려졌다면 CPU, 메모리, 디스크 여유와 최근 배포 내역을 함께 본다.

저가 VPS로 충분한 구간은 생각보다 넓다. 다만 싼 서버를 안정적으로 쓰려면 사용량을 기록하고, 백업을 복원해 보고, 장애 때 확인할 순서를 갖춰야 한다. 사양을 올리는 건 그 기록에서 자원이 실제 병목으로 드러났을 때가 맞다.