클라우드서버 처음 고를 때 과금 폭탄 피하는 방법

장애는 사양보다 계산 실수에서 먼저 납니다

얼마 전 작은 쇼핑몰 이전 상담을 했는데, 월 방문자 3만 명 정도인 사이트에 8코어 16GB 클라우드서버를 쓰고 있었습니다. 트래픽이 폭발해서 그런 게 아니었습니다. 예전 담당자가 “클라우드는 넉넉하게 잡아야 안전하다”고 해서 그대로 둔 겁니다. 실제로 로그를 보니 피크 시간 동시 접속은 25명 안팎, PHP 작업자도 대부분 놀고 있었습니다. 2코어 4GB로 내려도 충분했고, 이미지 캐시만 제대로 잡으면 더 낮춰도 됐습니다.

클라우드서버는 좋은 도구입니다. 필요한 만큼 늘리고 줄일 수 있고, 스냅샷과 방화벽, 로드밸런서 같은 기능도 붙이기 쉽습니다. 그런데 이 장점 때문에 오히려 과하게 씁니다. “나중에 늘릴 수 있다”는 말이 맞다면 처음부터 크게 살 이유도 없습니다. 먼저 현재 트래픽과 프로그램 구조를 보고, 그다음 사양을 정하는 쪽이 맞습니다.

클라우드서버 사양은 동시접속부터 잡는 방법

서버 사양을 볼 때 월 방문자 수만 보고 판단하면 자주 빗나갑니다. 월 10만 방문자라도 대부분 검색 유입이고 페이지가 가볍다면 저사양으로도 버팁니다. 반대로 월 2만 방문자라도 예약, 결제, 관리자 엑셀 다운로드가 무겁다면 순간 부하가 큽니다.

저는 보통 이렇게 봅니다. 먼저 피크 시간의 동시 접속을 잡습니다. 단순 블로그나 회사 소개 사이트라면 동시 접속 20명까지는 1코어 1GB 또는 2GB로도 운영되는 경우가 많습니다. 워드프레스에 플러그인이 많고 관리자 작업이 잦다면 2코어 2GB부터 보는 편이 안전합니다. 쇼핑몰처럼 장바구니, 로그인, 결제가 붙으면 2코어 4GB를 최소선으로 잡고 실제 쿼리 시간을 확인합니다.

개인 블로그, 작은 랜딩 페이지: 1코어 1~2GB
워드프레스 일반 사이트: 2코어 2GB
플러그인 많은 워드프레스, 소규모 쇼핑몰: 2코어 4GB
이벤트 페이지, 광고 집행 기간: 평소 사양보다 캐시와 대역폭을 먼저 점검
관리자 통계, 검색, 대량 업로드가 많은 서비스: CPU보다 DB I/O 확인 우선

여기서 중요한 건 CPU 코어 수보다 병목 위치입니다. 웹서버가 Nginx인지 Apache인지, PHP-FPM 작업자 수가 몇 개인지, DB가 같은 서버에 있는지, 이미지가 원본 그대로 나가는지에 따라 필요한 사양이 달라집니다. 4코어로 올렸는데도 느린 사이트를 보면 대개 DB 인덱스가 없거나, 캐시가 꺼져 있거나, 백업 작업이 낮 시간에 돌고 있습니다.

요금제 비교는 월 트래픽과 디스크 쓰기량까지 봅니다

클라우드서버 요금은 서버 월 비용만 보면 안 됩니다. 저장공간, 스냅샷, 외부 전송량, 공인 IP, 로드밸런서, 관리형 DB가 따로 붙는 경우가 있습니다. 처음 견적은 싸 보이는데 실제 청구서가 커지는 지점이 여기입니다.

예를 들어 이미지가 많은 사이트가 하루 1만 페이지뷰를 냅니다. 페이지당 이미지와 정적 파일을 합쳐 3MB가 나간다면 하루 전송량은 약 30GB, 한 달이면 900GB입니다. 이 정도면 서버 사양보다 전송량 과금과 이미지 최적화가 먼저입니다. 반대로 텍스트 위주의 블로그는 하루 1만 페이지뷰여도 페이지당 500KB면 한 달 150GB 수준입니다. 같은 방문자 수라도 청구 구조가 다릅니다.

디스크도 넉넉히만 잡으면 답이 아닙니다. 사이트 파일 20GB, DB 5GB라면 50GB 디스크로도 당장 운영은 됩니다. 하지만 백업 압축 파일을 서버 안에 같이 쌓으면 금방 찹니다. 로그가 큰 사이트는 일주일 만에 수십 GB가 생기기도 합니다. 디스크 사용률이 90%를 넘으면 DB가 멈추거나 세션 파일을 못 써서 로그인 장애가 납니다. 트래픽보다 이런 사고가 더 흔합니다.

처음 구축할 때 빠뜨리면 나중에 비싸지는 설정

