모두
모두콘텐츠
얼마 전 작은 쇼핑몰 서버 이전을 도와준 적이 있습니다. 월 방문자는 많지 않았는데 기존 업체에서 8코어 VPS를 쓰고 있더군요. 막상 로그를 보니 하루 대부분 CPU 사용률은 10% 아래였고, 진짜 문제는 디스크 백업이 같은 서버 안에만 있다는 점이었습니다. 서버는 크게 잡는 것보다 맞게 잡는 쪽이 오래 갑니다.
서버 사양은 방문자 수보다 동시접속부터 봅니다
서버 견적을 낼 때 “월 방문자 10만이면 어느 정도면 되나요?”라는 질문을 많이 받습니다. 그런데 월 방문자는 너무 넓은 숫자입니다. 하루에 고르게 들어오는 10만과 이벤트 하루에 몰리는 10만은 완전히 다릅니다. 실무에서는 동시접속, 요청 수, 페이지 무게, 캐시 여부를 같이 봐야 합니다.
예를 들어 워드프레스 블로그 기준으로 정적 캐시가 잘 걸려 있고 이미지가 외부 저장소나 CDN으로 빠져 있다면, 하루 3천~1만 방문자 정도는 1~2코어, 메모리 1~2GB VPS로도 버티는 경우가 많습니다. 반대로 캐시가 없고 PHP가 매 요청마다 DB를 때리면 방문자 수가 적어도 금방 느려집니다.
- 개인 블로그, 회사 소개 사이트: 1코어, 메모리 1GB부터 검토
- 워드프레스 콘텐츠 사이트: 1~2코어, 메모리 2GB 권장
- 작은 쇼핑몰: 2코어, 메모리 4GB부터 시작
- 동시 주문·검색이 많은 사이트: DB 분리 또는 캐시 계층 검토
여기서 중요한 건 처음부터 큰 서버를 사는 게 아닙니다. CPU, 메모리, 디스크 I/O, DB 쿼리 시간을 계측할 수 있게 만들어두고 한 단계씩 올리는 방식이 낫습니다. 싼 요금제가 부족해서 장애 나는 경우보다, 로그와 백업 없이 운영하다가 원인을 못 찾아 길게 죽는 경우를 더 많이 봤습니다.
트래픽보다 서버를 죽이는 건 설정입니다
서버 장애 원인을 보면 순수 트래픽 폭증보다 설정 문제가 많습니다. PHP 메모리 제한, 웹서버 프로세스 수, DB 커넥션 수, 로그 파일 비대화, SSL 인증서 만료 같은 것들입니다. 다 평소에는 조용하다가 특정 순간에 한꺼번에 터집니다.
예를 들어 Nginx나 Apache의 워커 수를 너무 낮게 잡으면 CPU가 남아도 요청이 대기합니다. 반대로 PHP-FPM 프로세스를 과하게 열어두면 메모리를 다 먹고 스왑이 발생합니다. 스왑이 시작되면 사이트는 죽은 것처럼 느려집니다. 이때 서버 사양을 올리면 잠깐 나아 보이지만, 설정이 틀어져 있으면 결국 같은 문제가 반복됩니다.
먼저 확인할 기본 항목
- CPU 사용률이 높은지, I/O 대기가 높은지 구분
- 메모리 여유와 스왑 사용 여부 확인
- 웹서버 에러 로그에서 502, 504, Too many connections 확인
- DB slow query 로그와 커넥션 수 확인
- 디스크 사용률과 inode 사용률 확인
특히 디스크는 의외로 많이 놓칩니다. 용량이 100%가 아니어도 inode가 꽉 차면 파일 생성이 안 됩니다. 세션 파일이나 캐시 파일이 수십만 개 쌓인 서버에서 자주 봅니다. 서버가 느리다는 말만 듣고 CPU부터 올리면 돈은 돈대로 쓰고 원인은 그대로 남습니다.
웹호스팅, VPS, 클라우드 서버를 고르는 기준
초보자라면 무조건 VPS가 답은 아닙니다. 단순한 회사 소개 사이트나 방문자 적은 블로그라면 관리형 웹호스팅이 더 편할 수 있습니다. 보안 패치, 메일, 백업, SSL 일부를 업체가 처리해주기 때문입니다. 서버를 직접 운영할 자신이 없으면 저가 웹호스팅이 더 안정적일 때도 많습니다.
VPS는 자유도가 높습니다. 웹서버 설정, PHP 버전, DB 튜닝, 배포 구조를 마음대로 잡을 수 있습니다. 대신 장애 대응도 본인 몫입니다. 새벽에 디스크가 꽉 차거나 인증서가 만료되면 직접 봐야 합니다. 클라우드 서버는 확장성과 부가 기능이 좋지만, 네트워크, 스토리지, 스냅샷, 트래픽 비용이 분리되어 있어 월말 비용이 예상보다 커질 수 있습니다.
- 웹호스팅: 운영 부담을 줄이고 싶은 소규모 사이트에 적합
- VPS: 비용 대비 성능이 좋고 직접 설정 가능한 사람에게 적합
- 클라우드 서버: 확장, 이중화, 자동화가 필요한 서비스에 적합
- 매니지드 서버: 장애 대응 인력이 부족한 사업자에게 현실적인 선택
제가 보통 권하는 순서는 이렇습니다. 처음에는 작은 사양으로 시작하되, 백업과 모니터링을 먼저 갖춥니다. 그다음 병목이 확인되면 CPU, 메모리, DB, 캐시 순서로 손봅니다. 사양 업그레이드는 마지막 카드가 아니라 중간 카드입니다. 원인을 확인한 뒤 쓰면 효과가 큽니다.
백업은 서버 밖에 있어야 백업입니다
백업 이야기는 지루하지만, 실제 사고에서는 제일 중요합니다. 같은 서버 안에 압축 파일 하나 만들어두고 백업이라고 부르는 경우가 많습니다. 디스크가 깨지거나 계정이 삭제되면 원본과 백업이 같이 사라집니다. 이건 백업이 아니라 복사본에 가깝습니다.
최소 기준은 서버 밖 저장입니다. 다른 스토리지, 다른 계정, 가능하면 다른 리전에 보관해야 합니다. DB는 파일만 복사하면 안 되고 덤프 또는 일관성 있는 스냅샷이 필요합니다. 업로드 파일, DB, 설정 파일, SSL 인증서, 배포 스크립트까지 복구에 필요한 것을 묶어서 봐야 합니다.
운영자가 실제로 챙길 백업 기준
- 일 1회 이상 자동 백업
- 최근 7일분과 월 단위 보관본 분리
- 서버 외부 저장소에 보관
- 분기마다 복구 테스트 진행
- DB, 업로드 파일, 설정 파일을 함께 관리
백업은 성공 로그만 보면 안 됩니다. 복구가 되는지를 봐야 합니다. 제가 운영하던 서버 중에도 백업 스크립트는 매일 성공이라고 찍혔는데, 실제 덤프 파일 크기가 0바이트였던 적이 있습니다. 권한이 바뀌었는데 알림이 없었던 겁니다. 백업은 만들어지는 순간보다 되살릴 때 가치가 드러납니다.
서버 이전은 DNS보다 데이터 동기화가 먼저입니다
서버 이전을 할 때 가장 흔한 실수는 DNS부터 바꾸는 겁니다. 새 서버 세팅이 끝났다고 바로 도메인을 넘기면, 일부 사용자는 구 서버로, 일부는 신 서버로 접속합니다. 이때 게시글, 주문, 회원가입 데이터가 양쪽으로 갈라질 수 있습니다.
이전은 순서가 중요합니다. 먼저 새 서버에 동일한 런타임과 DB 버전을 맞추고, 파일과 DB를 1차 복사합니다. 그다음 테스트 도메인이나 로컬 hosts 설정으로 화면, 로그인, 결제, 관리자 기능을 확인합니다. 실제 전환 직전에는 구 서버의 쓰기 작업을 잠깐 막고 최종 DB를 다시 가져와야 합니다.
- 이전 전 TTL을 낮춰 DNS 전파 시간을 줄임
- 새 서버에서 PHP, DB, 확장 모듈 버전 확인
- 파일 권한과 업로드 경로 확인
- 최종 전환 직전 DB 재동기화
- 전환 후 구 서버는 최소 며칠간 보관
TTL은 전환 하루 전쯤 낮춰두면 좋습니다. 물론 모든 환경에서 즉시 반영되지는 않지만, 대기 시간을 줄이는 데 도움이 됩니다. 서버 이전은 빠르게 끝내는 작업이 아니라 데이터를 잃지 않는 작업입니다. 여기에 초점을 두면 실수가 확 줄어듭니다.
장애가 났을 때는 큰 것부터 지웁니다
사이트가 안 뜨면 마음이 급해집니다. 그런데 이때 이것저것 동시에 바꾸면 원인을 잃습니다. 저는 항상 큰 범위부터 줄입니다. 서버가 살아 있는지, 웹서버가 응답하는지, DB가 붙는지, 애플리케이션 오류인지 순서대로 봅니다.
먼저 ping이나 콘솔 접속으로 서버 상태를 확인합니다. 그다음 웹서버 프로세스, 포트 리스닝, 에러 로그를 봅니다. 502면 웹서버와 PHP-FPM 사이를 보고, 504면 처리 지연이나 백엔드 응답 지연을 의심합니다. 500이면 애플리케이션 로그와 권한 문제가 많습니다. DB 접속 오류라면 커넥션 수, 계정 권한, 디스크 용량을 같이 봐야 합니다.
서버 운영은 비싼 장비를 고르는 일이 아니라, 평소에 망가질 지점을 줄이는 일에 가깝습니다. 작은 서버라도 캐시, 백업, 로그, 알림이 갖춰져 있으면 오래 버팁니다. 반대로 큰 서버라도 백업이 없고 설정을 모르면 장애 한 번에 며칠이 날아갑니다. 저는 아직도 사양표보다 복구 절차가 먼저라고 봅니다.
