홈페이지 서버 사양을 계산해 고르는 방법

얼마 전 월 방문자가 3천 명인 홈페이지에 고사양 VPS를 쓰고 있다는 이야기를 들었다. 막상 접속이 느린 이유는 서버 성능이 아니라 첫 화면에 올라간 8MB짜리 이미지였다. 홈페이지를 운영할 때는 요금제 이름보다 페이지 무게, 월간 조회 수, 접속이 몰리는 시간을 먼저 봐야 한다.

월 트래픽은 페이지 무게부터 계산한다

브라우저에서 첫 화면을 열고 개발자 도구의 네트워크 항목을 보면 내려받은 데이터 양을 확인할 수 있다. 이미지와 글꼴까지 포함해 한 페이지가 1.5MB이고 월 조회 수가 3만 회라면 전송량은 약 45GB다. 여기에 관리자 작업, 검색 로봇, 재방문 때 달라지는 파일을 감안해 30% 정도 여유를 두면 월 60GB 안팎을 출발점으로 잡을 수 있다.

같은 3만 회라도 페이지가 5MB면 계산값이 150GB로 뛴다. 이때 서버를 올리기 전에 이미지 크기와 압축 설정을 손보는 편이 대개 싸고 빠르다. 다만 호스팅 업체의 트래픽 집계 방식은 서로 다르다. 월 제공량뿐 아니라 초과 시 과금되는지, 속도가 제한되는지도 확인해야 한다.

월 조회 수만으로 CPU를 고르면 또 빗나간다. 3만 회를 30일로 나누면 평균은 분당 1회도 되지 않지만, 게시물 하나가 공유되면 10분에 수백 회가 들어올 수 있다. 접속자가 한꺼번에 몰리는 시간과 그때 페이지를 만들기 위해 데이터베이스 조회가 얼마나 일어나는지가 서버 부하를 좌우한다.

공유 호스팅과 VPS의 경계는 운영 방식에 있다

회사 소개, 메뉴 안내, 문의 폼 정도의 홈페이지라면 공유 웹호스팅이나 정적 사이트 호스팅으로 시작해도 충분한 경우가 많다. 서버 업데이트와 기본 설정을 직접 맡을 필요가 적고, 월 비용도 낮다. 방문이 늘기 전까지 비싼 서버를 먼저 확보할 이유는 별로 없다.

게시판이나 워드프레스처럼 요청할 때마다 화면을 만드는 홈페이지는 상황이 조금 다르다. 페이지 캐시를 켜고 플러그인을 적게 쓴다면 월 수만 회 조회 규모에서 공유 호스팅이나 1~2개 가상 CPU, 메모리 2GB 정도의 소형 VPS를 시험 출발점으로 삼을 수 있다. 이 숫자는 보장 사양이 아니다. 관리자 화면이 자주 멈추거나, 캐시가 통하지 않는 회원 기능이 많거나, 접속이 짧은 시간에 몰린다면 측정 후 조정해야 한다.

VPS는 설정을 바꿀 자유가 있는 대신 보안 업데이트, 방화벽, 장애 대응도 운영자 몫이다. 서버를 만질 시간이 없다면 같은 방문 규모에서 관리형 호스팅이 더 실용적일 수 있다. 요금표를 비교할 때는 CPU와 메모리 외에 저장 공간, 월 전송량, 백업 제공 여부, 복구 비용을 함께 적어 놓는 게 좋다.

이전할 때는 복구 가능한 백업을 먼저 만든다

홈페이지 이전 사고는 파일을 빼먹거나 데이터베이스 시점을 맞추지 못해서 생긴다. 이전 전에는 웹 파일, 데이터베이스, 업로드 파일, 서버 설정을 각각 확보한다. 백업 파일을 받았다는 사실만으로 안심하지 말고 임시 환경에서 실제로 복원해 첫 화면, 게시물, 첨부파일, 로그인까지 확인해야 한다.

기존 서버의 파일과 데이터베이스를 백업하고 복원에 걸린 시간을 기록한다.
새 서버에서 화면과 기능을 확인한 뒤, 이전 직전 바뀐 데이터만 다시 옮긴다.
접속 대상을 바꾸는 동안 기존 서버를 바로 지우지 않고 한동안 유지한다.
새 서버에서 SSL 인증서, 문의 메일, 예약 작업, 관리자 로그인을 확인한다.

도메인 접속 대상을 바꿔도 모든 방문자가 즉시 새 서버로 오지는 않는다. 이전 하루 전쯤 DNS 캐시 유지 시간을 짧게 조정하고, 변경 후에는 이전 서버와 새 서버의 접속 기록을 함께 보는 편이 안전하다. 주문이나 회원 글이 쌓이는 홈페이지라면 전환 시간에 쓰기를 잠시 멈추는 방법도 검토해야 한다.

느려지거나 멈췄을 때 확인할 순서

장애가 나면 서버부터 재시작하는 경우가 있는데, 그러면 원인을 보여 주던 기록이 사라질 수 있다. 먼저 접속 오류가 모든 방문자에게 나타나는지 확인한다. 그다음 도메인 연결, SSL 인증서 만료, 디스크 여유 공간, 웹서버와 데이터베이스 상태, 최근 배포나 설정 변경 순서로 좁혀 간다. 특정 페이지만 느리면 이미지 크기나 느린 데이터베이스 조회가 원인일 수도 있다.

평소에는 CPU 평균보다 장애를 먼저 알려 주는 지표를 챙긴다. 디스크가 90% 가까이 찼는지, 백업이 성공한 날짜가 언제인지, 인증서가 언제 만료되는지 정도만 꾸준히 확인해도 급한 사고를 많이 줄일 수 있다. 백업은 서버 안에 한 벌만 두지 말고 별도 저장 공간에도 보관해야 한다. 같은 서버가 고장 나면 원본과 백업을 함께 잃기 때문이다.

저는 홈페이지 규모가 작을수록 사양을 크게 잡기보다 복원 절차를 짧게 만드는 데 돈과 시간을 쓴다. 트래픽은 늘어난 뒤에도 증설할 수 있지만, 복구해 본 적 없는 백업은 장애가 난 순간에야 빈틈이 드러난다.