클라우드는 크게 시작할수록 손해가 나는 경우가 많습니다
얼마 전 지인이 작은 쇼핑몰을 클라우드로 옮기고 싶다고 해서 견적을 봤는데, 월 방문자 3만 명 사이트에 처음부터 4코어 16GB 서버와 관리형 데이터베이스, 로드밸런서까지 들어가 있었습니다. 틀린 구성은 아닙니다. 다만 과했습니다. 실제 로그를 보면 동시 접속은 피크 때 18명 정도였고, 이미지도 대부분 외부 스토리지에 올라가 있었습니다. 이런 경우는 2코어 4GB VPS급 클라우드 인스턴스 하나로도 꽤 오래 버팁니다.
클라우드가 비싼 이유는 성능이 좋아서만은 아닙니다. 필요한 만큼 쓴다는 말 뒤에, 켜둔 만큼 계속 과금된다는 조건이 붙습니다. 서버 한 대는 싸 보여도 스냅샷, 트래픽, 디스크, 백업 보관, 공인 IP, 모니터링까지 붙으면 월 비용이 훅 올라갑니다. 그래서 저는 클라우드를 고를 때 요금제 이름보다 먼저 트래픽과 동시 접속을 봅니다.
먼저 방문자가 아니라 동시 접속을 계산합니다
사이트 서버 사양을 잡을 때 월 방문자 수만 보면 자주 틀립니다. 월 10만 방문자라도 하루 종일 고르게 들어오면 서버 부담은 낮습니다. 반대로 이벤트 문자 한 번에 5분 동안 몰리면 월 방문자가 적어도 서버가 멈춥니다. 운영에서는 평균보다 피크가 중요합니다.
대략 계산은 이렇게 합니다. 하루 방문자 3,000명, 방문당 페이지뷰 3회, 사용자가 한 페이지에 머무는 시간이 평균 30초라면 하루 페이지뷰는 9,000회입니다. 하루 24시간으로 단순 평균을 내면 별것 아니지만, 실제 트래픽은 보통 특정 시간대에 몰립니다. 피크 2시간에 전체의 30%가 들어온다고 보면 2시간 동안 2,700 페이지뷰입니다. 초당 요청으로 바꾸면 약 0.4회 수준입니다. 여기에 이미지, CSS, 스크립트 요청이 붙지만 정적 파일 캐시가 잡혀 있으면 애플리케이션 서버까지 매번 때리지는 않습니다.
워드프레스나 일반 PHP 게시판 기준으로 캐시가 켜져 있고 DB 쿼리가 무난하면 2코어 2GB도 월 수만 방문자는 처리합니다. 다만 관리자 페이지, 검색, 장바구니, 결제, 회원 기능이 많으면 이야기가 달라집니다. 같은 방문자 수라도 정적 블로그와 쇼핑몰은 서버가 받는 압력이 다릅니다.
- 개인 블로그, 회사 소개 사이트: 1코어 1GB에서 시작 가능
- 워드프레스 블로그, 소규모 랜딩 여러 개: 2코어 2GB 권장
- 소형 쇼핑몰, 회원 기능 있는 사이트: 2코어 4GB부터 검토
- 검색, 주문, 관리자 작업이 많은 서비스: DB 분리 여부부터 확인
클라우드 비용은 서버보다 주변 과금에서 새는 경우가 많습니다
초보자가 클라우드 견적을 볼 때 인스턴스 월 요금만 봅니다. 그런데 실제 청구서를 보면 디스크와 트래픽, 스냅샷 비용이 같이 붙습니다. 특히 백업을 매일 찍고 30일 보관하면 디스크 사용량이 생각보다 빨리 늘어납니다. 50GB 서버라고 해서 백업도 50GB만 쓰는 게 아닙니다. 변경량과 보관 주기에 따라 누적됩니다.
예를 들어 월 2만 원짜리 서버를 골랐는데 블록 스토리지 100GB, 스냅샷 30일, 아웃바운드 트래픽, 관리형 DB까지 붙이면 월 7만 원을 넘는 일이 흔합니다. 이 금액이 나쁜 건 아닙니다. 다만 사이트 매출이나 중요도에 맞지 않으면 낭비입니다. 반대로 매출이 하루 100만 원인 쇼핑몰이 백업 비용 아끼려고 수동 백업만 믿는 것도 위험합니다.
저는 보통 처음에는 서버 1대, 자동 백업 7일, 별도 원격 백업 주 1회 정도로 시작합니다. 그리고 트래픽이 늘면 웹 서버와 DB를 나누고, 그 다음 캐시 서버나 로드밸런서를 붙입니다. 처음부터 모든 부품을 올리는 구성은 운영자가 시스템을 잘 아는 경우에나 의미가 있습니다. 모르면 장애 지점만 늘어납니다.
클라우드 이전 전에 백업부터 검증해야 합니다
사이트 이전에서 제일 많이 터지는 지점은 서버 생성이 아닙니다. 백업입니다. 파일은 옮겼는데 DB 문자셋이 깨지거나, 업로드 폴더 권한이 안 맞거나, SSL 인증서 갱신 경로가 달라져서 며칠 뒤 장애가 납니다. 그래서 이전 작업은 복사보다 검증이 더 중요합니다.
최소한 이전 전에는 세 가지를 확인해야 합니다. 첫째, 파일 백업과 DB 백업 시간이 같은 시점에 가까운지 봐야 합니다. 둘째, 새 서버에서 복원 테스트를 한 번 해야 합니다. 셋째, DNS 변경 전에 임시 접속으로 로그인, 글쓰기, 결제, 메일 발송 같은 기능을 직접 눌러봐야 합니다. 눈으로 첫 화면만 뜬다고 이전이 끝난 게 아닙니다.
- DB 덤프 파일 용량이 지나치게 작지 않은지 확인
- 업로드 폴더와 캐시 폴더 권한 확인
- PHP, Node, Java 등 런타임 버전 차이 확인
- SSL 인증서 자동 갱신 방식 확인
- DNS TTL을 이전 하루 전 낮춰두기
특히 DNS TTL은 자주 놓칩니다. 기존 값이 24시간이면 서버를 옮긴 뒤에도 사용자 일부는 하루 동안 예전 서버로 들어갑니다. 이 상태에서 게시글이나 주문이 양쪽으로 나뉘면 복구가 피곤해집니다. 이전 전날 TTL을 300초 정도로 낮춰두면 전환 시간이 훨씬 짧아집니다.
장애가 났을 때는 서버 증설보다 로그가 먼저입니다
사이트가 느려지면 많은 분들이 바로 서버를 키웁니다. 2코어를 4코어로 올리고, 메모리를 4GB에서 8GB로 올립니다. 그런데 장애 원인이 디스크 가득 참, DB 연결 제한, SSL 만료, 특정 플러그인 오류라면 증설해도 그대로입니다. 클라우드는 버튼 몇 번으로 키울 수 있어서 오히려 원인 확인을 건너뛰기 쉽습니다.
장애 때는 순서를 정해두는 게 좋습니다. 먼저 모니터링에서 CPU, 메모리, 디스크, 네트워크를 봅니다. 그 다음 웹 서버 에러 로그와 애플리케이션 로그를 봅니다. DB가 있다면 슬로우 쿼리와 연결 수를 확인합니다. 이 네 가지를 보면 대개 방향이 잡힙니다. CPU가 낮은데 사이트가 느리면 서버 사양 문제가 아닐 가능성이 큽니다.
- CPU 90% 이상 지속: 캐시 미적용, 과한 동적 요청, 배치 작업 확인
- 메모리 부족: PHP 워커 수, DB 버퍼, 플러그인 과다 확인
- 디스크 90% 이상: 로그 누적, 백업 파일 방치, 업로드 폭증 확인
- DB 응답 지연: 인덱스, 슬로우 쿼리, 동시 연결 수 확인
- 간헐적 502 오류: 웹 서버와 애플리케이션 프로세스 연결 확인
운영을 오래 하다 보면 큰 장애는 복잡한 기술보다 기본값에서 많이 납니다. 로그 로테이션이 안 되어 디스크가 꽉 차고, 백업이 같은 서버 안에만 있고, 인증서 갱신 실패 알림을 아무도 안 봅니다. 클라우드라고 이런 문제가 자동으로 사라지지는 않습니다.
처음 구성은 작게, 백업과 관측은 제대로 잡는 편이 낫습니다
클라우드를 처음 쓰는 사이트라면 저는 작게 시작하는 쪽을 더 선호합니다. 2코어 2GB나 2코어 4GB로 시작하고, 캐시와 백업, 모니터링을 제대로 잡습니다. 그 상태에서 일주일 정도 실제 CPU 사용률, 메모리 여유, 피크 시간 응답 속도를 봅니다. 수치가 부족하면 올리면 됩니다. 클라우드의 장점은 처음부터 크게 사는 게 아니라, 부족할 때 빠르게 키울 수 있다는 데 있습니다.
다만 백업은 작게 잡으면 안 됩니다. 서버 사양은 낮춰도 백업은 분리해야 합니다. 같은 서버 안에 백업 파일을 두는 건 편하지만, 디스크 장애나 계정 침해가 생기면 같이 날아갑니다. 최소 주 1회는 다른 저장소로 빠져야 하고, 중요한 사이트는 매일 자동 백업과 월 1회 장기 보관을 둡니다. 복원 테스트도 가끔 해야 합니다. 백업 파일이 있다는 것과 복원이 된다는 것은 다른 말입니다.
클라우드는 좋은 도구입니다. 하지만 좋은 도구일수록 대충 쓰면 비용과 복잡도가 빨리 늘어납니다. 서버를 크게 잡기 전에 동시 접속, 캐시 여부, DB 부하, 백업 보관 기간을 먼저 숫자로 적어보면 과한 견적은 꽤 많이 걸러집니다. 제 경험상 작은 사이트는 성능보다 운영 습관 때문에 더 자주 멈춥니다.
