모두
모두콘텐츠
얼마 전 방문자가 하루 200명도 안 되는 사이트가 서버를 올려야 한다는 상담을 받았다. 접속이 느린 원인은 서버 성능이 아니라 용량이 큰 첫 화면 이미지와 매번 실행되는 백업 작업이었다. 홈페이지호스팅을 고를 때는 요금제 이름보다 실제 사용량과 운영 방식을 먼저 봐야 한다.
방문자 수를 전송량과 순간 부하로 바꾸기
월 방문자 수만 보고 서버를 고르면 빗나가기 쉽다. 한 사람이 몇 페이지를 보는지, 페이지 하나를 내려받을 때 데이터가 얼마나 나가는지부터 계산한다. 월 방문자 1만 명이 평균 3페이지를 보고 페이지당 전송량이 1MB라면 월 전송량은 약 30GB다. 이미지가 많아 페이지당 3MB라면 같은 방문자 수에서도 약 90GB가 된다. 브라우저 캐시와 검색 로봇 때문에 실제 청구량은 달라지므로, 계산값에 여유를 두고 운영 화면의 전송량과 비교하는 게 낫다.
서버가 버텨야 할 부하는 월 전송량과 또 다르다. 하루 방문자 1천 명이 3페이지씩 본다면 하루 평균은 초당 약 0.035페이지다. 방문이 특정 시간에 10배 몰려도 초당 약 0.35페이지다. 이 정도의 단순 회사 소개 사이트라면 비싼 서버부터 살 이유가 없다. 반대로 방문자가 적어도 결제 시작 시각에 요청이 한꺼번에 몰리거나, 검색할 때마다 데이터베이스에서 큰 표를 뒤지는 사이트는 순간 부하를 따로 봐야 한다.
사이트 종류에 맞춰 첫 사양 잡기
정적 페이지나 이미지 위주의 작은 사이트는 저가 웹호스팅으로 시작해도 충분한 경우가 많다. 운영자가 서버 보안 패치와 웹서버 설정을 직접 맡을 필요가 없다는 점도 이득이다. 다만 같은 상품이라도 저장 공간, 월 전송량, 데이터베이스 제공 여부, 백업 복구 범위가 다르다. 가격표의 저장 공간보다 복구할 수 있는 백업이 있는지를 먼저 확인한다.
워드프레스처럼 페이지를 만들 때마다 PHP와 데이터베이스가 동작한다면 메모리 여유가 중요하다. 최적화된 소규모 사이트는 공유 호스팅에서도 잘 돌아간다. 직접 VPS를 운영해야 한다면 1~2개 가상 CPU와 메모리 2GB 정도를 첫 기준으로 삼고, 플러그인 수와 실제 메모리 사용량을 보고 조정할 만하다. 운영체제, 데이터베이스, 웹서버가 같은 장비에 올라가는 구성에서 메모리 1GB는 업데이트나 백업 중 여유가 빠듯할 수 있다.
상품 목록이 많거나 로그인, 검색, 주문 처리가 잦다면 2개 가상 CPU와 메모리 4GB 정도에서 부하를 측정하며 시작할 수 있다. 이것도 보장 사양은 아니다. 느린 쿼리 하나가 CPU 증설보다 큰 영향을 주기도 한다. CPU 사용률이 계속 높은지, 메모리 부족으로 프로세스가 종료되는지, 디스크 읽기와 쓰기가 밀리는지를 확인한 뒤 올려야 돈을 덜 쓴다.
가격표에서 빠지기 쉬운 비용 보기
월 요금만 비교하면 이전 뒤에 예상 밖의 비용이 붙는다. 저장 공간과 전송량 초과 요금, 백업 보관 기간, 복구 작업 비용, 도메인 갱신 비용, SSL 인증서 제공 범위를 같은 표에 놓고 봐야 한다. 무료 인증서를 쓸 수 있어도 자동 갱신이 설정돼 있는지는 별개의 문제다. 인증서가 만료되면 서버가 멀쩡해도 방문자는 접속 경고를 본다.
VPS는 서버 자원을 더 자유롭게 쓰는 대신 운영 시간을 비용에 넣어야 한다. 보안 업데이트, 방화벽, 계정 관리, 모니터링, 백업 검증을 맡을 사람이 없다면 월 요금이 조금 더 높은 관리형 호스팅이 실제로는 저렴할 수 있다. 반대로 설정을 직접 관리하고 여러 사이트를 묶어 운영한다면 VPS가 유리해지는 구간도 있다. 클라우드 서버는 자원을 조절하기 편하지만 트래픽과 저장장치, 백업 비용이 별도로 쌓일 수 있으니 예상 사용량으로 한 달 비용을 계산한다.
이전과 백업은 복구 순서까지 적어두기
이전 작업은 기존 사이트를 바로 끄는 순간 어려워진다. 먼저 파일과 데이터베이스를 각각 백업하고, 새 환경에서 같은 버전의 실행 환경과 설정을 맞춘다. 로그인, 게시물 작성, 문의 메일, 결제처럼 데이터를 바꾸는 기능을 시험한 뒤 도메인 연결을 전환한다. 전환 직전에는 기존 사이트의 게시물 작성이나 주문 접수를 잠시 멈추는 편이 안전하다. 두 서버에 새 데이터가 나뉘어 저장되면 나중에 합치기 까다롭다.
백업은 파일이 존재하는 것만으로 끝나지 않는다. 자동 백업 주기, 보관 개수, 서버 밖 별도 저장 여부를 확인하고 실제로 한 번 복원해 봐야 한다. 매일 백업해도 오류가 난 데이터를 며칠째 덮어쓰고 있다면 쓸 수 있는 시점이 없을 수 있다. 변경이 잦은 쇼핑몰은 하루 한 번으로 부족할 수 있고, 거의 바뀌지 않는 소개 사이트는 더 긴 주기도 가능하다. 허용할 수 있는 데이터 손실 시간을 기준으로 주기를 정한다.
장애가 나면 우선 접속 오류가 모든 방문자에게 나는지, 특정 기능에서만 나는지 구분한다. 그다음 도메인 연결과 SSL 만료, 서버 자원 사용량, 웹서버와 애플리케이션 기록, 최근 변경 사항을 차례로 본다. 최근 플러그인 업데이트나 설정 변경 직후 시작된 장애라면 그 변경을 되돌리는 것이 서버를 키우는 것보다 빠를 때가 많다. 적정 사양은 처음부터 크게 사는 숫자가 아니라, 사용량을 재고 복구 가능한 상태를 유지하면서 조정하는 값이라고 생각한다.
