모두
모두콘텐츠
얼마 전 월 방문자가 3천 명인 블로그를 옮기면서 4코어 클라우드 서버를 권유받았다는 이야기를 들었다. 방문자 수만 보면 꽤 여유 있는 사양이다. 그런데 실제로 확인해야 할 것은 월간 방문자보다 가장 바쁜 시간의 요청 수, 페이지를 만드는 방식, 메모리 사용량이다. 이 세 가지를 보면 저렴한 웹호스팅으로 충분한지, 클라우드 서버가 필요한지 대체로 구분된다.
월간 트래픽을 서버 부하로 바로 바꾸지 않는다
월 10만 페이지뷰를 하루 평균으로 나누면 약 3,300페이지뷰다. 하루 조회의 10%가 가장 바쁜 한 시간에 몰린다고 가정해도 그 시간의 평균은 초당 약 0.09페이지뷰다. 순간적으로 그 열 배가 몰리고, 페이지 하나를 보여줄 때 원본 서버에 요청 다섯 건이 간다면 초당 약 4~5건을 처리하는 셈이다. 이미지와 스크립트를 외부 캐시에서 전달한다면 원본 서버가 받는 요청은 더 적다.
반대로 월 방문자가 적어도 예약 오픈 직후에 접속이 몰리거나, 검색할 때마다 큰 데이터베이스를 훑으면 작은 서버가 버티기 어렵다. 분석 도구에서 가장 바쁜 5분의 요청 수를 확인하고, 그 시간에 응답 시간이 늘어났는지 같이 봐야 한다. 평균 트래픽만으로 코어 수를 정하면 과하게 사거나 사고를 놓치기 쉽다.
- 정적 페이지와 캐시가 잘 되는 블로그라면 저가 웹호스팅부터 검토한다.
- 로그인, 장바구니, 실시간 조회처럼 매번 페이지를 만드는 기능이 많으면 캐시가 닿지 않는 요청을 따로 센다.
- 동시 작업 수는 대략 초당 요청 수에 응답 시간을 곱해 가늠한다. 초당 10건을 각 0.5초에 처리한다면 동시에 약 5건이 실행된다.
CPU보다 메모리 계산이 먼저인 경우가 많다
작은 워드프레스 사이트를 예로 들면 웹서버와 운영체제에 400~600MB, 데이터베이스에 400~700MB, PHP 작업자 네 개에 각각 100~150MB가 필요할 수 있다. 설정과 플러그인에 따라 차이가 크지만 합치면 1.2~1.9GB다. 2GB 서버는 돌아갈 수 있어도 업데이트나 백업 작업이 겹칠 때 여유가 거의 없다. 이 경우 코어를 늘리기 전에 작업자 수와 메모리 사용량을 확인한다.
CPU 사용률이 잠깐 치솟는 것과 메모리가 부족해 프로세스가 종료되는 것은 다르다. 평소 CPU가 낮은데 응답이 느리다면 느린 쿼리, 외부 API 대기, 디스크 입출력도 의심해야 한다. 대시보드에는 CPU 평균뿐 아니라 메모리 여유, 교체 메모리 사용, 디스크 대기 시간, 오류율을 같이 올려둔다. 서버를 키워도 느린 쿼리는 그대로 남는다.
처음부터 큰 사양을 잡을 필요는 없다. 캐시가 되는 소규모 사이트라면 공유 웹호스팅이나 작은 서버로 시작하고, 가장 바쁜 시간의 수치를 보고 한 단계씩 올리는 편이 낫다. 다만 1GB 서버에 데이터베이스와 여러 작업자를 한꺼번에 얹는 구성은 메모리 계산부터 해봐야 한다. 광고 문구의 ‘무제한’보다 실제 CPU·메모리 제한과 초과 시 동작이 중요하다.
요금은 서버 가격에 전송량과 백업을 더해 본다
클라우드 요금표의 월 서버 비용은 전체 비용이 아니다. 저장 공간, 외부 전송량, 스냅샷, 백업 보관 기간, 고정 주소, 관리형 데이터베이스가 별도 청구될 수 있다. 페이지당 전송량이 1MB이고 월 10만 페이지뷰라면 단순 계산으로 약 100GB다. 이미지 압축과 캐시 여부에 따라 실제 원본 서버의 전송량은 달라지므로, 현재 사용량을 먼저 재고 여유분을 붙인다.
예를 들어 서버비가 월 1만 원이어도 백업과 전송량에 각각 비용이 붙으면 비교 대상인 웹호스팅보다 비싸질 수 있다. 견적을 낼 때는 월간 총액과 함께 장애 때 복구에 걸리는 시간도 본다. 서버 관리 경험이 부족한 운영자에게는 자동 백업과 기술 지원이 포함된 상품이 오히려 비용을 줄인다. 직접 관리할 수 있고 설정을 세밀하게 바꿔야 할 때 클라우드의 장점이 커진다.
이전 전에는 복구와 되돌리기부터 준비한다
서버 이전에서 자주 터지는 문제는 새 서버의 성능보다 빠진 파일과 오래된 데이터베이스다. 작업 전 파일과 데이터베이스를 각각 백업하고, 실제로 다른 환경에 복원해 첫 화면과 관리자 로그인이 되는지 확인한다. 같은 계정 안에 둔 스냅샷만 믿으면 계정 문제나 실수로 함께 잃을 수 있다. 운영 서버와 분리된 위치에 복구본을 하나 더 둔다.
전환 며칠 전에는 DNS 캐시 시간을 짧게 조정하고, 새 서버에서 화면·로그인·메일 발송·예약 작업·인증서 적용을 확인한다. 전환 직전 데이터베이스를 다시 복사해야 하는 서비스라면 쓰기 중단 시간을 공지한다. 이전 후에는 오류 로그와 주문·문의 같은 실제 기록을 살피고, 문제가 생기면 기존 서버로 되돌릴 기준과 담당자를 미리 정해둔다. DNS 캐시 때문에 모든 방문자가 동시에 새 서버로 이동하지는 않는다.
백업은 ‘있다’는 표시보다 복원에 몇 분이 걸리는지가 중요하다. 데이터 손실을 하루까지 허용할지, 한 시간도 허용할 수 없는지에 따라 백업 주기가 달라진다. 복구 목표가 짧을수록 비용과 운영 부담도 올라간다. 저는 서버를 고를 때 최고 사양보다 가장 바쁜 시간의 실제 수치와 복원 연습 결과를 먼저 본다. 그 두 가지가 확인되면 필요한 만큼만 쓰기가 훨씬 쉬워진다.
