모두
모두콘텐츠
얼마 전 하루 방문자가 1천 명 남짓한 사이트를 옮겼는데, 기존 서버에는 CPU 8개와 메모리 16GB가 잡혀 있었다. 느린 원인은 사양이 아니었다. 이미지 한 장이 4MB였고, 백업 작업이 방문자가 몰리는 시간에 데이터베이스를 붙잡고 있었다. 이런 사이트라면 서버를 더 키우기 전에 사용량부터 계산하는 게 맞다.
방문자 수보다 피크 요청량을 먼저 계산한다
서버가 처리하는 단위는 방문자가 아니라 요청이다. 페이지 한 번을 열어도 HTML, 이미지, 스크립트 요청이 따로 발생한다. 다만 이미지와 스크립트를 캐시에서 보내면 가상서버가 직접 처리하는 요청은 크게 줄어든다. 관리자 화면에서 월간 방문자 수만 보고 CPU를 고르면 실제 부하와 어긋나기 쉽다.
계산은 하루 페이지 조회 수에 서버가 직접 처리할 요청 수를 곱하는 데서 시작한다. 예를 들어 하루 3만 페이지 조회가 있고, 페이지마다 서버가 처리하는 요청이 평균 3개라면 하루 9만 요청이다. 8만 6400초로 나누면 평균 초당 약 1건이다. 방문이 몰리는 시간에 평균의 10배가 들어온다고 가정해도 초당 약 10건이다. 이 10배는 견적을 위한 가정이므로, 운영 중인 사이트라면 접속 기록에서 실제 피크를 확인해야 한다.
동시 처리량도 함께 본다. 초당 10건이 들어오고 서버 응답에 평균 0.3초가 걸리면 동시에 처리 중인 요청은 대략 3건이다. 반대로 데이터베이스 조회가 느려 응답이 3초로 늘면 같은 트래픽에서도 약 30건이 쌓인다. 그래서 느린 사이트를 무조건 큰 서버로 옮기면 비용만 올라가고 병목은 남을 수 있다.
CPU와 메모리는 사이트 구성에 맞춰 잡는다
정적 페이지 위주이고 접속량이 적다면 1가상 CPU와 메모리 1GB부터 시험할 만하다. 웹서버와 데이터베이스를 한 대에서 돌리는 워드프레스 같은 구성은 메모리 2GB를 출발점으로 잡는 편이 현실적이다. 운영체제, 데이터베이스, PHP 작업 프로세스가 메모리를 나눠 쓰기 때문이다. 상품 상세 검색이나 예약처럼 쿼리가 많은 서비스는 같은 방문자 수라도 CPU와 메모리를 더 쓸 수 있다. 이 숫자는 구매 기준점이지 성능 보증치는 아니다.
메모리가 모자라면 먼저 작업 프로세스 수와 실제 사용량을 확인한다. 여유 메모리가 거의 없고 디스크 스왑 사용량이 계속 늘면 증설을 검토할 근거가 된다. CPU 사용률이 순간적으로 높아지는 것만으로는 부족하다. 피크 시간에 높은 사용률이 지속되고 응답 시간도 함께 늘어나는지 봐야 한다. 데이터베이스의 느린 조회 한 건을 고치는 일이 CPU를 두 배로 늘리는 것보다 효과적일 때도 많다.
공유 웹호스팅으로 충분한 구간도 있다. 서버 설정을 직접 바꿀 필요가 없고, 사이트 규모가 작으며, 제공되는 백업·복구 범위가 요구사항에 맞는다면 가상서버를 운영할 이유가 크지 않다. 가상서버는 설정 권한을 주지만 보안 업데이트, 방화벽, 장애 대응도 운영자 몫이 된다. 월 요금만 비교하면 이 시간을 빠뜨리기 쉽다.
디스크 용량보다 전송량과 백업 공간을 따진다
페이지 조회당 방문자에게 전달되는 데이터가 평균 1MB라면 하루 1천 조회는 약 1GB, 30일이면 약 30GB다. 하루 3만 조회라면 약 900GB가 된다. 같은 서버 사양이라도 포함 전송량에 따라 월 비용이 달라질 수 있다. 이미지 최적화나 캐시를 적용한 뒤 실제 서버 송신량을 재면 계산을 더 정확하게 할 수 있다. 페이지 크기만 보고 전송량을 단정하면 동영상, 파일 다운로드, 검색 로봇 트래픽을 놓친다.
디스크는 현재 파일 크기만큼만 잡으면 위험하다. 업로드 파일, 데이터베이스 증가분, 로그, 업데이트 때 필요한 임시 공간을 더해야 한다. 예를 들어 현재 사용량이 8GB인 사이트에 10GB 디스크를 붙이면 작은 변경에도 공간이 바닥날 수 있다. 특히 디스크가 가득 차면 로그 기록과 데이터베이스 쓰기가 함께 실패한다. 여유 공간은 사용량 추세를 보며 잡고, 서버 안에 쌓이는 오래된 백업과 로그에는 보관 기한을 둔다.
백업을 같은 가상서버의 다른 폴더에만 두는 것은 복구 수단으로 부족하다. 서버 전체가 손상되거나 계정이 탈취되면 원본과 백업을 함께 잃을 수 있다. 별도 저장소에 자동 백업을 두고, 파일과 데이터베이스의 백업 시점이 맞는지도 확인한다. 하루 한 번 백업이라면 장애 시 최대 하루치 변경분을 잃을 수 있다는 뜻이다. 주문이나 예약 데이터가 있다면 그 손실 범위를 먼저 정해야 백업 주기도 정할 수 있다.
이전 전에 복구와 전환 순서를 적어 둔다
서버 이전은 파일 복사보다 전환 순서에서 사고가 난다. 먼저 새 가상서버에 운영체제와 웹서버를 설치하고, 파일과 데이터베이스를 옮긴 뒤 테스트 환경에서 로그인·업로드·메일 발송·예약 작업을 확인한다. SSL 인증서 적용과 자동 갱신도 이때 점검한다. 예전 서버에서 잘 돌던 예약 작업이 새 서버에서 빠지는 일이 생각보다 흔하다.
전환 직전에는 데이터베이스 쓰기 작업을 잠시 멈추거나, 마지막 변경분을 옮길 절차를 정한다. 그다음 접속 대상을 바꾸고 새 서버의 오류 기록과 응답 시간을 본다. 접속 대상 변경은 이용자마다 반영 시점이 다를 수 있으므로 예전 서버를 즉시 끄지 않는다. 문제가 생기면 어느 시점의 데이터로 되돌릴지, 예전 서버로 접속을 돌릴 수 있는지까지 적어 두면 복구 판단이 빨라진다.
장애가 나면 자원 그래프보다 접속 경로부터 본다
사이트가 열리지 않을 때는 접속 대상 설정, 서버 접속, 웹서버 프로세스, 애플리케이션, 데이터베이스 순서로 범위를 좁힌다. 모든 방문자에게 접속이 안 되는지, 특정 페이지만 오류가 나는지도 구분한다. 인증서 만료라면 화면에 경고가 뜰 수 있고, 데이터베이스 연결 실패라면 웹서버 자체는 살아 있어도 페이지를 만들지 못한다. 이 차이를 확인하지 않고 재부팅부터 하면 원인을 보여 주던 기록만 흐려질 수 있다.
서버에 들어갈 수 있다면 디스크 여유 공간과 메모리 부족 기록, 웹서버 오류 기록을 먼저 확인한다. 그 뒤 최근 배포나 설정 변경 시간을 장애 시작 시각과 맞춰 본다. 실제 운영에서는 접속 폭주보다 잘못된 설정 한 줄, 가득 찬 디스크, 복원해 본 적 없는 백업이 더 긴 장애를 만든 경우가 많았다. 작은 사양으로 시작해 측정값에 따라 늘리는 건 어렵지 않다. 잃어버린 데이터를 되돌리는 일은 훨씬 어렵다.
