모두
모두콘텐츠
얼마 전 게임 공략 사이트를 운영하는 분이 하루 방문자가 1천 명을 넘었다며 VPS로 옮겨야 하느냐고 물었다. 서버 로그를 보니 느린 원인은 접속자 수보다 용량이 큰 공략 이미지였다. 버스 트래픽 피버 공략 사이트를 만든다고 해도 서버는 방문자 수만 보고 고를 일이 아니다. 한 페이지가 얼마나 많은 데이터를 보내는지, 접속이 몇 분에 몰리는지부터 계산해야 한다.
페이지 용량과 몰리는 시간을 먼저 계산한다
서버 요금제를 비교할 때 월 방문자 수만 적어 두면 판단이 어렵다. 방문자가 한 번에 몇 페이지를 읽는지에 따라 전송량이 달라진다. 예를 들어 공략 페이지가 이미지까지 포함해 평균 1MB이고 하루 1천 페이지가 열리면 하루 전송량은 약 1GB, 30일이면 약 30GB다. 이미지가 많아 평균 3MB가 되면 같은 방문자 수에서도 약 90GB가 된다. 이 수치는 계산 예시다. 실제 계약 전에는 접속 기록이나 분석 도구에서 페이지 조회 수와 전송 바이트를 확인해야 한다.
순간 접속도 따로 봐야 한다. 하루 1만 페이지 조회의 10%인 1천 건이 10분에 몰린다면 초당 약 1.7페이지 조회다. 웹서버가 처리하는 요청 수는 여기에 이미지·스크립트 요청이 더해진다. 다만 이미지가 캐시에서 나가면 원본 서버 부담은 크게 줄어든다. 검색 유입이 늘었다는 이유만으로 높은 사양의 클라우드 서버를 계약하면 이 차이를 놓치기 쉽다.
- 최근 30일의 페이지 조회 수와 전송량을 확인한다.
- 하루 평균뿐 아니라 가장 바빴던 5분의 요청 수를 확인한다.
- 이미지 한 장의 크기, 페이지당 이미지 수, 캐시 적중률을 함께 본다.
공략 페이지 형태에 맞춰 호스팅을 고른다
버스 트래픽 피버의 단계별 공략을 글과 이미지로 올리고 댓글이나 회원 기능이 없다면 정적 페이지가 단순하다. 수정한 페이지를 배포하고 이미지에 캐시를 적용하면 매 조회마다 프로그램과 데이터베이스를 실행할 이유가 없다. 이 경우에는 무료 또는 저가의 정적 호스팅으로 시작해도 충분한 구간이 넓다. 다만 무료 요금제에도 저장 공간, 전송량, 빌드 횟수 등의 제한이 있으니 현재 조건은 계약 화면에서 확인해야 한다.
워드프레스처럼 관리 화면에서 글을 쓰고 검색·댓글 플러그인을 운영한다면 사정이 다르다. 페이지 캐시가 제대로 작동하는 저가 웹호스팅부터 검토하고, 관리 화면까지 느리거나 피크 시간에 처리 대기가 쌓일 때 VPS를 고려한다. 예를 들어 2코어와 메모리 2GB VPS는 작은 콘텐츠 사이트의 출발점이 될 수 있지만, 이 사양 자체가 동시접속 보증치는 아니다. 플러그인 수, 캐시 설정, 데이터베이스 질의에 따라 같은 서버에서도 결과가 달라진다.
호스팅 상품에 적힌 ‘무제한 트래픽’도 그대로 받아들이면 안 된다. 실제로는 공정 사용 정책이나 순간 자원 제한이 붙을 수 있다. 월 전송량뿐 아니라 CPU 사용 제한, 동시 처리 제한, 초과 요금, 백업 포함 여부를 같이 읽어야 한다. 게임 공략 이미지를 많이 올릴 계획이라면 서버 사양을 올리기 전에 이미지 크기를 줄이고 캐시가 적용되는지 보는 편이 비용을 아끼기 쉽다.
이전과 백업은 복구까지 시험한다
사이트 이전에서 자주 생기는 사고는 파일만 옮기고 데이터베이스나 업로드 이미지를 빠뜨리는 것이다. 이전 전에는 현재 파일, 데이터베이스, 설정값을 각각 백업하고 백업 시각을 기록한다. 새 서버에서 복원한 뒤에는 첫 화면만 보지 말고 오래된 공략 글, 이미지, 검색, 관리 화면을 직접 확인해야 한다. 정상 동작을 확인한 다음 도메인 연결을 바꾸고, 이전 서버는 문제가 생겼을 때 되돌릴 수 있도록 잠시 유지한다.
백업 파일이 있다는 것과 복구할 수 있다는 것은 다르다. 같은 서버 안에만 보관한 백업은 서버나 계정에 문제가 생겼을 때 함께 잃을 수 있다. 하루에 글을 여러 개 올린다면 하루 한 번 백업만으로 허용할 수 있는 손실이 얼마인지도 생각해야 한다. 나는 운영 빈도에 맞춰 자동 백업을 잡고, 별도 저장 위치에 사본을 둔 뒤, 가끔 새 환경에 실제로 복원해 본다. 복원에 걸린 시간을 재면 장애 때 필요한 작업 시간도 대략 알 수 있다.
접속 장애는 범위를 좁혀가며 확인한다
사이트가 갑자기 느려지면 곧바로 서버를 증설하지 않는다. 먼저 나만 접속이 안 되는지, 모든 페이지가 안 열리는지, 이미지에만 문제가 있는지 확인한다. 도메인 연결과 SSL 인증서 상태를 보고, 서버의 디스크 여유 공간과 메모리, 웹서버 오류 기록을 차례로 확인한다. 디스크가 꽉 차서 로그나 임시 파일을 쓰지 못하는 경우라면 CPU를 늘려도 해결되지 않는다.
서버 응답이 늦다면 접속 기록의 응답 시간과 오류 비율을 본다. 캐시가 적용된 페이지는 빠른데 관리 화면만 느리다면 프로그램이나 데이터베이스 쪽을 살펴볼 차례다. 반대로 원본 서버는 정상인데 이미지가 일부 지역에서만 느리다면 캐시 설정과 전송 경로를 확인한다. 장애가 난 시각의 배포·플러그인 변경·인증서 갱신 기록도 함께 대조하면 원인을 찾는 시간이 줄어든다.
버스 트래픽 피버 공략 사이트라면 처음부터 큰 서버를 사는 것보다 작은 구성으로 열고 전송량, 가장 바쁜 시간의 응답 속도, 복구 시간을 기록하는 쪽이 낫다. 운영하면서 병목이 확인되면 그 부분에만 비용을 쓰면 된다. 14년 동안 본 작은 사이트의 장애도 트래픽 자체보다 확인하지 않은 설정과 복원해 보지 않은 백업에서 시작한 경우가 더 많았다.
