모두
모두콘텐츠
얼마 전 하루 방문자가 300명쯤 되는 홈페이지의 서버를 옮겨 달라는 연락을 받았다. 운영자는 트래픽이 늘어서 사이트가 느려졌다고 생각했는데, 로그를 보니 원인은 오래된 플러그인이었다. 서버 사양을 올리기 전에 무엇이 느린지 확인했으면 이전 비용을 쓰지 않아도 됐을 일이다.
홈페이지를 처음 만들 때도 비슷하다. 방문자가 얼마나 올지 모른다는 이유로 큰 VPS나 클라우드 서버부터 고르는 경우가 있다. 사실 작은 회사 소개 사이트나 개인 블로그는 저렴한 웹호스팅으로도 충분한 구간이 길다. 필요한 사양은 방문자 수만 보지 말고 전송량, 몰리는 시간, 페이지가 서버에서 하는 일을 함께 계산해야 한다.
한 달 전송량부터 대략 계산한다
먼저 페이지 한 번을 열 때 내려받는 데이터가 몇 MB인지 확인한다. 이미지가 많은 홈페이지는 글 위주의 사이트보다 전송량이 훨씬 크다. 예를 들어 페이지당 평균 1MB, 하루 500명이 각각 2페이지를 본다면 하루 전송량은 약 1GB다. 30일이면 약 30GB다. 계산식은 ‘평균 페이지 용량 × 하루 페이지뷰 × 30일’이다.
이 숫자는 출발점일 뿐이다. 관리자 화면에서 올리는 파일, 검색 로봇, 이미지 원본 다운로드가 빠져 있다. 새 사이트라면 계산값에 2배 정도 여유를 두고 요금제의 월 전송량과 초과 비용을 확인한다. 사진 한 장이 5MB씩 들어간다면 서버를 바꾸기 전에 이미지 크기부터 줄이는 편이 효과가 크다.
캐시도 같이 봐야 한다. 이미지와 스타일 파일을 방문자 가까운 곳에서 제공하면 원본 서버가 처리하는 요청이 줄어든다. 아마존 클라우드프런트의 운영 문서도 캐시 적중률에 따라 원본 서버 부하가 달라진다고 설명한다. 다만 로그인 화면이나 장바구니처럼 사용자마다 내용이 다른 페이지는 공개 페이지와 같은 방식으로 캐시할 수 없다.
방문자 수보다 몰리는 시간을 본다
하루 1만 페이지뷰라고 해서 서버가 매초 같은 양을 처리하는 건 아니다. 안내 문자를 보낸 직후 10분에 방문이 몰리면 평소보다 훨씬 많은 요청이 들어온다. 반대로 검색 유입이 하루 종일 고르게 들어오는 블로그는 같은 일일 페이지뷰라도 부담이 작다.
대략적인 피크를 잡으려면 가장 바쁜 1시간의 페이지뷰를 3,600으로 나눠 초당 페이지 요청 수를 구한다. 그 시간에 1,800페이지뷰가 있었다면 평균 초당 0.5건이다. 실제로는 짧게 몰리므로 3~5배의 순간 부하를 가정해 본다. 페이지 생성에 1초가 걸린다면 순간적으로 처리 중인 요청은 대략 1.5~2.5건 수준이다. 이 수치는 예산을 잡기 위한 추정치이며, 접속 로그로 확인하는 게 가장 정확하다.
여기서 말하는 ‘동시에 처리 중인 요청’은 사이트에 접속해 있는 사람 수와 다르다. 방문자가 글을 읽는 몇 분 동안 서버가 계속 작업하는 것은 아니다. 업체가 제시하는 동시접속자 숫자만 보고 비싼 상품을 고르면 사양이 남기 쉽다. 대신 피크 시간의 응답 시간, 오류 수, CPU와 메모리 사용량을 같이 본다.
웹호스팅과 VPS를 나누는 기준
회사 소개, 예약 문의, 일반 블로그처럼 기능이 단순하고 운영 인력이 없다면 관리형 웹호스팅이 편하다. 서버 보안 업데이트와 기본 운영을 업체가 맡는 범위를 확인하고, 제공 용량과 전송량이 실제 사용량을 감당하는지 보면 된다. 방문자가 적다면 무료 또는 저가 상품으로 시작해도 무방하다. 다만 무료 상품은 광고 표시, 백업, 자체 도메인 연결 조건을 먼저 확인해야 한다.
VPS는 서버 설정을 직접 바꾸거나 특정 프로그램을 설치해야 할 때 선택할 만하다. 대신 운영자가 보안 패치, 방화벽, 장애 대응을 챙겨야 한다. CPU 1개와 메모리 1GB 같은 숫자만으로 적합성을 판단하기는 어렵다. 데이터베이스와 웹서버를 같은 장비에서 돌리고 플러그인도 여럿 쓴다면 메모리 부족이 먼저 나타날 수 있다. 이때는 상품 설명보다 실제 메모리 사용량과 디스크 입출력을 보고 올리는 편이 낫다.
요금도 월 기본료만 비교하면 틀린다. 백업 보관, 추가 전송량, 별도 저장 공간, 관리 서비스를 합친 월 비용으로 비교한다. 작은 홈페이지에 서버 두 대를 미리 구성하는 것보다, 장애가 났을 때 복구할 수 있는 백업과 연락 가능한 지원 창구를 확보하는 편이 먼저인 경우가 많다.
이전하기 전에 복구 절차를 만든다
홈페이지 이전 사고는 파일만 복사하고 끝냈을 때 자주 난다. 데이터베이스의 최신 글이나 주문이 빠지고, 새 서버에서는 메일 발송이 막히거나 이미지 경로가 달라지기도 한다. 이전 전에는 파일과 데이터베이스를 각각 백업하고, 복사본으로 복구가 되는지 확인한다. 백업 파일이 있다는 사실과 실제로 복원할 수 있다는 사실은 다르다. 아마존의 백업 운영 지침에도 복구 시험이 별도 절차로 들어간다.
작업 순서는 단순하게 잡는다. 기존 사이트의 파일과 데이터베이스를 백업한 뒤 새 환경에서 화면, 로그인, 문의 양식, 결제 기능을 확인한다. 변경 직전에는 새 글이나 주문이 생기지 않도록 작업 시간을 공지하고 최종 데이터를 다시 옮긴다. 전환 후에도 기존 서버를 바로 지우지 말고 접속 기록과 오류 로그를 확인할 시간을 둔다.
장애가 나면 가장 먼저 전체 접속이 안 되는지, 특정 페이지나 기능만 안 되는지 구분한다. 그다음 도메인 만료와 DNS 설정, SSL 인증서, 서버 상태, 저장 공간, 최근 변경 사항 순으로 확인하면 원인을 좁히기 쉽다. 특히 배포나 플러그인 업데이트 직후라면 마지막 변경을 되돌릴 수 있는지도 본다.
홈페이지에 필요한 서버는 방문자 수가 늘 때마다 미리 크게 사두는 장비가 아니다. 실제 피크와 전송량을 기록하고, 느려지는 지점을 확인한 다음 한 단계씩 올리는 편이 운영하기 편하다. 14년간 서버를 보면서 가장 안심됐던 사이트도 사양이 큰 곳보다는 백업을 복원해 본 곳이었다.
