모두
모두콘텐츠
얼마 전 월 방문자가 1만 명도 안 되는 사이트에서 서버를 올려야 하느냐는 상담을 받았다. 관리 화면이 느리다는 게 이유였다. 확인해 보니 서버 자원보다 예약 작업과 데이터베이스 설정이 문제였다. 서버를 두 배 큰 것으로 바꿔도 같은 문제가 남았을 것이다. 클라우드비교를 할 때 요금제 이름보다 현재 부하와 운영 방식을 먼저 보는 이유다.
방문자 수를 서버 사양으로 바로 바꾸지 않는다
월간 방문자나 페이지 조회 수만으로 CPU를 고르기는 어렵다. 같은 10만 페이지 조회라도 이미지가 많은 정적 사이트와 검색·장바구니 요청이 많은 쇼핑몰은 서버가 하는 일이 다르다. 먼저 한 페이지를 열 때 전송되는 데이터 크기, 캐시가 처리하는 비율, 서버에서 직접 실행되는 요청 수를 나눠 적는다.
예를 들어 월 10만 페이지 조회에 페이지당 전송량이 1.5MB라면 대략 150GB가 나간다. 이 수치는 대역폭과 전송 요금을 가늠하는 출발점이다. 반면 10만 건을 한 달 전체로 나눈 평균은 초당 0.04건에도 못 미친다. 실제 접속은 특정 시간에 몰리므로 이 평균으로 서버를 고르면 안 된다. 접속 기록에서 가장 바쁜 5분의 요청 수를 뽑고, 그때의 CPU 사용률과 응답 시간을 함께 봐야 한다.
동시접속도 숫자만 따로 보면 오해하기 쉽다. 초당 동적 요청 4건이 들어오고 각 요청을 처리하는 데 0.5초가 걸리면, 처리 중인 요청은 대략 2건이다. 응답 시간이 5초로 늘면 같은 유입에서도 20건이 쌓인다. 느린 데이터베이스 쿼리 하나가 서버 증설보다 먼저 해결할 문제일 수 있다.
공유 호스팅과 VPS를 가르는 운영 기준
회사 소개 사이트나 작은 블로그라면 공유 웹호스팅부터 검토한다. 서버 보안 갱신, 웹서버 설정, 기본 장애 대응을 업체가 맡는 범위가 넓다. 월 트래픽이 적고 특수한 실행 환경이 필요 없다면 저가 요금제로도 충분한 경우가 많다. 다만 CPU 사용 제한, 실행 시간 제한, 백업 보관 기간은 계약 전에 확인해야 한다.
VPS는 운영체제와 웹서버 설정을 직접 제어해야 할 때 유리하다. 그만큼 보안 패치, 방화벽, 로그 확인, 백업 복원도 운영자의 일이 된다. 작은 콘텐츠 사이트는 1개 가상 CPU와 1GB 메모리에서도 돌아갈 수 있지만, 데이터베이스와 관리 화면을 함께 쓰는 CMS라면 2개 가상 CPU와 2~4GB 메모리에서 시험을 시작하는 편이 현실적이다. 이 숫자는 구매 기준이 아니라 측정 출발점이다. 플러그인 수와 캐시 설정에 따라 필요한 메모리가 크게 달라진다.
관리형 클라우드는 장애 대응 인력이 부족하거나 데이터베이스, 저장소, 서버를 분리해 운영할 이유가 있을 때 값어치를 한다. 작은 사이트에 구성 요소를 무작정 늘리면 월 비용과 장애 지점이 함께 늘어난다. 방문자가 적은데도 관리형 서비스가 필요한 경우는 있다. 짧은 복구 시간이나 운영 인력의 제약이 명확할 때다.
월 요금은 서버 한 대 가격으로 비교하지 않는다
클라우드비교 표에는 최소한 컴퓨팅, 디스크, 외부 전송량, 백업 저장량, 관리형 데이터베이스 비용을 따로 넣는다. AWS, Google Cloud, Azure의 요금 안내에서도 디스크와 외부 전송량, 스냅샷은 서버 실행 비용과 별도 항목으로 다뤄진다. 같은 사양의 가상 서버라도 이 항목을 빼면 월말 청구액이 달라진다.
가령 두 요금제가 모두 2개 가상 CPU와 4GB 메모리를 준다고 하자. 한쪽은 월 전송량이 포함되고 다른 쪽은 사용량에 따라 청구한다면, 앞서 계산한 월 150GB를 넣어 봐야 비교가 된다. 이미지 최적화로 페이지당 1.5MB를 1MB로 줄이면 월 전송량은 약 100GB가 된다. 서버를 키우는 것보다 이미지와 캐시를 손보는 편이 비용에 더 크게 작용할 수 있다.
무료 요금제도 같은 방식으로 본다. 개발·검증용이나 접속이 드문 정적 사이트에는 잘 맞는다. 다만 무료 사용 한도, 중단 조건, 초과 과금 방식은 서비스마다 다르고 바뀔 수 있다. 무료라는 표시만 보고 운영 사이트를 올리기보다 예상 사용량을 넣어 월 청구액을 계산하는 게 안전하다.
이전과 백업까지 넣어야 실제 비용이 보인다
서버 이전에서 자주 빠지는 비용은 사람의 작업 시간이다. 새 서버에 파일과 데이터베이스를 옮긴 뒤 로그인, 글쓰기, 결제처럼 데이터가 바뀌는 기능을 먼저 시험한다. 전환 하루 전에는 DNS의 TTL을 짧게 조정할 수 있지만, 모든 이용자가 즉시 새 서버로 이동하는 것은 아니다. 전환 중 양쪽 서버에서 쓰기가 발생하면 데이터가 갈라질 수 있으므로 쓰기 중단 시간과 되돌릴 기준을 정해 둔다.
백업은 생성 여부보다 복원 가능 여부가 중요하다. 파일과 데이터베이스를 함께 보관하고, 운영 서버와 다른 위치에 사본을 둔다. 하루에 한 번 백업하면 장애 시 최대 하루치 변경 사항을 잃을 수 있다. 그 손실이 허용되지 않는 서비스라면 백업 주기를 줄여야 한다. 반대로 복원에 두 시간이 걸리는데 서비스는 10분 안에 살아나야 한다면 백업 주기만 줄여서는 해결되지 않는다. 실제로 새 환경에 복원해 걸린 시간을 재야 한다.
사이트가 느리거나 열리지 않을 때도 순서가 있다. 먼저 도메인 해석과 SSL 인증서 상태를 확인하고, 그다음 웹서버 오류 기록, 디스크 여유 공간, 메모리, 데이터베이스 연결을 본다. 트래픽 급증은 기록에서 확인한 뒤 판단해도 늦지 않다. 14년 동안 본 장애 중에는 큰 서버가 필요했던 일보다 백업이 비어 있거나 설정 한 줄이 틀렸던 일이 더 많았다. 서버 비용을 줄인 만큼 복원 연습과 점검에 시간을 쓰는 쪽이 사이트를 오래 살린다.
