모두
모두콘텐츠
얼마 전 접속자가 늘었다며 서버임대를 문의한 운영자가 있었다. 로그를 보니 서버가 바쁜 시간은 하루에 몇 분뿐이었다. 평소 장애의 원인은 트래픽이 아니라 용량이 꽉 찬 디스크와 실패한 백업 작업이었다. 이런 경우 비싼 서버로 옮겨도 문제는 그대로 따라간다.
서버를 고르기 전에 사용량부터 잰다
서버임대라는 말은 단독 물리 서버를 빌리는 뜻으로도, VPS나 클라우드 인스턴스를 쓰는 뜻으로도 쓰인다. 먼저 필요한 자원을 계산해야 상품 이름에 끌려가지 않는다. 최소한 최근 한 달의 시간대별 방문 수, 가장 바쁜 5분의 요청 수, 메모리 사용량, 디스크 사용량과 증가 속도를 확인한다. 월간 방문자 수 하나로 사양을 정하면 순간 부하를 놓치기 쉽다.
예를 들어 월 30만 페이지뷰라도 하루 평균은 약 1만 회다. 다만 행사 알림 직후 10분에 2만 회가 몰리면 평균값은 별 의미가 없다. 이때 1초당 요청 수는 페이지뷰를 초로 나눈 값과도 다르다. 한 페이지를 열 때 HTML, 이미지, 스크립트가 여러 번 요청될 수 있기 때문이다. 정적 파일을 캐시하거나 별도 전송망에서 제공하는지까지 봐야 서버가 직접 처리할 요청이 나온다.
동시접속도 숫자만 따로 보면 오해하기 쉽다. 서버가 직접 처리하는 요청이 초당 20건이고 각 요청의 처리 시간이 평균 0.2초라면, 처리 중인 요청은 평균 약 4건이다. 처리 시간이 2초로 늘어나면 같은 유입에서도 약 40건이 된다. 느린 데이터베이스 조회 하나가 서버 증설보다 먼저 손봐야 할 문제일 수 있다.
공유 호스팅부터 단독 서버까지 선택하는 순서
운영 초기의 콘텐츠 사이트라면 공유 웹호스팅이나 작은 VPS로 충분한 경우가 많다. 서버 설정 권한이 필요 없고 관리 인력이 없다면 공유 호스팅이 오히려 편하다. 반대로 특정 프로그램 설치, 작업 예약, 접속 제어가 필요하면 VPS가 맞는다. VPS는 저렴하게 시작할 수 있지만 운영체제 업데이트, 방화벽, 백업 상태를 직접 챙겨야 하는 상품도 많다.
작은 VPS를 고를 때는 CPU 개수만 보지 않는다. 메모리가 부족해 디스크 교환 영역을 계속 쓰면 응답 시간이 급격히 늘어난다. 운영체제와 웹서버, 데이터베이스를 한 대에 두는 소규모 사이트라면 메모리 2GB가 빠듯할 수 있어 4GB 안팎에서 시작하고 실제 사용량을 보는 편이 낫다. 이 수치는 출발점이지 모든 사이트에 통하는 기준은 아니다. 이미지 변환이나 검색 색인처럼 메모리를 많이 쓰는 작업이 있으면 별도로 계산해야 한다.
단독 물리 서버 임대는 지속적으로 높은 CPU 사용률이 나오거나, 큰 메모리와 저장장치 성능이 필요하거나, 장비 자원을 다른 고객과 나누기 어려울 때 검토한다. 평소에는 한가한데 가끔 몰리는 사이트라면 상위 단독 서버를 장기간 계약하기 전에 캐시와 부하 분산부터 확인하는 게 합리적이다. 클라우드도 자동으로 저렴해지는 것은 아니다. 서버 비용에 저장 공간, 외부 전송량, 백업 보관료가 더해지는 구조인지 확인해야 월 청구액을 예상할 수 있다.
월 요금보다 먼저 확인할 계약 조건
같은 월 요금이라도 포함된 자원은 다르다. CPU와 메모리 외에 디스크 종류와 용량, 월 전송량, 초과 요금, 백업 제공 범위, 장애 대응 시간을 한 줄씩 비교한다. 특히 ‘무제한 트래픽’이라는 표현은 회선 속도 제한이나 과도한 사용에 대한 조건을 함께 읽어야 한다. 월 전송량만 넉넉해도 회선 속도가 낮으면 짧은 시간에 접속자가 몰릴 때 느려질 수 있다.
대략적인 전송량은 페이지 한 번에 서버 밖으로 나가는 평균 데이터 크기에 월 페이지뷰를 곱해 잡는다. 평균 2MB인 페이지가 월 30만 번 열리면 약 600GB다. 이 수치에는 봇 요청, 파일 다운로드, 관리자 작업, 이미지 캐시 적중률이 반영되지 않는다. 실제 전송량 기록에 여유분을 더해 계약 조건과 비교하는 편이 정확하다. 여러 업체의 가격을 비교할 때도 같은 메모리 용량과 같은 전송 조건으로 맞춰야 한다.
관리형 상품이라면 어디까지 대신 운영하는지도 중요하다. 서버 재부팅만 해주는지, 보안 업데이트와 데이터베이스 점검까지 맡는지에 따라 운영 부담이 크게 달라진다. 장애가 났을 때 연락할 수 있는 시간과 복구 책임의 경계도 계약 전에 확인해 두면 좋다.
이전과 백업을 사양표만큼 꼼꼼히 본다
서버를 옮길 때 가장 흔한 실수는 파일 복사만 끝내고 데이터베이스와 사용자 업로드를 놓치는 것이다. 먼저 현재 서버의 파일, 데이터베이스, 작업 예약, 환경 설정, SSL 인증서 갱신 방식까지 목록으로 만든다. 새 서버에서 서비스를 띄운 뒤 실제 로그인과 글 작성, 파일 업로드를 시험한다. 마지막 데이터 동기화 시점과 서비스 중단 시간을 정해 두고 전환해야 누락을 줄일 수 있다.
백업은 ‘켜져 있음’보다 ‘복구할 수 있음’이 중요하다. 서버와 같은 디스크에만 백업 파일을 두면 디스크 장애나 계정 침해 때 함께 잃을 수 있다. 별도 저장 위치에 보관하고, 최근 백업 파일 하나를 시험 서버에서 주기적으로 복원해 본다. 하루치 데이터 손실을 감당할 수 없다면 하루 한 번 백업으로는 부족하다. 얼마나 오래 멈출 수 있는지도 함께 정해야 복구 방식과 비용을 정할 수 있다.
운영 중 사이트가 느려지면 바로 상위 요금제로 옮기지 않는다. 먼저 CPU와 메모리, 디스크 여유 공간, 데이터베이스의 느린 쿼리, 오류 기록을 같은 시간대에 맞춰 본다. 백업 작업이 접속이 몰리는 시간과 겹치는지도 확인한다. 내가 서버임대 사양을 결정할 때 가장 신뢰하는 숫자는 광고에 적힌 최대 성능보다 내 사이트가 바쁜 순간에 남긴 기록이다.
