모두
모두콘텐츠
얼마 전 방문자가 늘었다며 단독웹호스팅으로 옮기려는 사이트를 봤습니다. 접속 기록을 확인하니 서버가 바쁜 시간은 짧았고, 느려진 원인은 백업 작업과 방문자 요청이 겹친 것이었습니다. 시간을 분리하자 기존 요금제로도 충분했습니다. 이런 경우가 꽤 많습니다. 단독 자원이 필요한지 보려면 월 방문자 수보다 바쁜 시간에 서버가 처리하는 일을 먼저 계산해야 합니다.
단독이라는 말보다 자원 배분 방식을 확인한다
단독웹호스팅은 업체마다 뜻이 다릅니다. 한 서버를 혼자 쓰는 상품도 있고, 한 서버 안에서 CPU와 메모리만 일정량 배정받는 상품도 있습니다. 관리형 상품이라면 운영체제와 보안 업데이트를 업체가 맡을 수도 있습니다. 상품 이름만 보고 물리 서버 전체를 쓴다고 생각하면 사양과 비용을 잘못 비교하게 됩니다.
계약 전에 CPU 사용 한도, 메모리 보장량, 저장 공간의 종류와 입출력 제한, 월 전송량, 초과 시 처리 방식을 확인합니다. 데이터베이스가 같은 자원을 쓰는지도 중요합니다. 백업 보관 공간이 기본 용량에 포함되는지, 복구 요청에 별도 비용이 드는지도 봐야 합니다. 장애 때 손댈 수 있는 범위는 관리형 여부에 따라 달라지니 접근 권한과 지원 범위도 확인할 항목입니다.
일반 웹호스팅은 이웃 사이트의 부하 영향을 받을 수 있지만, 운영 부담이 작고 가격이 낮습니다. 단독 자원은 부하를 예측하기 쉬운 편이지만 설정과 복구 책임이 늘 수 있습니다. 페이지가 몇 초 느리다는 이유만으로 옮기기 전에 이미지 크기, 캐시, 느린 데이터베이스 질의부터 확인하는 편이 정확합니다.
방문자 수를 동시 처리량으로 바꿔 본다
하루 페이지 조회가 3만 회라고 가정해 보겠습니다. 한 페이지를 열 때 서버가 직접 처리하는 동적 요청이 5건이면 하루 15만 건입니다. 이를 하루 8만6400초로 나누면 평균 초당 약 1.7건입니다. 바쁜 시간대가 평균의 10배라면 초당 약 17건을 처리해야 합니다. 이미지나 스크립트가 별도 캐시에서 제공된다면 서버가 맡는 요청은 더 적습니다.
요청 하나가 서버에서 평균 0.3초 머무르면, 초당 17건일 때 동시에 처리 중인 요청은 계산상 약 5건입니다. 여기에 일시적인 몰림과 처리 시간의 편차를 감안해 작업자 수를 8~10개부터 검토할 수 있습니다. 다만 이 숫자는 출발점입니다. 장바구니 계산, 검색, 관리자 작업처럼 데이터베이스를 많이 쓰는 요청이 섞이면 같은 방문자 수에서도 필요한 자원이 달라집니다.
메모리도 작업자 수로 가늠합니다. 웹 작업자 하나가 실제로 80MB를 쓴다면 10개에 약 800MB가 필요합니다. 여기에 운영체제, 데이터베이스, 캐시, 백업 작업의 메모리를 더해야 합니다. 이런 구성에서는 메모리 2GB가 빠듯할 수 있고 4GB가 편할 수 있습니다. 데이터베이스를 분리했거나 캐시가 잘 잡혀 있다면 얘기가 달라집니다. CPU 2개와 메모리 4GB를 무조건 권할 수 없는 이유입니다.
느려질 때 자원을 늘려야 하는지 구분한다
저는 먼저 바쁜 시간의 CPU 사용률, 메모리 부족 기록, 디스크 대기 시간, 데이터베이스의 느린 질의를 함께 봅니다. CPU가 계속 높은데 요청이 몰릴 때 응답 시간도 늘어난다면 처리 능력이 부족할 가능성이 있습니다. 반대로 CPU는 한가한데 응답이 느리다면 데이터베이스 잠금, 외부 연동 대기, 디스크 입출력을 의심합니다. 서버를 큰 것으로 바꿔도 원인이 남아 있으면 속도는 기대만큼 나아지지 않습니다.
평균 응답 시간만 보면 짧은 장애를 놓칩니다. 바쁜 시간대 요청 중 느린 쪽 5%의 응답 시간과 오류 비율을 같이 보는 게 낫습니다. 예를 들어 평소에는 0.2초인데 특정 시간에 3초를 넘고 오류까지 생긴다면, 그 시각의 백업·예약 작업·접속 증가가 겹쳤는지 맞춰 봅니다. 하루 몇 분만 문제가 있다면 작업 시간을 옮기는 것으로 해결될 수도 있습니다.
공유 자원 한도에 반복해서 걸리고, 캐시와 질의를 손본 뒤에도 바쁜 시간의 성능이 불안정하다면 단독웹호스팅을 검토할 만합니다. 독립적인 설정이 필요하거나 여러 사이트의 자원을 한곳에서 관리해야 할 때도 선택 이유가 됩니다. 반면 규모가 작은 소개 사이트나 캐시가 잘 적용된 블로그는 저가 웹호스팅으로 충분한 경우가 많습니다.
이전 비용에는 복구 시간을 포함한다
이전할 때 가장 자주 빠지는 것은 파일보다 데이터의 시점입니다. 기존 서버에서 파일과 데이터베이스를 각각 백업했다면 생성 시간이 어긋날 수 있습니다. 글이나 주문이 계속 들어오는 사이트라면 최종 이전 직전에 쓰기를 잠시 멈추고 데이터를 다시 옮겨야 합니다. 옮긴 뒤에는 화면만 보지 말고 로그인, 글 작성, 결제나 문의 접수, 관리자 기능까지 확인합니다.
백업은 저장했다는 기록보다 복원 시험이 중요합니다. 저는 최소한 백업 파일이 실제로 열리는지, 별도 환경에서 데이터베이스가 복원되는지, 복원에 몇 분이 걸리는지 확인합니다. 서버와 같은 저장 장치에만 백업을 두면 장치 장애 때 함께 잃을 수 있습니다. 보관 기간도 정해야 합니다. 오류를 며칠 뒤 발견했는데 최근 백업만 남아 있으면 되돌릴 시점을 고를 수 없습니다.
이전 후 장애가 나면 접속 자체가 안 되는지, 화면만 깨지는지, 특정 기능만 실패하는지부터 나눕니다. 그다음 이름 해석과 인증서 상태, 웹서버 기록, 데이터베이스 연결, 디스크 여유 공간 순으로 확인하면 범위를 빨리 좁힐 수 있습니다. 되돌릴 기존 환경을 바로 없애지 않고 잠시 유지하는 것도 실무에서는 값어치가 큽니다.
단독웹호스팅은 방문자가 많아졌다는 사실만으로 사는 상품은 아닙니다. 바쁜 시간의 요청량과 작업별 자원 사용량을 재고, 복구에 걸리는 시간까지 계산했을 때 기존 상품의 한계가 분명해지면 그때 옮겨도 늦지 않습니다. 서버를 운영하면서 비용을 아낀 순간은 대개 큰 장비를 고른 때보다, 느려진 이유를 정확히 찾은 때였습니다.
