얼마 전 작은 쇼핑몰 이전을 봐줬는데, 월 방문자 3만 명짜리 사이트에 8코어 서버를 쓰고 있었습니다. 장애가 자주 난다길래 사양부터 봤더니 CPU는 거의 놀고 있었고, 문제는 백업 압축 작업이 피크 시간에 돌면서 디스크 입출력을 막는 구조였습니다. 클라우드서버는 비싼 걸 고르면 안전해지는 물건이 아닙니다. 먼저 트래픽과 동시접속을 숫자로 바꾸고, 그 다음에 CPU, 메모리, 디스크, 백업 방식을 맞춰야 합니다.
클라우드서버는 방문자 수보다 동시접속으로 봐야 합니다
월 방문자 10만 명이라는 말은 서버 입장에서 별로 정확한 지표가 아닙니다. 하루에 고르게 들어오는 10만 명과 광고 집행 후 30분에 몰리는 10만 명은 완전히 다릅니다. 운영할 때는 월 트래픽보다 피크 시간 요청 수와 동시접속을 먼저 봅니다.
대략 계산은 이렇게 합니다. 하루 방문자 3천 명, 1인당 페이지 3개, 페이지당 요청 40개라면 하루 요청은 36만 개입니다. 이게 24시간 고르게 오면 별일 아닙니다. 그런데 실제로는 특정 2~3시간에 몰립니다. 피크 시간에 전체의 30%가 들어오면 10만 요청 이상이 짧은 시간에 들어오고, 이미지가 많거나 워드프레스 플러그인이 무거우면 체감 부하는 더 커집니다.
- 회사 소개형 사이트: 1코어, 메모리 1~2GB로도 충분한 경우가 많습니다.
- 워드프레스 블로그: 캐시 적용 기준 1~2코어, 메모리 2GB부터 시작해도 됩니다.
- 소규모 쇼핑몰: 2코어, 메모리 4GB 이상에서 시작하고 DB 부하를 따로 봐야 합니다.
- 광고 유입이 잦은 랜딩 페이지: 서버 사양보다 캐시, 이미지 용량, CDN 설정이 먼저입니다.
근데 숫자만 보고 바로 큰 요금제로 가는 건 별로 좋지 않습니다. 클라우드서버의 장점은 올리기 쉽다는 점입니다. 처음부터 과하게 잡기보다 모니터링을 켜고 1~2주 실제 사용량을 본 뒤 올리는 쪽이 비용도 덜 새고 판단도 정확합니다.
CPU, 메모리, 디스크는 각각 병목이 다릅니다
서버가 느리다고 해서 무조건 CPU를 올리면 낭비가 생깁니다. 웹서버 운영에서 CPU가 부족한 경우도 있지만, 실무에서는 메모리 부족으로 스왑이 터지거나 디스크 입출력이 막히는 경우를 더 자주 봅니다. 특히 백업, 로그 압축, 이미지 리사이징, DB 덤프가 겹치면 방문자가 많지 않아도 사이트가 멈춘 것처럼 보입니다.
CPU는 동적 처리량을 봅니다
PHP, Node, Python 같은 애플리케이션이 매 요청마다 많은 연산을 한다면 CPU가 중요합니다. 관리자 화면, 검색, 주문 처리, 회원 기능이 많을수록 CPU 사용률이 튑니다. 반대로 정적 페이지나 캐시된 페이지 위주라면 1코어 서버도 꽤 오래 버팁니다. CPU 사용률이 평소 20% 안팎인데 순간적으로만 치솟는다면 사양보다 캐시와 작업 스케줄을 먼저 봐야 합니다.
메모리는 여유가 있어야 장애가 덜 납니다
메모리는 조금 남는 게 좋습니다. 리눅스는 남는 메모리를 캐시로 쓰기 때문에 사용률이 높아 보여도 정상일 수 있지만, 스왑 사용량이 계속 늘면 이야기가 다릅니다. 워드프레스에 플러그인이 많고 DB까지 같은 서버에 있으면 1GB는 금방 답답해집니다. 개인 블로그라도 관리자 화면이 느리거나 업데이트 중 오류가 난다면 2GB 이상을 권합니다.
디스크는 용량보다 입출력이 중요합니다
많이 놓치는 지점이 디스크입니다. 용량 50GB가 남아 있어도 입출력이 낮으면 백업 하나에 사이트가 버벅입니다. 이미지 업로드가 많은 사이트, 로그가 빠르게 쌓이는 서비스, DB 테이블이 큰 쇼핑몰은 디스크 성능을 따로 봐야 합니다. 자동 백업을 켰다고 안심하기보다 백업이 언제 돌고, 복원은 몇 분 안에 되는지 확인하는 게 더 중요합니다.
처음 구성은 작게, 백업은 처음부터 제대로
클라우드서버를 처음 쓰는 분들이 가장 많이 하는 실수는 서버 생성 후 사이트만 올리고 끝내는 겁니다. 운영은 사이트가 뜨는 순간부터 시작입니다. 장애는 밤에 오고, 백업은 필요할 때 없고, SSL 인증서는 주말에 만료됩니다. 그래서 저는 저가 요금제를 쓰더라도 백업과 알림은 꼭 먼저 잡습니다.
- 서버 스냅샷은 최소 주 1회, 변경 많은 사이트는 매일 잡습니다.
- DB 백업은 파일 백업과 분리해서 보관합니다.
- 백업 파일은 같은 서버 안에만 두지 않습니다.
- 복원 테스트를 한 번은 직접 해봅니다.
- 디스크 사용률 80% 전후에서 알림이 오게 설정합니다.
- SSL 만료 알림은 서버 안이 아니라 외부 알림으로 받는 편이 안전합니다.
솔직히 백업은 재미없는 작업입니다. 그런데 장애 대응에서 제일 잔인한 질문은 늘 같습니다. “어제 상태로 돌릴 수 있나요?” 이 질문에 바로 답할 수 있으면 절반은 이긴 겁니다. 클라우드서버 요금제를 한 단계 올리는 것보다 백업 구조를 제대로 만드는 쪽이 실제 안전성에는 더 크게 작용합니다.
요금제 비교는 트래픽 단가와 운영 시간을 같이 봅니다
같은 2코어, 메모리 4GB라도 서비스마다 네트워크 정책, 디스크 성능, 스냅샷 비용, 초과 트래픽 과금 방식이 다릅니다. 월 요금만 보면 싸 보이는데 백업과 트래픽을 붙이면 비슷해지는 경우가 많습니다. 반대로 방문자가 적은 사이트는 무료 티어 또는 저가 VPS로 충분한 구간도 분명히 있습니다.
예를 들어 회사 소개 사이트, 포트폴리오, 소규모 블로그는 캐시와 이미지 최적화만 되어 있으면 고성능 클라우드서버가 필요하지 않습니다. 하루 방문자 500명 이하, 동시접속 10명 안팎이라면 1코어에 메모리 1~2GB로 시작해도 무리가 없는 경우가 많습니다. 여기서 중요한 건 싼 서버를 쓰는 게 아니라, 싼 서버로 충분한 구조를 만드는 겁니다.
반대로 쇼핑몰, 예약 서비스, 강의 사이트처럼 결제나 로그인 상태가 많은 사이트는 캐시로 덮을 수 없는 요청이 많습니다. 이 구간부터는 서버 사양뿐 아니라 DB 분리, 세션 저장소, 파일 저장 방식까지 봐야 합니다. 접속자가 많지 않아도 주문이 몰리는 10분에 서버가 버티지 못하면 매출 손실이 바로 보입니다.
장애가 났을 때는 순서대로 확인해야 빨리 잡힙니다
사이트가 죽으면 마음이 급해져서 이것저것 누르게 됩니다. 그런데 서버 운영은 순서가 중요합니다. 먼저 도메인, SSL, 웹서버, 애플리케이션, DB, 디스크, 네트워크를 나눠서 봐야 합니다. 전부 한 덩어리로 보면 원인을 찾기 어렵습니다.
- 도메인 응답이 정상인지 확인합니다.
- SSL 인증서 만료나 갱신 실패가 있는지 봅니다.
- 웹서버 프로세스가 살아 있는지 확인합니다.
- 애플리케이션 로그에서 500 오류를 찾습니다.
- DB 연결 수와 느린 쿼리를 확인합니다.
- 디스크 용량과 inode 부족 여부를 봅니다.
- 최근 배포, 플러그인 업데이트, 보안 설정 변경을 되짚습니다.
경험상 트래픽 폭증보다 설정 변경이 원인인 경우가 많습니다. 방화벽 규칙 하나, PHP 버전 변경, 자동 갱신 실패, 권한 변경, 로그 폭증 같은 것들이 사이트를 멈춥니다. 그래서 클라우드서버를 운영할 때는 변경 내역을 짧게라도 남기는 습관이 좋습니다. 어제 뭘 바꿨는지 알면 복구 시간이 확 줄어듭니다.
제 기준에서 좋은 클라우드서버 운영은 큰 서버를 쓰는 게 아닙니다. 현재 트래픽에 맞는 크기로 시작하고, 병목을 숫자로 확인하고, 백업과 복원 경로를 미리 만들어 두는 겁니다. 작은 서버라도 이렇게 굴리면 오래 안정적으로 갑니다. 반대로 비싼 서버도 백업이 없고 알림이 없으면 장애 앞에서는 꽤 허술합니다.
