모두
모두콘텐츠
얼마 전 하루 방문자가 200명 남짓한 사이트를 점검했는데, 운영자는 접속이 느려지자 VPS부터 알아보고 있었다. 로그를 보니 서버가 부족한 게 아니라 이미지 한 장이 8MB였고 백업 작업이 방문이 몰리는 시간에 돌고 있었다. 이런 경우 요금제를 올려도 체감 속도는 크게 달라지지 않는다.
리눅스호스팅을 고를 때는 월 방문자 수보다 페이지 전송량, 가장 바쁜 시간의 요청 수, 사이트가 쓰는 메모리를 먼저 본다. 같은 방문자 1,000명이라도 글만 읽는 블로그와 로그인·검색이 잦은 쇼핑몰은 필요한 자원이 다르다.
월 트래픽부터 계산한다
첫 계산은 단순하다. 하루 페이지 조회 수에 페이지당 실제 전송량과 30일을 곱한다. 하루 1,000회 조회되고 페이지당 평균 1MB가 전송된다면 월 약 30GB다. 이미지 최적화나 캐시가 잘 되어 평균 500KB로 줄면 약 15GB가 된다. 서버 상품의 ‘디스크 100GB’는 저장 공간이고, 월 전송량 100GB와는 다른 숫자다.
관리 화면의 방문자 수만으로 전송량을 추정하면 오차가 크다. 웹서버 로그나 호스팅 통계에서 월간 전송량을 확인하고, 상품 한도가 있다면 최근 사용량에 20~30% 정도 여유를 둔다. 광고 집행이나 행사처럼 갑자기 유입이 늘어날 일정이 있으면 그 기간은 따로 계산해야 한다.
월 1만~3만 페이지 조회의 일반적인 글 중심 사이트라면 저가 공유 호스팅으로도 충분한 경우가 많다. 다만 상품마다 CPU 사용 시간, 동시 처리 수, 데이터베이스 용량을 제한하는 방식이 달라서 ‘무제한 트래픽’ 문구 하나로 판단하면 곤란하다. 무료 상품도 시험용이나 변경이 드문 작은 사이트에는 쓸 만하지만, 백업 복구 기능과 사용량 초과 시 처리 방식은 먼저 확인한다.
동시접속보다 바쁜 순간의 요청을 본다
관리 화면에 동시접속자 100명이 찍혔다고 서버가 요청 100개를 동시에 처리하는 것은 아니다. 사람이 글을 읽는 동안에는 서버가 쉬고 있을 수도 있다. 반대로 검색 버튼을 여러 사람이 한꺼번에 누르면 적은 방문자 수로도 데이터베이스가 바빠진다.
대략적인 출발점은 초당 요청 수와 응답 시간을 곱하는 것이다. 가장 바쁜 시간에 초당 동적 요청 20개가 들어오고 각 요청이 평균 0.3초 걸리면, 동시에 처리 중인 요청은 평균 약 6개다. 이 값은 평균이므로 순간 폭주와 느린 요청을 감안해 여유를 둬야 한다. 정적 파일 요청과 PHP 같은 동적 요청도 나눠서 봐야 한다.
예를 들어 PHP 작업 하나가 메모리 80MB를 쓰고 작업자 8개가 필요하다면 애플리케이션에만 약 640MB가 든다. 여기에 운영체제, 웹서버, 데이터베이스, 파일 캐시가 더해진다. 이런 구성에서 메모리 1GB VPS는 빠듯할 수 있고 2GB가 시작점으로 더 현실적이다. 반면 정적 페이지나 캐시 적중률이 높은 블로그는 같은 조회 수라도 훨씬 작은 자원으로 버틴다. 숫자는 상품 보증치가 아니라 실제 사용량을 측정하기 전의 계산 예시다.
공유 호스팅과 VPS는 운영 부담까지 비교한다
공유 호스팅은 서버 업데이트, 기본 보안 설정, 장애 대응 일부를 업체가 맡는다. 사이트 하나를 안정적으로 운영하려는 사람에게 이 편의는 꽤 크다. 단, 서버 설정을 바꾸기 어렵고 특정 프로그램 설치나 상시 실행 작업에 제한이 있을 수 있다.
VPS는 설정 권한이 넓지만 운영체제 업데이트, 방화벽, 계정 권한, 백업, 장애 복구가 운영자 몫이다. 필요한 메모리가 2GB라는 계산만으로 VPS가 더 싸다고 판단하면 이 작업 시간이 빠진다. 직접 운영할 이유가 명확하고 점검할 사람이 있을 때 옮기는 편이 낫다. 클라우드 서버도 같은 기준으로 보고, 추가 저장 공간과 데이터 전송 비용까지 합산해야 월 비용이 보인다.
SSL 인증서가 포함된 상품이라도 자동 갱신 여부를 확인한다. 인증서 만료는 서버가 멀쩡한데도 방문자에게 접속 오류처럼 보이는 흔한 원인이다. 도메인 만료일과 갱신 결제 수단 역시 서버 사양과 별도로 관리해야 한다.
이전과 백업은 복구까지 시험한다
사이트를 옮길 때는 파일만 복사하면 끝이라고 생각하기 쉽다. 실제로는 데이터베이스, 업로드 파일, 환경 설정, 예약 작업, 메일 사용 여부까지 확인해야 한다. 먼저 기존 서버의 전체 백업을 받고 새 서버에 복원한다. 새 서버에서 내부 미리보기로 로그인, 글 작성, 이미지 표시, 메일 발송을 확인한 뒤 도메인 연결을 바꾼다.
게시글이나 주문이 계속 들어오는 사이트라면 마지막 데이터 동기화 시간이 중요하다. 전환 직전에 쓰기를 잠시 막거나 변경분을 다시 옮겨야 누락을 줄일 수 있다. 도메인 연결을 바꾼 직후에도 일부 방문자는 한동안 옛 서버로 갈 수 있으니, 바로 해지하지 말고 접속 로그와 데이터 차이를 확인한다.
백업은 서버와 다른 저장 위치에 두고, 파일과 데이터베이스를 함께 보관한다. 매일 백업했다는 표시보다 중요한 것은 실제 복원 결과다. 한 달에 한 번이라도 시험 공간에 복원해 첫 화면과 관리자 로그인, 최근 글을 확인하면 백업이 쓸모 있는지 알 수 있다. 보관 기간은 실수나 침해 사실을 늦게 발견할 가능성까지 고려해 정한다.
장애가 나면 먼저 도메인과 SSL 만료 여부, 외부에서의 접속 상태를 확인한다. 다음으로 웹서버와 애플리케이션 로그의 오류 시간, 디스크 여유, 메모리 부족 기록, 데이터베이스 연결 상태를 같은 시각에 맞춰 본다. 5xx 오류가 급증했는데 CPU는 한가하다면 요금제를 올리기 전에 설정 오류나 데이터베이스 연결 제한을 의심하는 게 순서다. 14년 운영하면서 비용을 가장 많이 아낀 순간은 싼 서버를 찾았을 때보다, 느려진 이유를 숫자로 확인하고 불필요한 증설을 멈췄을 때였다.
