모두
모두콘텐츠
얼마 전 작은 회사 홈페이지를 VPS로 옮기겠다는 연락을 받았다. 방문자가 갑자기 늘어서가 아니라 공유호스팅이 느리다는 이유였다. 기록을 보니 문제는 서버 성능보다 이미지 용량과 만료된 캐시 설정에 가까웠다. 서버를 키우기 전에 실제로 어느 자원이 부족한지부터 보는 편이 비용도 적게 들고 사고도 줄인다.
홈페이지 규모는 방문자보다 요청으로 계산한다
월 방문자 수만으로 서버를 고르면 엇나가기 쉽다. 방문자가 몇 페이지를 보고, 한 페이지가 몇 MB를 보내며, 피크 시간에 요청이 얼마나 몰리는지가 필요하다. 예를 들어 월 방문자 3만 명이 평균 3페이지를 보고 페이지당 전송량이 1MB라면 월 전송량은 약 90GB다. 여기에 검색 로봇, 관리자 작업, 파일 다운로드를 더해야 한다. 이미지가 많은 사이트라면 실제 전송량이 이보다 훨씬 커질 수 있다.
같은 조건의 페이지 조회는 하루 평균 3천 건, 초당 평균 약 0.035건이다. 피크를 평균의 20배로 잡아도 초당 약 0.7건이다. 이 숫자만 보면 작은 편이지만, 이벤트 공지 직후처럼 몇 초 안에 몰리는 요청은 월간 평균에 드러나지 않는다. 접속 기록에서 가장 바쁜 5분의 요청 수를 따로 보고, 검색·결제·관리 화면처럼 캐시가 안 되는 요청은 구분해야 한다.
동시접속자 수에도 함정이 있다. 브라우저를 켜 둔 사람 100명이 서버에서 100개의 작업을 동시에 돌리는 건 아니다. 서버가 처리 중인 요청 수는 대략 초당 요청 수에 처리 시간을 곱해 가늠한다. 초당 10건을 받는데 한 건을 처리하는 데 0.2초가 걸리면 평균적으로 처리 중인 요청은 2건 정도다. 반대로 데이터베이스가 느려져 2초가 걸리면 20건이 쌓인다. 그래서 방문자 숫자보다 응답 시간과 느린 요청 기록이 더 유용하다.
공유호스팅과 VPS를 고르는 기준
회사 소개, 게시판, 소규모 쇼핑몰처럼 기능이 달라도 서버 선택 기준은 같다. 실제 피크 시간에 CPU와 메모리가 버티는지, 저장 공간과 전송량이 정책 안에 들어오는지 확인한다. 캐시가 잘 되는 소개형 홈페이지라면 무료 정적 호스팅이나 저가 공유호스팅으로도 충분할 수 있다. 동적 페이지가 많고 서버 설정을 직접 바꿔야 할 때 VPS를 검토하면 된다.
워드프레스 한 곳을 운영한다면 가상 CPU 2개와 메모리 2GB 정도를 출발점으로 잡을 수 있다. 다만 플러그인이 많거나 데이터베이스까지 같은 서버에 두고 백업 작업을 동시에 돌리면 2GB는 빠듯해질 수 있다. 이 수치는 보장 사양이 아니라 처음 측정할 자리다. 일주일 이상 가장 바쁜 시간의 메모리 사용량, CPU 대기, 응답 시간, 저장 장치 지연을 본 뒤 올리는 게 낫다.
- 메모리가 부족하면 프로세스가 종료되거나 스왑 때문에 갑자기 느려진다.
- CPU 사용률은 낮은데 응답이 길다면 데이터베이스 쿼리와 저장 장치 대기를 확인한다.
- 전송량만 크다면 서버를 키우기 전에 이미지 압축과 캐시 정책을 손본다.
요금표에서는 월 방문자 허용치보다 월 전송량, 저장 공간, 데이터베이스 제한, 백업 제공 범위를 읽는다. 무제한이라는 표현에도 파일 개수나 CPU 사용 정책이 붙는 경우가 있다. 기존 사용량과 피크를 알면 비싼 요금제를 고를 이유가 있는지도 보인다.
이전 전에 백업을 복원해 본다
홈페이지 이전에서 가장 위험한 건 파일 복사를 끝내고 백업도 됐다고 믿는 순간이다. 파일, 데이터베이스, 업로드 파일, 환경 설정, 인증서 갱신 방식이 각각 어디에 있는지 적어 둔다. 데이터베이스가 있는 사이트라면 파일을 복사하는 동안 글이나 주문이 바뀔 수 있다. 최종 이전 시점에는 쓰기를 잠시 막거나 변경분을 다시 맞춰야 데이터가 어긋나지 않는다.
백업은 복원해 봐야 쓸 수 있다. 새 서버의 임시 환경에서 파일과 데이터베이스를 되살리고 로그인, 이미지, 문의 폼, 결제 흐름을 확인한다. 운영 서버와 같은 계정에만 백업을 두면 계정 장애나 삭제 사고 때 같이 잃는다. 별도 위치에 보관하고, 보관 기간과 마지막 성공 시각을 확인하는 게 낫다. 매일 백업해도 한 달 전의 정상 상태가 필요할 수 있으니 보관 세대도 정해 둔다.
주소 전환 전에는 새 서버에서 화면뿐 아니라 관리자 기능과 자동 발송 작업을 점검한다. DNS의 TTL을 미리 낮추면 전환 후 변경 사항이 퍼지는 시간을 줄일 수 있지만, 모든 이용자에게 즉시 적용되는 건 아니다. 구 서버는 바로 지우지 말고 일정 기간 유지하면서 접속 기록과 오류를 살핀다. 이 기간에 신규 글이나 주문이 양쪽으로 갈라지지 않도록 쓰기 경로를 하나로 고정하는 게 중요하다.
장애가 나면 확인하는 순서
홈페이지가 열리지 않을 때는 서버를 재시작하기 전에 범위를 먼저 좁힌다. 내 회선에서만 안 되는지, 외부에서도 같은지 확인하고 DNS 조회, 인증서 만료, 웹서버 응답, 애플리케이션 오류 순서로 본다. 서버는 살아 있는데 화면만 느리다면 최근 배포와 플러그인 변경, 데이터베이스 연결 수, 저장 공간 사용량을 확인한다. 디스크가 가득 차면 로그 기록과 데이터베이스 쓰기가 같이 멈출 수 있다.
- 접속 자체가 안 되면 DNS 상태와 서버 네트워크, 방화벽 규칙을 본다.
- 보안 경고가 뜨면 인증서 유효 기간과 갱신 작업 기록을 본다.
- 오류 화면이 나오면 웹서버 로그와 애플리케이션 로그의 같은 시각을 맞춰 본다.
- 느리기만 하다면 피크 요청 수, 느린 쿼리, CPU·메모리·저장 장치 지연을 비교한다.
재시작은 증상을 잠깐 숨길 수 있지만 원인 기록도 덮어 버린다. 장애 시각, 바뀐 설정, 로그 한 줄만 남겨도 다음 대응은 빨라진다. 제 경험상 작은 홈페이지일수록 큰 서버보다 복원 가능한 백업과 익숙한 점검 순서가 운영 시간을 더 많이 아껴 준다.
