VPS 호스팅 요금 내 사이트에 맞게 계산하는 방법

얼마 전 월 방문자 2만 명인 블로그를 옮기면서 서버 비용을 다시 계산했다. 운영자는 접속자가 늘었다는 이유로 메모리 8GB 요금제를 보고 있었지만, 기존 서버의 메모리 사용량은 평소 1GB도 되지 않았다. VPS 호스팅 요금은 방문자 수 하나로 고르면 쉽게 과해진다. 전송량, 접속이 몰리는 시간, 백업 비용을 따로 계산해야 한다.

월 방문자보다 전송량부터 계산한다

첫 번째 숫자는 한 달에 서버에서 밖으로 나가는 데이터다. 페이지 한 번을 여는 데 전송되는 용량에 월 페이지 조회 수를 곱하면 출발점이 나온다. 예를 들어 페이지당 2MB이고 하루 1,000페이지가 열린다면 2MB × 1,000 × 30일, 약 60GB다. 방문자 수가 아니라 페이지 조회 수를 넣어야 한다. 한 사람이 글 세 개를 읽으면 세 번 전송하기 때문이다.

이미지가 무겁거나 파일 다운로드가 많으면 숫자가 금방 달라진다. 20MB짜리 자료를 한 달에 5,000번 내려받으면 그것만 약 100GB다. 반대로 이미지와 정적 파일을 별도 저장소나 CDN에서 보내면 VPS의 전송량은 줄어든다. 서버 관리 화면에서 최근 30일의 실제 송신량을 먼저 확인하고, 이전할 사이트라면 예상치에 여유를 붙이는 편이 정확하다.

요금표의 ‘트래픽 1TB’가 무조건 같은 조건도 아니다. 포함량이 송신 기준인지, 송수신 합계인지, 초과분에 얼마를 받는지 확인해야 한다. 아마존 라이트세일은 송수신 데이터가 제공량 계산에 들어가고, 초과 요금은 조건에 따라 송신 데이터에 붙는다. 숫자 하나만 비교하면 예상 청구액을 잘못 잡기 쉽다.

접속이 몰릴 때 필요한 CPU와 메모리를 본다

월 60GB를 쓰는 두 사이트라도 필요한 서버는 다를 수 있다. 하루 종일 고르게 읽히는 정적 블로그와, 점심시간에 로그인 사용자가 몰리는 예약 사이트는 처리 방식이 다르다. 전자는 캐시가 대부분의 요청을 받지만, 후자는 매번 애플리케이션과 데이터베이스가 일할 수 있다.

동시접속자라는 말도 그대로 CPU 사용량을 뜻하지는 않는다. 페이지를 읽으며 머무는 사람과 서버가 요청을 처리 중인 사람은 다르다. 접속이 가장 많은 한 시간의 요청 수, 캐시 적중률, 응답 시간, CPU 사용률을 함께 봐야 한다. 특히 평소 CPU는 한가한데 접속이 몰릴 때 응답 시간이 튄다면 그때의 요청과 데이터베이스 작업을 확인한다.

• 정적 페이지 중심의 작은 사이트라면 공유 웹호스팅이나 무료 구간으로도 충분할 수 있다.
• 워드프레스 한 곳을 직접 운영한다면 1 vCPU와 메모리 1GB를 출발점으로 삼되, 플러그인과 데이터베이스가 함께 돌아갈 때 메모리 부족 여부를 확인한다.
• 관리 화면 작업, 검색, 예약처럼 동적 요청이 잦다면 메모리 2GB 이상에서 시작해 실제 CPU와 응답 시간을 보고 조정한다.

이 숫자는 구매 기준이 아니라 첫 측정 지점이다. 메모리 1GB 서버에서 운영체제, 웹서버, 데이터베이스를 모두 돌리면 여유가 작을 수 있다. 메모리 부족으로 프로세스가 종료됐는데 방문자 증가 탓으로 판단하면 요금제만 올리고 원인은 남는다.

표시된 월 요금에 빠진 항목을 더한다

공개 요금표를 보면 디지털오션의 기본 VPS는 메모리 1GB가 월 6달러, 2GB가 월 12달러, 4GB가 월 24달러다. 각 요금제의 포함 전송량과 저장 공간도 다르다. 가격은 바뀔 수 있으니 결제 직전에는 같은 지역과 같은 CPU 종류를 선택했는지 확인해야 한다. 서로 다른 조건의 최저가를 나란히 놓으면 비교가 안 된다.

실제 월 비용은 서버 기본료에 백업, 추가 저장 공간, 전송량 초과분, 필요하면 관리 비용을 더한 값이다. 디지털오션은 자동 백업을 서버 비용의 일정 비율로 별도 청구한다. 월 6달러 서버가 운영비까지 6달러라는 뜻은 아니다. 부가세와 환율도 원화 청구액에 영향을 준다.

시간 단위 과금도 헷갈리는 지점이다. 서버를 잠깐 만들었다 지우면 사용 시간만큼 청구될 수 있지만, 계속 켜 두는 운영 서버는 월 상한액을 기준으로 예산을 잡는 게 편하다. 중지한 서버의 과금 여부는 서비스마다 다르다. 라이트세일은 인스턴스를 중지해도 삭제하기 전까지 요금이 발생한다.

백업과 복구 시간을 요금표 옆에 적는다

서버 운영을 하면서 가장 비싸게 치른 건 대개 월 요금 차이가 아니라 복구 실패였다. 스냅샷 하나만 켜 놓고 안심하기 쉽지만, 데이터베이스가 계속 쓰이는 중에 찍은 이미지가 원하는 시점까지 복구되는지는 별개다. 파일과 데이터베이스를 어떻게 백업할지, 며칠 보관할지, 서버와 다른 위치에 둘지 정해야 한다.

저는 최소한 백업 주기와 허용 가능한 데이터 손실 시간을 먼저 적는다. 하루치 글을 잃어도 된다면 매일 백업이 출발점이지만, 주문이나 예약을 받는다면 그 간격은 길 수 있다. 그리고 새 서버에 한 번 복원해 본다. 백업 파일이 있다는 사실보다 복원에 몇 분이 걸리고 무엇이 빠졌는지가 운영에는 더 중요하다.

처음부터 큰 사양을 사기보다 작은 요금제로 시작해 CPU, 메모리, 디스크 사용량과 응답 시간을 며칠 관찰하는 편이 낫다. 다만 백업 비용은 처음부터 예산에 넣는다. 서버 사양은 필요할 때 올릴 수 있어도, 장애가 난 뒤에 지난 데이터의 백업을 만들 수는 없다.