클라우드서버를 만들고 웹서버만 올리면 끝이라고 생각하기 쉽습니다. 실제 운영에서는 기본 설정이 더 중요합니다. 방화벽, SSH 접속 정책, 자동 업데이트 범위, 시간대, 로그 순환, 백업 주기, 모니터링 알림이 먼저 잡혀야 합니다.

SSH는 비밀번호 접속을 막고 키 기반으로 제한하는 게 기본입니다. 관리자 IP가 고정이면 접속 허용 대역을 좁히는 편이 좋습니다. 웹 포트는 80과 443만 열고, DB 포트는 외부에 열지 않는 구성이 보통 안전합니다. 관리형 DB를 쓰더라도 허용 IP와 계정 권한을 확인해야 합니다.

백업은 “있다”가 아니라 “복구해 봤다”가 기준입니다. 서버 스냅샷만 믿으면 애매한 경우가 있습니다. 스냅샷은 서버 전체를 특정 시점으로 되돌리기 좋지만, 특정 게시글이나 특정 DB 테이블만 살리기에는 불편합니다. 저는 보통 스냅샷과 파일 백업, DB 덤프를 나눕니다. DB는 매일, 파일은 변경량에 따라 매일 또는 주 2~3회, 스냅샷은 큰 업데이트 전후로 잡습니다.

서버 스냅샷: 전체 장애 복구용
DB 덤프: 게시글, 주문, 회원 데이터 복구용
파일 백업: 업로드 이미지, 첨부파일 복구용
외부 저장소 보관: 서버 디스크 손상이나 계정 잠김 대비

근데 백업을 같은 서버 안에만 두는 경우가 아직 많습니다. 이건 백업이라기보다 임시 복사본에 가깝습니다. 서버가 삭제되거나 디스크가 깨지면 같이 사라집니다. 최소한 다른 스토리지나 다른 계정에 한 벌은 있어야 합니다.

이전 작업은 DNS보다 데이터 동결 시간이 관건입니다

클라우드서버로 이전할 때 가장 많이 터지는 지점은 DNS가 아닙니다. 데이터가 바뀌는 사이트에서 동결 시간을 안 잡는 게 문제입니다. 블로그처럼 댓글이 거의 없는 사이트는 간단합니다. 파일과 DB를 옮기고, 새 서버에서 확인한 뒤 DNS를 바꾸면 됩니다. 하지만 쇼핑몰이나 예약 사이트는 이전 중에도 주문과 회원 가입이 생깁니다.

이런 사이트는 먼저 TTL을 낮춰 둡니다. 보통 이전 하루 전쯤 DNS TTL을 300초 정도로 낮추면 전환이 편합니다. 그다음 새 서버에 파일을 옮기고, DB를 1차 복제합니다. 실제 전환 시점에는 관리자 기능을 잠시 막거나 주문 접수를 멈춘 뒤 DB를 다시 덤프해서 넣습니다. 이 짧은 동결 시간이 있어야 데이터가 갈라지지 않습니다.

SSL도 미리 봐야 합니다. 인증서 자동 갱신이 제대로 잡혀 있는지, 웹서버 재시작 없이 갱신 반영이 되는지, 리버스 프록시 뒤에 있을 때 원래 접속 프로토콜을 애플리케이션이 제대로 인식하는지 확인합니다. 여기서 틀어지면 무한 리다이렉트, 로그인 풀림, 혼합 콘텐츠 경고가 납니다.

장애가 났을 때는 큰 사양부터 올리지 않습니다

사이트가 느려지면 가장 먼저 서버를 키우는 경우가 많습니다. 급한 불을 끄는 데는 도움이 될 수 있습니다. 하지만 원인을 안 본 채로 올리면 다음 달 비용만 커지고 같은 장애가 반복됩니다. 저는 장애가 나면 순서를 정해 봅니다.

디스크 사용률과 inode 고갈 여부
CPU 사용률이 사용자 프로세스인지, I/O 대기인지
메모리 부족과 스왑 사용량
웹서버 에러 로그와 502, 504 비율
DB 슬로우 쿼리와 잠금 대기
외부 API, 결제 모듈, 문자 발송 지연

CPU가 100%라도 무조건 CPU 부족은 아닙니다. PHP 프로세스가 무한히 늘어나는 구조일 수도 있고, 특정 봇이 검색 페이지를 계속 때릴 수도 있습니다. 메모리가 남아 있는데 504가 난다면 PHP-FPM 작업자 수나 DB 응답 시간을 봐야 합니다. 디스크 I/O 대기가 높으면 코어를 늘려도 체감이 거의 없습니다.

클라우드서버는 필요한 만큼 쓰는 구조일 때 가장 효율이 좋습니다. 작은 서버로 시작해서 지표를 보고 올리는 게 부끄러운 일이 아닙니다. 오히려 운영을 아는 사람일수록 처음부터 큰 사양을 고집하지 않습니다. 서버는 돈으로 크게 만드는 것보다, 장애 날 지점을 먼저 줄이는 쪽이 오래 갑니다. 저가 요금제로 충분한 구간은 분명히 있고, 그 구간을 정확히 아는 게 운영 비용을 줄이는 제일 현실적인 방법입니다.