요즘 상담을 하다 보면 작은 쇼핑몰이나 회사 소개 사이트까지 처음부터 클라우드 서버를 크게 잡는 경우가 많아졌습니다. 그런데 실제 로그를 보면 하루 방문자 1천 명도 안 되고, 동시접속은 5명 아래인 사이트가 꽤 많습니다. 이런 사이트에 4코어 8기가 서버부터 넣는 건 기술적으로 틀렸다기보다 돈을 먼저 쓰는 방식입니다.
저는 서버를 고를 때 브랜드보다 먼저 숫자를 봅니다. 트래픽이 얼마나 나오는지, 피크 시간대 동시접속이 몇 명인지, 이미지가 많은지, 관리자 페이지에서 배치 작업을 돌리는지부터 확인합니다. 클라우드는 좋습니다. 다만 좋다는 말과 크게 써야 한다는 말은 다릅니다.
클라우드는 사양보다 운영 방식이 먼저입니다
클라우드 서버를 처음 쓰는 분들이 가장 많이 착각하는 지점이 있습니다. 클라우드로 옮기면 장애가 줄어든다고 생각합니다. 실제로는 반쯤만 맞습니다. 물리 장비 장애나 증설 편의성은 좋아지지만, 웹서버 설정이 엉켜 있거나 백업이 없거나 인증서 갱신을 놓치면 클라우드에서도 그대로 죽습니다.
예를 들어 워드프레스 사이트 하나를 운영한다고 보겠습니다. 하루 방문자 3천 명, 피크 시간 동시접속 20명 수준이면 보통 1코어 1기가에서 2코어 2기가 사이로도 시작할 수 있습니다. 캐시 플러그인, 이미지 최적화, 데이터베이스 정리만 제대로 되어 있으면 생각보다 오래 버팁니다. 반대로 캐시가 없고 원본 이미지를 그대로 올리고, 방문자마다 무거운 쿼리가 여러 번 돌면 4코어 서버도 버벅입니다.
사실 서버 비용은 사양표에서 결정되는 것 같지만, 운영 현장에서는 설정값에서 더 많이 새어 나갑니다. PHP 메모리 제한, 웹서버 워커 수, 데이터베이스 커넥션 수, 백업 압축 작업 시간 같은 것들이 맞지 않으면 작은 트래픽에서도 장애가 납니다.
트래픽 규모별로 대충 이 정도부터 잡습니다
정확한 사양은 사이트 구조마다 다르지만, 처음 산정할 때는 기준선이 필요합니다. 저는 대체로 아래 정도를 출발점으로 봅니다. 이미지가 많거나 로그인 사용자가 많거나 검색 기능이 무거우면 한 단계 올려 잡습니다.
- 하루 방문자 500명 이하: 일반 웹호스팅이나 1코어 1기가 VPS로 충분한 경우가 많습니다.
- 하루 방문자 500~3천 명: 1코어 1기가 또는 2코어 2기가 클라우드 서버에서 캐시 적용을 전제로 봅니다.
- 하루 방문자 3천~1만 명: 2코어 4기가 정도부터 보고, 데이터베이스와 웹서버 부하를 분리해서 확인합니다.
- 하루 방문자 1만 명 이상: 서버 사양만 올리지 말고 캐시, CDN, DB 튜닝, 백업 분리까지 같이 설계해야 합니다.
여기서 중요한 건 하루 방문자보다 피크입니다. 하루 1만 명이 24시간 고르게 들어오는 사이트와, 점심시간 30분에 몰리는 사이트는 완전히 다릅니다. 후자는 평균 트래픽만 보고 서버를 잡으면 장애가 납니다. 서버 선택 전에 최소한 접속 로그에서 시간대별 요청 수를 봐야 합니다.
대략적인 계산도 해볼 수 있습니다. 페이지 하나가 이미지 포함 2MB이고 하루 5천 페이지뷰라면 전송량은 하루 10GB, 한 달이면 300GB 근처입니다. 여기에 봇, 관리자 접속, 재방문 캐시 미적용분을 더하면 400~500GB까지 볼 수 있습니다. 이 정도면 요금제의 월 전송량 조건을 꼭 확인해야 합니다.
싸게 시작해도 되는 구간과 그러면 안 되는 구간
개인 블로그, 회사 소개 사이트, 랜딩 페이지, 초기 쇼핑몰은 대부분 비싼 클라우드 구성이 필요 없습니다. 정적 페이지 비중이 높고 결제나 회원 기능이 약하면 저가 VPS나 웹호스팅으로도 충분합니다. 솔직히 이런 사이트는 서버를 크게 사는 것보다 이미지 용량 줄이고 캐시 켜는 게 효과가 큽니다.
근데 아무 사이트나 싸게 가면 되는 건 아닙니다. 예약, 결제, 수강 신청, 이벤트 응모처럼 특정 시간에 사용자가 몰리는 구조는 다르게 봐야 합니다. 평소에는 한산해도 이벤트 시작 5분 동안 동시접속이 수백 명까지 올라갈 수 있습니다. 이때는 평소 방문자 기준으로 고르면 거의 실패합니다.
또 하나는 데이터 손실 비용입니다. 게시글 몇 개 잃어도 복구 가능한 블로그와, 주문 데이터가 사라지면 바로 민원이 생기는 쇼핑몰은 백업 기준이 달라야 합니다. 후자는 서버 사양보다 백업 주기, 복구 테스트, 데이터베이스 덤프 보관 위치가 더 중요합니다.
이전할 때는 서버 복사보다 순서가 중요합니다
클라우드 이전에서 사고가 나는 지점은 정해져 있습니다. 파일은 옮겼는데 DB 문자셋이 깨지거나, DNS를 먼저 바꿨는데 새 서버의 SSL이 준비되지 않았거나, 업로드 폴더 권한이 달라져 이미지가 안 뜨는 식입니다. 기술 자체보다 순서 문제입니다.
- 현재 서버에서 파일, DB, 설정 파일을 각각 백업합니다.
- 새 클라우드 서버에 웹서버, 런타임, DB 버전을 맞춥니다.
- 임시 접속 방식으로 사이트가 뜨는지 먼저 확인합니다.
- 로그인, 글쓰기, 결제, 메일 발송 같은 동적 기능을 테스트합니다.
- SSL 인증서 적용 후 DNS를 변경합니다.
- 변경 후 24~48시간은 양쪽 서버 로그를 같이 봅니다.
DNS 전환 전에 TTL을 낮춰두면 롤백이 편합니다. 보통 하루 전쯤 낮춰두면 충분한 경우가 많습니다. 그리고 이전 당일에는 게시글 작성이나 주문이 계속 들어오는 사이트라면 최종 DB 동기화 시간을 따로 잡아야 합니다. 이걸 안 하면 새 서버로 넘어간 뒤 일부 데이터가 빠져 보입니다.
백업은 저장보다 복구가 기준입니다
백업이 있다고 말하는 사이트 중에도 실제로 복구가 안 되는 경우가 많습니다. 압축 파일은 있는데 DB가 빠져 있거나, DB는 있는데 업로드 이미지가 없거나, 백업 파일이 같은 서버 안에만 있는 식입니다. 서버 디스크가 깨지면 같이 사라지는 백업은 백업이라고 보기 어렵습니다.
운영 기준으로는 최소한 파일과 DB를 분리해서 보고, 중요한 사이트는 외부 저장소에 하나 더 둬야 합니다. 개인 블로그는 하루 1회 백업이면 충분한 경우가 많고, 주문이 들어오는 쇼핑몰은 DB를 더 짧은 주기로 잡아야 합니다. 비용을 아끼려면 서버 코어를 올리기보다 백업 보관 정책을 먼저 정하는 편이 낫습니다.
복구 테스트도 필요합니다. 한 달에 한 번이라도 임시 위치에 DB를 올려보고 관리자 로그인이 되는지 확인하면 큰 사고를 줄일 수 있습니다. 백업 파일 용량이 0바이트였는데 몇 달 동안 아무도 몰랐던 현장도 봤습니다. 자동화는 편하지만, 성공했다는 알림만 믿으면 위험합니다.
장애가 났을 때 보는 순서
사이트가 안 뜨면 먼저 서버를 키우고 싶어집니다. 그런데 순서를 지켜야 합니다. 저는 보통 DNS, SSL, 웹서버 상태, 디스크 용량, 메모리, DB 접속, 애플리케이션 로그 순서로 봅니다. 이 순서만 지켜도 엉뚱한 증설을 줄일 수 있습니다.
- 도메인이 올바른 서버를 보고 있는지 확인합니다.
- SSL 인증서 만료나 체인 오류가 있는지 봅니다.
- 웹서버 프로세스가 살아 있는지 확인합니다.
- 디스크 사용률이 90%를 넘었는지 봅니다.
- DB 접속 오류와 커넥션 초과를 확인합니다.
- 최근 배포나 플러그인 변경이 있었는지 로그를 봅니다.
디스크 100%로 사이트가 죽는 경우가 생각보다 많습니다. 접속자가 폭증한 게 아니라 로그 파일이나 백업 파일이 계속 쌓인 겁니다. 이런 상황에서 서버 사양을 올려도 며칠 뒤 같은 문제가 다시 납니다. 원인을 지우지 않고 비용만 올리는 셈입니다.
클라우드는 필요한 만큼 늘릴 수 있어서 좋은 도구입니다. 다만 처음부터 크게 사는 도구가 아니라, 측정하면서 맞춰 가는 도구에 가깝습니다. 작은 서버로 시작하되 로그와 백업, 복구 절차를 갖춰두면 의외로 오래 버팁니다. 저는 서버 비용을 아끼는 것보다, 장애가 났을 때 어디부터 볼지 정해져 있는 상태가 더 중요하다고 봅니다.
