KT클라우드 서버 사양을 계산해서 고르는 방법

서버를 옮긴 뒤 사이트가 느려졌다는 연락을 받으면, 저는 먼저 CPU보다 설정을 봅니다. 실제로 메모리가 남아도 데이터베이스 연결 수가 막혀 오류가 나는 경우가 있습니다. KT클라우드로 이전할 때도 서버 상품부터 고르면 비용은 늘고 원인은 그대로 남기 쉽습니다. 현재 트래픽과 장애 기록을 먼저 펼쳐 놓는 편이 정확합니다.

월 방문자보다 바쁜 한 시간을 계산한다

월간 페이지 조회 수만으로 서버 크기를 정하면 피크를 놓칩니다. 예를 들어 월 30만 페이지 조회라면 하루 평균은 약 1만 건입니다. 하루 조회의 15%가 가장 바쁜 한 시간에 몰리면 시간당 1,500건, 초당 평균 약 0.4건입니다. 다만 광고를 집행하거나 알림을 보내는 날에는 그 시간 안에서도 요청이 짧게 몰립니다. 이 예시라면 순간 요청량을 평균의 10배인 초당 4건 안팎까지 가정해 시험해 볼 수 있습니다. 10배는 상품 기준이 아니라 여유를 확인하기 위한 가정값입니다.

페이지 하나가 평균 2MB라면 월 전송량은 단순 계산으로 약 600GB입니다. 여기서 이미지와 정적 파일을 얼마나 캐시하는지에 따라 원본 서버의 실제 전송량과 CPU 부담이 달라집니다. 반대로 회원 검색, 장바구니, 관리자 화면처럼 매번 데이터베이스를 읽는 요청이 많다면 같은 조회 수라도 더 무겁습니다. 웹서버 접속 기록에서 바쁜 시간의 초당 요청 수와 응답 시간, 오류 비율을 함께 뽑아야 하는 이유입니다.

작은 블로그라면 2개 가상 CPU와 4GB 메모리 정도를 시험 시작점으로 둘 수 있습니다. 이 숫자만 보고 곧바로 운영 사양을 확정하지는 않습니다. 실제 페이지를 대상으로 동시 접속을 늘리며 메모리 사용량, 데이터베이스 응답 시간, 디스크 대기 시간을 봅니다. 이미지가 많은 사이트와 예약 처리 사이트를 같은 요금제로 판단할 수는 없습니다.

서버 가격에는 빠진 항목을 더한다

KT클라우드 비용을 비교할 때는 가상머신 한 대의 표시 가격보다 한 달 운영비를 적어 보는 게 낫습니다. 서버 사용료에 운영체제 디스크, 추가 데이터 디스크, 외부 전송량, 공인 IP, 백업 저장 공간, 모니터링과 부가 서비스를 더합니다. 계약 방식과 사용 시간에 따라서도 청구액이 달라질 수 있으니 견적은 같은 조건으로 맞춰야 합니다.

가령 서버가 월 4만 원, 저장 공간과 백업이 2만 원, 네트워크 관련 비용이 1만 원이라면 실제 비교 기준은 월 7만 원입니다. 숫자는 계산 예시일 뿐 KT클라우드의 현재 요금이 아닙니다. 기존 웹호스팅이 월 1만 원대이고 CPU 제한이나 관리 권한 때문에 불편한 일이 없다면 옮길 이유가 약합니다. 서버 패치, 방화벽, 장애 대응을 직접 맡는 시간까지 넣으면 차이는 더 커집니다.

그런데 특정 작업 때문에 관리자 권한이 필요하거나, 접속량에 맞춰 자원을 늘려야 하거나, 서비스별로 서버를 분리해야 한다면 클라우드가 맞을 수 있습니다. 이때도 처음부터 큰 사양을 고르기보다 측정값을 남기고 필요한 부분을 늘리는 쪽이 비용을 통제하기 쉽습니다.

이전 전에 복구 절차를 한 번 실행한다

KT클라우드 공식 매뉴얼에는 운영 중인 서버의 루트 볼륨과 데이터 볼륨을 함께 담는 서버 스냅샷 기능이 안내돼 있습니다. 편리하지만 스냅샷 하나만으로 백업이 끝났다고 보지는 않습니다. 데이터베이스가 쓰기 작업을 하는 순간에 찍은 이미지라면 복구 후 데이터가 기대한 상태인지 확인해야 합니다. 데이터베이스 백업 파일을 별도로 만들고, 다른 저장 위치에 보관하고, 실제로 복원해 보는 절차가 필요합니다.

이전 하루 전: 파일과 데이터베이스를 백업하고 복원에 걸린 시간을 기록한다.
새 서버 준비: 운영체제, 웹서버, 런타임 버전과 시간대, 파일 권한, 방화벽 규칙을 맞춘다.
전환 직전: 쓰기 작업을 잠시 멈추고 마지막 변경분을 복사한다. 주문이나 문의가 들어오는 사이트라면 누락 여부를 대조한다.
전환 후: 주요 페이지, 로그인, 결제 또는 문의 전송, 예약 작업을 직접 확인한다. 기존 서버는 바로 지우지 않는다.

도메인 설정을 바꾸기 전에는 새 서버에서 서비스가 제대로 열리는지 시험해야 합니다. 전환 뒤 일부 이용자가 한동안 기존 서버에 접속할 수도 있으므로 두 서버의 데이터가 갈라지는 상황을 특히 조심합니다. 되돌리는 기준도 미리 적어 둡니다. 예를 들어 오류율이 일정 수준을 넘거나 결제 확인이 실패하면 이전 설정으로 돌린다는 식입니다. 되돌릴 수 있는 시간과 담당자가 정해져 있어야 장애 중에 판단이 빨라집니다.

장애가 나면 접속 경로부터 좁힌다

사이트가 열리지 않을 때 서버를 재시작하는 일부터 하면 원인 기록이 사라질 수 있습니다. 저는 외부에서 접속되는지, 도메인 설정이 올바른지, 인증서 상태가 정상인지 확인합니다. 그다음 방화벽과 포트, 웹서버 프로세스, 애플리케이션 로그, 데이터베이스 연결 순서로 내려갑니다. 화면이 느리다면 CPU 사용률만 보지 말고 메모리 부족, 디스크 공간과 대기 시간, 특정 요청의 응답 시간을 같이 봅니다.

KT클라우드에는 자원 상태를 확인하고 알람을 설정하는 모니터링 기능이 안내돼 있습니다. 다만 가상머신 지표가 정상이어도 로그인이나 결제 화면은 실패할 수 있습니다. 중요한 화면은 외부 접속 시험과 애플리케이션 오류 알림을 따로 두는 편이 좋습니다. 알림을 받는 사람, 확인 시간, 첫 조치도 적어 두면 새벽 장애에 덜 흔들립니다.

서버 사양은 처음부터 맞히는 숫자가 아닙니다. 작은 구성으로 시작해 바쁜 시간의 지표를 확인하고, 복구 시험에서 걸린 시간을 기준으로 백업을 손보면 됩니다. 14년간 운영하면서 더 자주 비용을 아껴 준 것은 큰 서버보다 정확한 기록과 한 번 검증한 복구 절차였습니다.