얼마 전 작은 쇼핑몰 이전 상담을 했는데, 월 방문자 3만 명 정도인 사이트에 8코어 16GB 클라우드서버 견적이 잡혀 있었습니다. 서버가 넉넉하면 마음은 편합니다. 그런데 실제 장애 원인은 CPU가 부족해서가 아니라 PHP 메모리 제한, 느린 DB 쿼리, 백업 누락, DNS 변경 실수인 경우가 훨씬 많습니다. 저는 클라우드서버를 고를 때 먼저 트래픽을 숫자로 쪼갭니다. 그다음 CPU, 메모리, 디스크, 네트워크를 따로 봅니다.
트래픽보다 동시접속부터 계산하기
월 방문자 수만 보고 서버를 고르면 과하게 잡기 쉽습니다. 월 10만 방문자라고 해도 하루 평균은 3천 명 남짓이고, 실제 피크 시간이 2시간이면 그 시간에 몰리는 요청 수가 중요합니다. 예를 들어 피크 시간에 600명이 들어오고 한 사람이 5페이지를 본다면 2시간 동안 3천 페이지뷰입니다. 초당으로 나누면 평균 0.4페이지뷰 수준입니다. 이미지와 스크립트 요청까지 합치면 초당 요청 수는 더 커지지만, 정적 파일을 캐시하거나 CDN에 넘기면 웹서버 부담은 크게 줄어듭니다.
실무에서는 동시접속을 보수적으로 잡아도 작은 기업 홈페이지나 블로그는 1코어 1GB, 워드프레스는 1코어 2GB부터 시작해도 버티는 경우가 많습니다. 방문자가 갑자기 몰리는 이벤트 페이지, 광고 랜딩, 예약 오픈 페이지는 이야기가 다릅니다. 순간 피크가 평균의 10배 이상 튀기 때문에 평소 트래픽 기준으로 잡으면 바로 병목이 납니다.
- 회사 소개형 사이트: 1코어 1GB 또는 공유 호스팅으로 충분한 경우가 많음
- 워드프레스 블로그: 1코어 2GB, 캐시 적용 시 월 수만 방문자도 가능
- 작은 쇼핑몰: 2코어 4GB부터 보고 DB와 이미지 처리를 따로 확인
- 이벤트 랜딩: 평균 방문자보다 순간 접속자 기준으로 산정
CPU보다 메모리와 DB가 먼저 막힌다
클라우드서버 장애 로그를 보면 CPU 100퍼센트보다 메모리 부족으로 프로세스가 죽는 상황이 더 흔합니다. 특히 워드프레스, 쇼핑몰 솔루션, 관리자 페이지가 무거운 서비스는 PHP 작업자 수와 DB 연결 수가 같이 올라갑니다. 1GB 메모리 서버에서 웹서버, PHP, DB를 한꺼번에 돌리면 평소에는 멀쩡해 보여도 백업이나 이미지 리사이즈가 도는 순간 스왑이 터집니다.
CPU는 짧게 치고 빠지는 작업에 강합니다. 반면 메모리는 한 번 부족하면 전체가 느려집니다. 그래서 저는 1GB 서버를 쓸 때 DB까지 올릴지 먼저 의심합니다. 단순 정적 사이트면 괜찮지만, CMS와 DB가 함께 있으면 2GB부터 보는 편이 낫습니다. 운영 중인 서버라면 7일 정도의 피크 시간 메모리 사용량, DB 슬로우 쿼리, 웹서버 동시 연결 수를 같이 봐야 합니다.
대략적인 시작점
- 정적 사이트: 1코어 512MB에서 1GB
- 소규모 CMS: 1코어 2GB
- 상품 수가 적은 쇼핑몰: 2코어 4GB
- 검색, 예약, 회원 기능이 많은 서비스: 2코어 8GB 이상 또는 DB 분리
여기서 중요한 건 시작점이라는 점입니다. 처음부터 큰 서버를 사는 것보다 모니터링을 붙여놓고 한 단계씩 올리는 쪽이 운영비를 덜 태웁니다. 클라우드서버는 사양 변경이 쉬운 편이라, 초기에 과한 견적을 고집할 이유가 적습니다.
디스크는 용량보다 백업 방식을 먼저 본다
디스크 100GB가 필요하다는 말을 들으면 저는 먼저 파일 종류를 묻습니다. 실제 서비스 데이터인지, 로그인지, 백업 파일인지에 따라 대처가 다릅니다. 운영 서버 안에 백업 압축 파일이 계속 쌓여서 디스크가 꽉 차는 사고를 많이 봤습니다. 이건 서버 사양 문제가 아니라 운영 방식 문제입니다.
웹소스와 DB 백업은 운영 서버와 다른 저장소에 있어야 합니다. 최소한 매일 1회 DB 백업, 주 1회 전체 파일 백업, 최근 7일 보관 정도는 잡아야 합니다. 쇼핑몰처럼 주문 데이터가 중요한 곳은 하루 1회로 부족할 수 있습니다. 주문이 많은 시간대라면 DB 덤프 주기와 스냅샷 주기를 나눠야 합니다.
- 로그: 보관 기간을 정하고 자동 삭제
- 업로드 이미지: 별도 스토리지 또는 주기적 압축 보관
- DB 백업: 복구 테스트까지 포함
- 스냅샷: 서버 전체 복원용으로 쓰되 유일한 백업으로 믿지 않기
백업은 있는 것보다 돌아오는 것이 중요합니다. 복원 명령을 한 번도 쳐보지 않은 백업은 사고 때 믿기 어렵습니다. 새 클라우드서버를 만들고 DB를 올린 뒤 로그인, 주문, 게시글 작성까지 확인해야 진짜 백업입니다.
이전 작업은 DNS보다 데이터 동결 시간이 중요하다
클라우드서버로 이전할 때 가장 많이 나는 실수는 DNS만 바꾸면 끝난다고 생각하는 겁니다. 실제로는 데이터가 움직이는 시간이 더 중요합니다. 게시판이나 쇼핑몰처럼 계속 데이터가 바뀌는 사이트는 이전 직전 글쓰기와 주문 처리를 잠깐 막거나, 최종 DB 동기화 시간을 아주 짧게 잡아야 합니다.
DNS TTL은 이전 하루 전쯤 낮춰두면 좋습니다. 그래야 새 서버로 전환했을 때 전파 지연을 줄일 수 있습니다. 다만 TTL을 낮췄다고 모든 사용자가 즉시 새 서버를 보는 건 아닙니다. 통신사 캐시나 사용자 환경 때문에 구서버와 신서버가 잠깐 섞일 수 있습니다. 그래서 이전 직후에는 구서버에도 접근 로그를 남겨 누가 아직 들어오는지 확인합니다.
- 이전 전: 백업 생성, 복원 테스트, SSL 인증서 준비
- 이전 중: DB 최종 동기화, 파일 권한 확인, 관리자 로그인 확인
- 전환 후: 접속 로그, 오류 로그, 주문과 메일 발송 확인
- 하루 뒤: 구서버 트래픽이 거의 없는지 확인 후 종료
장애가 났을 때는 큰 것부터 보지 않는다
사이트가 느리거나 죽으면 서버 증설부터 누르는 경우가 있습니다. 급한 마음은 이해합니다. 근데 순서를 잘못 잡으면 돈만 쓰고 원인은 그대로 남습니다. 저는 먼저 디스크 사용량, 메모리 부족 로그, 웹서버 오류 로그, DB 연결 수, 최근 배포와 설정 변경 이력을 봅니다. 실제로는 인증서 만료, 권한 변경, 로그 디스크 포화, 백업 스크립트 폭주 같은 문제가 많습니다.
클라우드서버는 좋은 도구지만 운영을 대신해주지는 않습니다. 작은 사이트는 싼 요금제로도 충분히 안정적으로 운영할 수 있습니다. 대신 백업이 분리되어 있고, 복구 절차가 확인되어 있고, 피크 시간의 숫자를 알고 있어야 합니다. 저는 서버비를 더 쓰기 전에 그 세 가지가 먼저라고 봅니다. 필요한 만큼만 쓰는 인프라가 오래 갑니다.
